< Programmbeschreibung >        < zurück >

Der Raspberry Pi als Server  -  Überlegungen zur Durchführung von Backups von System und Daten

Es ist schwer wenn nicht gar unmöglich, mit wenigen Worten eine Lösung zu beschreiben, die für alle Gegebenheiten gleichermaßen die perfekte Lösung ist. Eine solche umfassend für alle Fälle geltende Lösung wird es vermutlich auch gar nicht geben - weil schlichtweg immer zu viele Faktoren als relevante Größe einen Einfluss auf die Vorgehensweise im Rahmen der eigenen Gegebenheiten ausüben. Die Gefahren sind, entweder man sichert unnützes, oder zu wenig, oder das falsche, oder zu selten und damit mit fehlender Aktualität, mit zu hohem Aufwand, oder zu fahrlässig, oder ohne Qualitäts- und Integritätskontrollen, usw. Deswegen sind es letztendlich nur zwei Aspekte, die hinterher feststellen, ob eine individuelle Lösung richtig oder falsch war. Und zwar das Resultat im Fall der Fälle, wenn in einem Worst-Case-Szenario nach einem Vorfall alle Daten im produktiven System verloren sind. Ist ein vorhandenes Backup geeignet, alles wie zuvor wiederherzustellen, war es ein gutes Backup. Ist ein Backup ungeeignet und man kann den vorherigen Zustand nicht oder nur unzureichend wiederherstellen, ist es jedenfalls ein schlechtes Backup und man hätte sich diese Arbeit auch sparen können. Aber selbst dieses Fazit ist noch vage und wird schließlich davon beeinflusst, ob mir der Verlust oder die Wiederherstellung vielleicht gleichermaßen egal sind, weil mir einfach die Daten egal sind.

Ich glaube, man sollte deshalb -bevor irgendwelche vielleicht planlose Aktionen durchgeführt werden- mit den 2 folgenden Fragen beginnen und zuerst dafür nach Antworten suchen: Was muss/soll ich überhaupt sichern? Wie wichtig sind mir diese betroffenen Daten? Allein die Antwort auf das voraussichtliche Schadensausmaß bestimmt alle meine weiteren Entscheidungen. Für diese ersten beiden Fragen muss man unbedingt selber eine eigene Antwort finden. Bei mir laufen beispielsweise 2 zusätzliche headless arbeitende Server, die ich überhaupt nicht sichere. Bei diesen Maschinen habe ich einmalig nach dem Setup einige Einstellungsdateien gesichert und seitdem kümmere ich mich kaum noch um diese Rechner und lasse sie einfach ihre Arbeit tun. Diese Gleichgültigkeit gilt aber auch wirklich nur für diese 2 Rechner. Ich hoffe, dass der Artikel beim Finden einer eigenen Antwort auf diese zwei Eingangsfragen helfen kann, in dem er Möglichkeiten und Notwendigkeiten aufzeigt.

Ich habe für unsere Gegebenheiten also zuerst eine eigene Bewertungsskala gefunden, nach der ich anschließend meine Entscheidungen und meine Vorgehensweise ausgerichtet habe. Die Pyramide zeigt mit den unterschiedlich großen Flächen, mit welcher Gewichtung ich die einzelnen Aspekte bewerte. Der wichtigste Aspekt für die Frage, was, wann und wie oft gesichert werden soll, ist das Schadensausmaß bei Verlust oder Zerstörung von Daten. Wenn der Verlust von Daten und Dateien keinerlei Schaden bedeutet, warum soll ich dann überhaupt Aufwand in eine Sicherung stecken? Ohne einen möglichen Schaden, den man auch wirklich so empfindet, halte ich das für sinnlose Zeitverschwendung.

Aber was bedeutet eigentlich Schadensausmaß. Das ist einfach zu beantworten, damit ist nicht nur ein materieller oder finanzieller Schaden gemeint, sondern das umfasst durchaus auch einen immateriellen oder ideellen Schaden. Wie wichtig sind mir diese verlorengegangenen Daten? Was bedeuten sie mir? Wie ist der ideelle Wert einzuschätzen? Wie grenze ich wichtiges von unwichtigem ab? Also resultiert letztlich aus dem möglichen tatsächlichen oder auch nur empfundenen Schadensausmaß der sich notwendigerweise anschließende Arbeitsaufwand, den ich präventiv leisten muss, um dieses Schadensmaß zu minimieren oder gar ganz zu verhindern. Kurz gesagt:

-  kein Schaden nach Datenverlust = niedriger bis kein eigener Arbeitsaufwand

-  hohes Schadensmaß nach Datenverlust = u.U. auch großer eigener Arbeitsaufwand durch regelmäßige Sicherungen und sorgfältige Qualitätskontrolle

Wenn ich das mögliche Schadensmaß bestimmt habe und mir dann bewusst ist, dass der Schaden für mich sehr wohl bedeutsam ist und deshalb eigener Arbeitsaufwand für eine wirksame Schadensvermeidungsstrategie unbedingt notwendig ist, kann ich anschließend überlegen, welchen Aufwand ich überhaupt zu leisten bereit bin, um diesen Schaden wirksam zu verhindern. Hier gilt die Devise, je wichtiger mir die Daten sind, um so mehr sollte ich bereit sein, eigenen Aufwand zum Schutz dieser Daten in Kauf zu nehmen. Ausgehend von diesen beiden primären Aspekten kann ich mich nun mit dem dritten Feld befassen und versuchen, für das künftige eigene Sicherungs-Konzept Möglichkeiten und Lösungen zu finden, die einen Schaden einerseits verhindern und gleichzeitig aber auch den eigenen zu leistenden notwendigen Aufwand zu minimieren. Nicht zu vergessen, hier geht es ja nicht um ein zertifiziertes Rechenzentrum, sondern nur um den privaten IT-Einsatz mit ausschließlich privaten Daten.

Und zu guter Letzt steht ganz ganz oben in der Pyramide im kleinsten Feld das Programm. Um die Antwort auf die Frage, mit welchem Programm ich meine Datensicherungen erstellen will, kümmere ich mich also erst ganz am Ende.... und zwar dann, wenn ich genau weiß, was das Programm überhaupt für mich leisten soll. Ich bewerte die Auswahl eines Programms also als den kleinsten aller notwendigen Schritte. Es gibt sicher etliche Programme, die pauschal eine solche Aufgabe erfüllen können, aber vielleicht nicht so viele, die auch genau zu meinen Anforderungen passen. Also muss ich mir zuerst über meine Anforderungen im Klaren sein, dann erst wähle ich ein Programm. Aber für alle Programm-Alternativen gilt gleichermaßen, nicht die Auswahl des Programms ist eine Garantie für den Erfolg, sondern erst die richtige und überlegte regelmäßige Anwendung eines solchen Programms gewährleistet, dass unsere Daten nach dem Crash nicht doch endgültig verloren sind.

Die Intention dieses Artikels ist es also nicht, sich primär mit dem Programm ExtraBAK zu befassen, sondern zunächst grundsätzliche Überlegungen anzustellen, ob ich überhaupt Datensicherungen durchführe, in welchem Umfang und einen kurzen Blick auf andere möglicherweise beeinträchtigende Faktoren zu werfen. Mit anderen Worten also ein eigenes Konzept zum Schutz der gespeicherten Daten zu erarbeiten. Natürlich ist ExtraBAK auch schon eine Lösung, und zwar eine auf meine Anforderungen zugeschnittene Lösung. Aber trotzdem ist es auch eine allgemein taugliche Lösung. Der Teil des Artikels, der sich mit dem Einsatz von ExtraBAK befasst ist also eigentlich nur zusätzliches Beiwerk. Mit dem richtigen Überlegungen kann man auch jedes andere beliebige Backup-Programm nutzen. Ich nutze ExtraBAK, weil es mir ermöglicht, ohne großen eigenen Arbeitsaufwand selektive und größenmäßig sehr überschaubare Backups zu erstellen, die es mir stark erleichtern, willkürlich eine Qualitäts- und Integritätskontrolle durchzuführen. Die weitere Intention des Artikels ist es, ein Bewusstsein über mögliche Konsequenzen zu schaffen, wenn zwar ein bedeutsames Schadensausmaß entstehen kann, ich aber mit Gottvertrauen in die Zuverlässigkeit der Technik trotzdem nicht ordentlich sichere. Aber nicht nur eigene Fahrlässigkeit, mangelhafte oder mangelhaft angewandte Technik ist ein Problem, sondern auch vorsätzliche Zerstörung der Daten von außen, durch von fremden eingebrachte Schadsoftware, die sich z.B. den leichtfertigen Umgang mit "sudo" oder die Einbindung fremder (vielleicht proprietärer sich einer Kontrolle entziehenden) Repo's zunutze machen. Also in beiden Fällen bitte nicht hinterher jammern, wenn man keine ordentliche Sicherung hat.... denn das ist selbstverschuldet.

Dieser Artikel befasst sich also im Wesentlichen mit Überlegungen, wie man einige Risiken erkennen und minimieren kann, wie man das eigene Schadensausmaß beim Verlust der Daten bewerten kann, mit der Abgrenzung von Wichtigen und Unwichtigen und wie man das mögliche Schadensausmaß in Relation zum eigenen Aufwand für Sicherungsmaßnahmen setzen kann. Und schlussendlich, wie man -vielleicht mit Unterstützung von ExtraBAK- aus dem Dilemma "hohe Sicherheit erfordert vielleicht auch hohen Aufwand" raus kommt. Wegen dieses Schwerpunktes der konzeptionellen Überlegungen ist auch die Beschreibung des Programms aus diesem Artikel herausgelöst und befindet sich auf einer eigenen Seite, siehe dazu letzten Punkt im folgenden Menü.

Der Artikel ist zur leichteren Handhabung beim Lesen in die folgende Teile zu gegliedert. Ich versuche mich in diesen Teilen schrittweise einem praktikablen und wenig aufwendigen Konzept zu nähern, mit dem dennoch eine zuverlässige Datensicherung möglich ist.

Inhaltsübersicht:

> Rückblick auf eigene Erlebnisse

> Expansion - auf ein Mehr an Nutzung folgt ein Mehr an Risiken und ein Mehr an Aufwand für Wartung und Sicherung

> Der Einfluss von 'Unterschiede' auf den Sicherungsumfang - oder anders gefragt, was muss ich sichern, was nicht?

> Fakten

> Tatsächlicher Umfang

> Anforderungen an eine eigene und angemessene Lösung für den privaten IT-Einsatz

> Datenstrukturen

> Entscheidungen

> Ergänzende technische Hinweise

- Sicherheitsrisko "privilegierter Benutzer"

- Ransomware (Erpressungstrojaner)

- Mail To  (Benachrichtigungs-Emails)

- Höhere Gewalt

- Stromverbrauch

> ExtraBAK - die Programmbeschreibung

Rückblick auf eigene Erlebnisse

Mittlerweile ist es einige Jahre her, seit ich meinen ersten Raspberry Pi mit Linux als Betriebssystem aufgesetzt habe. Das war damals überhaupt mein erster Kontakt mit Linux. Der RPi sollte der stromsparende Nachfolger meines alten Fileservers werden, der als Win-7/Prof-Maschine ein wahrer Stromfresser war - so war zumindest damals meine Idee. Und als nach einigen Wochen/Monaten des Testens und Lernens die Umstellung anscheinend endlich gelungen war und der RPi endlich zufriedenstellend als unser neuer Fileserver gewerkelt hat, stand ich natürlich zwangsläufig auch vor der obligatorischen Frage "Wie erstelle ich am Besten Sicherungskopien meines PI's?" Weil ich heute rückblickend diese Frage allerdings nicht mehr als ganz so trivial empfinde (nur wenn man oberflächlich ist, ist es trivial), beschäftige ich mich beim Finden einer Antwort zu Beginn etwas umfangreicher mit ein wenig Theorie zum Thema. Denn natürlich folge ich auch hier meiner Devise, beim Umgang mit Computern nichts ohne eine Mindestmaß an Hintergrundwissen und Planmäßigkeit tun zu wollen. Ohne Hintergrundwissen und ohne Verständnis für die Zusammenhänge ist es schließlich nicht möglich, meine Entscheidungen nachzuvollziehen und später überhaupt zu praktikablen und sinnvollen eigenen Entscheidungen zu finden. "Backup" bedeutet nämlich nicht nur, eine Image-Kopie des Betriebssystems anzulegen, sinnvolle und vor allem tatsächlich verwendbare Backups erfolgen im Rahmen eines Konzeptes. Und weil es sich bei unserem Server nur um einen Raspberry Pi handelt, der ganz sicher keine Hochleistungsmaschine ist, beziehe ich in meine Überlegungen auch das bei uns etablierte Userverhalten ein. Insbesondere auch deshalb, weil der zentrale RPi mittlerweile -so wie bei uns- eine schon bedeutsame Rolle im familiären IT-Geschehen spielt. Aus dem Grund mache ich mir zusätzlich auch Gedanken zur Lastverteilung des Servers.

Aber wie gesagt, damals und zu dem Zeitpunkt war Linux völlig neu für mich und mein Selbstvertrauen war noch viel zu gering, um eine Wiederholung dieser langen und komplizierten Installation noch mal so eben aus dem Ärmel schütteln zu können. Also gab es nach der erfolgreichen Inbetriebnahme des PI und den dann folgenden ersten Überlegungen anscheinend auch nur den einen Weg, idealerweise die ganze SD-Karte zu sichern. Was ich damals natürlich auch getan habe, wie so viele andere vor mir und wie es wohl nach mir vermutlich auch immer noch viele tun, alle mit mehr oder weniger gleicher Intention. Wenn man nämlich eine Zeitlang in Raspi-Foren mitliest, begegnet einem immer wieder genau diese Frage und fast immer wird eine Lösung gefunden, die allzu oft darauf hinausläuft, doch irgendwie die ganz SDC zu sichern.

Nun sind einige Jahre vergangen, mein Selbstvertrauen im Umgang mit Linux ist gestiegen und mir ist heute bewusst, wie unsinnig es doch ist, wenn ich immer noch die ganze SDC sichern würde. Ein kühne Behauptung? Blödsinn? Tja, kann man so sehen, oder eben auch nicht. Ganz sicher gibt es Umstände, die ein solches Full-System-Backup tatsächlich erfordern, z. B. bei speziellen Distributionen, die um eine besondere Aufgabe drum herum gebaut sind und wo quasi die Distribution selber wesentlicher Teil des Programms zur Aufgabenlösung ist. Aber in unserem Netzwerk existieren solche Spezial-Installationen definitiv auf keiner Maschine, weder auf dem Server, noch auf den Clients. Ziel meiner Betrachtung sind also ganz normale Linux-Computer und natürlich insbesondere auch der familiäre Daten-Server... und für alle diese Linux-Systeme halte ich es derzeit für unnötig, Images des Betriebssystems anzulegen. Also warten wir's doch einfach mal ab, zu welchen Rückschlüssen ich im weiteren Verlauf dieses Artikels komme. Insbesondere versuche ich hier über Erklärungen zu Erkenntnissen über den Sinn und Unsinn gewisser Backups für gerade solcherart Standard-Linux-Systeme zu gelangen. Und ich versuche darzulegen, dass zu einem reproduzierbaren aktuellen Backup nicht nur eine einzelne OS-Image-Kopie gehört, sondern das das in Wahrheit ein kontinuierlicher Prozess ist.

Expansion - auf ein Mehr an Nutzung folgt ein Mehr an Risiken und ein Mehr an Aufwand für Wartung und Sicherung

Aufgrund der guten Erfahrungen mit Linux in der Zeit nach der Inbetriebnahme habe ich unserem PI im Laufe der Zeit neben dem eher anspruchslosen Fileserver-Job noch weitere Aufgaben übertragen. Das heißt, er leistet heute viel mehr als damals im Anfang direkt nach der ersten Einrichtung als Fileserver. Heute ist er auch noch Print-Server, OpenVPN-Server, Cloud-Server für den Cal/Dav-Sync unserer Smartphones, seit einiger Zeit ist er auch unser Mailserver und natürlich seit Beginn an ist er Backup-Controller. Das ist schon eine ganze Menge an Arbeit für so ein kleines Maschinchen.... aber was soll ich sagen, er tut's halt perfekt, und alles ohne in Not zu geraten. Von der Gewichtung des RPI-Arbeitsauftrages für uns, also der Menge seiner Aufgaben und seines Arbeitsergebnisses her betrachtet, ist es also unzweifelhaft, dass eine Sicherung dieses Rechners sinnvoll ist - da steckt ja auch eine Menge Arbeit von mir drin. Aber nicht nur, sondern mittlerweile auch private Daten in der Größenordnung von mehreren Gigabytes.

In der professionellen Datenverarbeitung ist regelmäßige Datensicherung seit jeher obligatorisch. Und es ist durchaus ratsam, ein wenig dieser Praxis auch für die eigene private Datenverarbeitung zu übernehmen. Aber auf unserer Ebene der privat betriebenen EDV mit einem Linux-Computer oder vielleicht sogar einem kleinen Netzwerk allein ein einmaliges Backup oder eine Image-Kopie eines laufenden Betriebssystems zu erstellen und zu glauben, jetzt ist alles gut, entspricht in etwa dem gleichen Irrglauben, wie eine Desktop-Firewall zu installieren und zu glauben, jetzt wäre man vor allen Angriffen sicher.

Backups zu erstellen bedeutet nicht nur die Erstellung des Backups, sondern primär auch die regelmäßige Prüfung, dass die Backups überhaupt sinnvoll verwendbar sind. Backups zu erstellen, gerade wenn es sich um ein Full-Betriebssystem-Backup handelt, heißt auch auf die Bewegungen des OS durch Upgrades zu reagieren. Was hilft ein SDC-Image, wenn es schon nach dem nächsten 'apt full-upgrade' veraltet ist? Ich gehe sogar noch einen Schritt weiter... wäre ich konsequent und eine hohe Ausfallsicherheit des Computers ist notwendig, müsste ich bei dem für uns mittlerweile sehr wichtigen RPI vor dem System-Upgrade zuerst ein Backup machen, damit ich es restoren kann, falls der Upgrade destruktiv wäre. Und wenn ich bestätigt habe, dass das letzte Upgrade stabil ist, müsste ich sofort ein neues Backup anfertigen, damit ich den letzten laufenden Stand gesichert habe. Was soll dieser Unfug? Wie viele von diesen Images will ich eigentlich anlegen? Vielleicht sogar noch rollierende Rollback-Versionen? Fakt ist, macht man es korrekt und sorgfältig, erfordert dieser Umfang der Datensicherung enorm viel Zeit und Aufwand - oder man verwendet von vornherein ein Snapshot-taugliches Filesystem. Ist das System allerdings wichtig und man macht es nicht korrekt, lügt man sich selber was in die Tasche und fällt im Fall der Fälle möglicherweise frustriert und enttäuscht hart auf den Boden der Tatsachen zurück. Also, warum etwas tun, was eh zweifelhaft ist und dessen dauerhafter Aufwand vermutlich den meisten eh zu hoch ist? Der bessere Weg ist es doch, eine sinnvolle und praktikable Lösung zur Erstellung von Backups zu finden, die mit vertretbarem Aufwand auch längerwährend die Wiederherstellung von System und Daten ermöglicht. Eine für mich wesentliche Prämisse ist es also, den eigenen Aufwand so gering wie möglich zu halten, ohne jedoch bei der Zuverlässigkeit meiner Backups unnötige Risiken auf Datenverlust in Kauf nehmen zu müssen. Erkennen wir dazu also zunächst einmal "Unterschiede"......

Der Einfluss von 'Unterschiede' auf den Sicherungsumfang - oder anders gefragt, was muss ich sichern, was nicht?

Die Kernfrage ist, was von der riesigen Menge an gespeicherten Dateien ist es überhaupt wert sinnvoll gesichert zu werden? Muss es wirklich alles sein? Welchen Aufwand will ich bei einer Worst-Case-Situation mit der notwendigen Wiederherstellung des Servers mit möglicherweise begleitendem Datenverlust überhaupt betreiben? Welchen Aufwand will ich während des normalen Produktivbetriebes betreiben, um diese Wiederherstellung über Backups im Fall der Fälle auch sicher zu garantieren? Kann man den einen oder anderen Aufwand vielleicht sinnvoll beschränken? Um sich bei diesen Fragen einer Lösung zu nähern, muss man sich zuerst ein paar wichtige Unterschiede bewusst machen. Welche das sind, versuche ich im folgenden zu erklären.

Eine unumstößliche Tatsache ist, dass alles das, was auf der SD-Karte des PIs gespeichert ist, aus Sicht des Speichermediums zunächst mal einfach nur Dateien sind - und zwar ausnahmslos und ohne Unterschied. Eine Unterscheidung über den "Sinn" oder die "Aufgabe" einer solchen Datei ergibt sich erst, wenn sie irgendwann durch irgendwen oder irgendwas verwendet wird. Und dazu wird sie zuerst geöffnet und dann gelesen. Enthält die Datei den Text eines Witzes, dann lacht vielleicht der menschliche Leser. Enthält sie Anweisungen für den Computer, führt der Computer diese Anweisungen (ein Programm) aus. Hier können wir also feststellen, dass der Inhalt einer bestimmten Datei durchaus nicht für alle und jeden sinnvoll verwendbar ist. Der Computer wird mit dem Witz nichts anfangen können, schlimmstenfalls würde er die Zeichen falsch interpretieren und irgendwas katastrophales tun. Und wir als Leser können mit dem Kauderwelsch einer computerverständlichen Datei üblicherweise auch nichts anfangen. Dateien haben also einen bestimmten Verwendungszweck und in gewisser Weise ist damit vorbestimmt, wer die Datei sinnvoll verwenden kann. Aber bis zu dem Punkt dieser Verwendung ist es dennoch immer nur eine Datei. Und genau das bleibt sie auch, wenn es um eine Sicherung dieser Datei auf ein anderes Medium, ein Backup-Medium geht. Dabei wird einfach nur diese Datei von dem einen Ort zu einem anderen Ort kopiert - es wird ein Duplikat erzeugt. Zählen wir als nächstes einfach mal, um wie viele Dateien es dabei überhaupt geht. Mein eigener eher spartanisch eingerichteter PC mit einem Custom-Desktop enthält ca. 380.000 Dateien - nur Betriebssystem und Anwendungsprogramme, ohne eigene Daten. Auf der SDC meines Servers sind nur ca. 112.000 Dateien gespeichert. Der große Mengenunterschied kommt dadurch zustande, weil auf dem Server keine grafische Anwendungen installiert sind, sondern wirklich nur das Betriebssystem und die notwendigen Dienste.... es ist eben ein reiner Server. Bei der Erstellung eines Images von meiner Festplatte müssten also 380.000 Dateien gesichert werden, beim SDC-Image-Backup des PIs werden mehr als 112.000 Dateien auf dem einem Medium gelesen und auf ein anderes Medium geschrieben - es wird i.ü.S. eine Kopie aller Dateien angelegt. Das kann komprimiert sein, oder in einem Container, wie auch immer, es sind trotzdem Kopien. Aber was sind diese 112.000 Files überhaupt für Dateien?

All das macht zusammen etwa 1,5 GB auf der SD-Karte aus. Gibt es an diesen Dateien etwas besonderes, etwas wichtiges, was unbedingt sicherungswürdig ist? Nö, eigentlich nicht, da ist absolut nicht bedeutsames enthalten. Das Raspian-Image kann ja auf einfachste Weise jederzeit erneut auf die Karte geschrieben werden. Danach wird mal eben ein vollständiges "Upgrade" durchgeführt und die folgenden "apt install"-Befehle für die wenigen o.g. Pakete sind ja wirklich ohne Aufwand auch schnell wiederholt. Bei diesen 1,5 GB ist also absolut nichts dabei, was nicht jederzeit auf einfachste Weise wiederhergestellt werden kann. Mit ein paar Stunden Aufwand ist der ganze Server mit all seiner Software wiederhergestellt. Welchen Sinn soll es also haben diese 1,5 GB zu sichern? Tja, ich kann den nicht erkennen.

An der Stelle greife ich noch mal 3 wichtige Begriffe auf, die bezogen auf Dateien zuvor schon genannt wurden, und zwar "Sinn" und "Aufgabe" und "Wiederherstellung" von Dateien. Der Sinn oder die Aufgabe einer Datei kann es z.B. sein, ein Programm zu sein und ausgeführt zu werden und dabei einen bestimmten Job zu tun. Der Sinn einer anderen Datei kann z.B. sein, ein Buch zu sein - entweder ein schon geschriebenes Buch eines beliebigen Autors, oder ein Buch, welches ich selber gerade mit einem Programm (einer Textverarbeitung) schreibe. Und wenn ich jetzt die Bedeutung des Verlustes dieser 3 Dateien für mich bewerte, dann bekommt das oben erwähnte "sich Unterschiede bewusst machen" einen Inhalt.

Der Grad der Notwendigkeit, bestimmte Dateien sorgfältig zu sichern, wird also durch den Aufwand festgelegt (den ich leisten muss) oder durch die Kosten (die ich tragen muss), um eine verlorengegangene Datei wiederzubeschaffen. Das bedeutet, alle jene Dateien, die ich jederzeit einfach wiederbeschaffen kann, muss ich also gar nicht sichern, die sind ja sowieso jederzeit verfügbar. Aber all das, was ich nur mit hohem Arbeitsaufwand oder Kosten wiederbeschaffen kann, muss ich unbedingt sichern. Ich kann also durchaus unterscheiden, was ich sinnvollerweise sichern muss und was für die regelmäßige Sicherung völlig unnötig ist.

Alles das, was ich ohne großen Aufwand und ohne Kosten wiederbeschaffen kann, ist deshalb meiner Meinung auch überhaupt nicht wert, gesichert zu werden. Einerseits weil die Wiederbeschaffung nicht wirklich Aufwand oder Kosten verursacht, andererseits hingegen die regelmäßige Sicherung selber wieder Aufwand und ggf. auch Kosten verursacht, und zwar durch den Prozess selber, der Bereitstellung von Backup-Medien, durch Aufbewahrung und Wartung und Pflege der Backups. Was hilft mir ein Full-System-Backup, wenn es 6 Monate alt ist und ich mich nicht mehr daran erinnern kann, ob und welche Änderungen ich nach dem Backup am PI durchgeführt habe? Was helfen mir regelmäßige Full-System-Backups, wenn ich danach nicht permanent kontrolliere und bestätige, dass sie überhaupt zum Restore verwendet werden können und das ich dazu von meinen Kenntnissen her in der Lage bin? Oder schlimmer, wenn ich selber gar nicht so recht weiß, wie ich so ein Image überhaupt verwenden kann/muss? Und je größer das Backup ist und umso mehr es mit Müll verwässert ist, umso schwieriger wird es im Fall der Fälle sein, die Integrität eines Backups zu beurteilen, es sinnvoll zu verwenden und anschließend die Qualität des erfolgten Restores zu bewerten .... also nicht nur hinsichtlich des Backupmediums, sondern gerade auch inhaltlich für das Restore-Ergebnis.

Fakten

Um einmal die Dimensionen zu verdeutlichen, habe ich aus Neugier die aktuelle Anzahl der Dateien und deren Speicherbedarf auf der SDC meines Servers ermittelt, bei denen eine Sicherung tatsächlich notwendig ist. Von den ca. 112.000 derzeit vorhandenen Dateien sind es genau 230 Dateien, deren Wiederherstellung ich bei Verlust zum Teil nur mit hohem bis sehr hohem Aufwand leisten könnte. Bezogen auf die gesamte Anzahl von 112.0000 Dateien entsprechen die 230 Files gerade mal einem Anteil von ca. 0,2%. Von den 1,5 GB beanspruchen diese 230 Dateien genau 585 KB, was bezogen auf die Gesamtmenge einem Anteil von ca. 0,04% entspricht. Mit anderen Worten: Wenn ich ein Image-Backup der SDC erzeuge, besteht dieses Backup faktisch aus über 99,96% unnützem Füllstoff, Ballast, Müll. Von allen im Image gesicherten Dateien können für meinen RPi ca. 99,96% jederzeit durch einfaches installieren auf einfachste Weise ohne Backup und ohne großen Aufwand wiederbeschafft werden. Kann mir bitte jemand den Sinn einer solchen Backup-Maßnahme erklären?

Was unterscheidet aber diese 230 Dateien von den anderen 112.000 ...? ... denn diese 230 Dateien sind doch auch innerhalb der oben genannten Punkte 1-4 durch einfache Installation auf meinem Server gelandet. Das ist einfach zu beantworten. Der Unterschied ist, ich habe sie nach der Installation manuell mit mehr oder weniger großem Aufwand auf unsere Serverfunktionen angepasst. Im Regelfall handelt es sich hier um spezifische Einstellungsdateien der Dienste, z.B. die Einrichtung der Samba-Shares, die OpenVPN-Konfigurationen, die Drucker-Konfiguration, die sehr umfangreiche Einstellung für Mailserver und Sync-Cloud-Server, usw. In diesen Einstellungsdateien steckt jahrelanges Lernen und wirklich viel Arbeit. Würden diese wenigen Dateien verloren gehen, würde unser Serverbetrieb auf unbestimmte Dauer zum Erliegen kommen. Ich könnte die Funktionen des Servers trotz umfangreicher Dokumentation nicht mal eben auf die Schnelle wiederherstellen.

Also geht an der Datensicherung speziell dieser kleinen Menge Dateien kein Weg dran vorbei. Wenn unser Server eine für uns wichtige Aufgabe hat (und die hat er mittlerweile), ist die Sicherung alternativlos.

Und weil ich mich hier ja mit Unterschieden befasse, kommt hier zu den zwei bisher besprochenen Kategorien eine weitere zu unterscheidende Kategorie hinzu. Das erste waren die Betriebssystem-Dateien, mit allen installierten Diensten und Programmen, die wir jederzeit wiederbeschaffen können. Das zweite waren die von uns durchgeführten manuellen Einstellungen, deren Wiederbeschaffung durchaus schwer oder gar unvertretbar hoch sein kann. Und das dritte sind nun die echten, eigenen Dateien des privaten Familien-Alltags, womit Dateien gemeint sind, die wir selber in irgendeiner Form angelegt haben. Das kann unser E-Mailarchiv sein, unser Kontakt-und Freundesadressbuch, die private Finanzbuchhaltung mit Datenbanken und Tabellenkalkulationen, mit einer Textverarbeitung geschriebene private Briefe und Schriftverkehr, Bewerbungen, Schul- oder Uni-Projektarbeiten der Kinder, von der Hausfrau geschriebene eigene Kochrezepte, die Mannschaftstabelle und Vereins-Dokumente der E-Jugend, deren Trainer man ist, GPX-Planungen für den nächsten Urlaub, GPX-Aufzeichnungen der letzten Rad-Rundfahrten, die digitale Fotosammlung der gemeinsamen Urlaube, oder der Kindergeburtstage, oder der Familenfeiern, usw. usw. Alles Daten und Dateien, die im privaten Lebensalltag entstehen oder entstanden sind, die einem durchaus auch sehr wichtig sind, weil sie Markierungspunkte im eigenen Leben darstellen und bei deren Aufbewahrung und Bewältigung der Einsatz eines zentralen Servers absolut sinnvoll und hilfreich ist.

Tatsächlicher Umfang

Für mich sind es gerade diese zuletzt beschriebenen Daten, die deutlich mehr Relevanz und Bedeutung in unserem familiären Leben haben, als die davor genannten 2 Kategorien. Und gerade diese Dateien sind es, die bei Verlust faktisch nicht mehr wiederbeschafft werden können. Habe ich ein Buch angefangen und ich verliere das Manuskript, ist es weg. Ich kann nur ein neues, ein anderes Buch schreiben. Es kann ähnlich dem ersten sein, aber es wird nie dasselbe sein. Schreibt der Filius gerade an seiner Master-Arbeit und kurz vor der Fertigstellung brennt die Platte ab, ist die Master-Arbeit endgültig weg. Habe ich unsere Finanzdaten über 10 Jahre gesammelt, um darüber Planungskennzahlen fürs Familienbudget im nahenden Pensionsalter zu erhalten und die Platte brennt ab, sind 10000e Buchungsdatensätze aus der Finanzbuchhaltung unwiderruflich weg. Nichts davon bringt einen um... natürlich nicht, schließlich sind die Menschen 100.000 Jahre vor uns auch ohne Computer ausgekommen. Aber mal ehrlich, wenn diese unsere Daten weg wären, wäre ich wohl auf unbestimmte Zeit in der Zukunft einigermaßen sauer. Weil mir das alles wichtig ist und weil wirklich von diesen Daten nichts dabei ist, was mit einem vertretbaren Aufwand wiederhergestellt werden kann. Das meiste davon wäre sogar endgültig verloren. Also ist es genau diese Kategorie an gespeicherten Dateien, der ich meine größte Aufmerksamkeit widme - und bestimmt nicht den Linux-Installationen auf den Computern.

Zu dieser dritten "harten" Kategorie gehört noch ein spezieller etwas "weicherer" Teilbereich. Hierbei handelt es sich um Dateien, für deren Speicherung auf der Platte wir zwar selber verantwortlich sind, aber es sind keine Dateien, die wir mit eigener Arbeit erstellt haben und die nichts direkt mit unserem Familienleben zu tun haben. Ich meine hier die typischen Mutlimedia-Dateien. Das können Filme sein, EBooks oder MP3's. Charakteristisch für diese Dateien ist der enorme Speicherbedarf. Wenn die persönlichen Anwender-Dateien der ganzen Familie nach vielen Jahren des EDV-Betriebs vielleicht höchstens 10 GB betragen, so können Multimedia-Dateien binnen eines Jahres auf die Größe mehrerer Terrabytes anschwellen. Auch diese Dateien zu sichern ist kein Problem, man muss halt nur ein Backup-Medium einsetzen, was diese Menge aufnehmen kann. Aber man täuscht sich, wenn man glaubt, man könne einfach mal alle paar Tage ein Full-Backup einer solchen Harddisk erzeugen.... wenn nämlich der PI das machen soll, wird er vermutlich einen ganzen Monat damit beschäftigt sein und währenddessen keine andere Aufgabe mehr erfüllen können. Also wegen der enormen Datenmenge und der Tatsache, dass solcherart Dateien sowieso auch immer wiederbeschafft werden können, verzichte ich hier auf die gleiche Nachhaltigkeit beim Sichern, wie sie für unsere echten Daten gilt. Aber wie man damit umgeht und welche Begründungen zu welchen Entscheidungen führen, muss jeder für sich selber ermitteln.

Als Fazit und reduziert auf das Wesentliche komme ich nun zu dieser Übersicht, wenn es um die wichtige Frage und der darauf folgenden Entscheidung geht, was muss und was will ich überhaupt sichern?

Anforderungen an eine eigene und angemesse Lösung für den privaten IT-Einsatz

An dem Punkt angekommen habe ich nun eine begründete Vorstellung darüber, welchen Weg ich gehen möchte resp. welchen Sicherungs-Umfang ich umsetzen möchte. Bei all den Thesen und Hypothesen gilt es letztendlich aber, das eigentliche Ziel nicht aus den Augen zu verlieren. Und das eigentliche Ziel ist, mit möglichst geringem Aufwand über reproduzierbare Backups die Sicherheit unserer Daten und die Wiederherstellbarkeit der Funktionen unseres Servers zu garantieren. Aus dieser Zielformulierung ergeben sich für mich und meine Ansprüche einige einfache Prämissen:

Der allerdings meiner Meinung nach wichtigste Faktor für eine ordentliche Erstellung von Sicherungsdateien ist es, vor Beginn der Backup-Erstellung eine grundsätzliche geordnete und übersichtliche Dateistruktur zu schaffen. Erst eine solche Dateistruktur ermöglicht Backups in effizienter Größe, überschaubar, verifizierbar, reproduzierbar, mit einfach durchzuführender Qualitäts- und Integritätskontrolle. Und insbesondere aus dem Anspruch "geringer Aufwand" und "mannlos" resultieren für meine Vorstellung einer praktikablen Lösung deshalb unmittelbar klare Vorgaben. Es sind an meinem Server (idealerweise) vier von einander unabhängige permanent angeschlossene Speichermedien notwendig:

	SDC	Speichermedium (obligatorisch) für das Betriebssystem und die Funktionen des Servers.
	SSD	1 Speichermedium als hochflexibler und schneller Speicher für tagesaktuelle private und persönliche Daten mit hohen bis sehr hohen Änderungsaufkommen.
	HD1	1 Speichermedium für 'statische' Dateien (ohne Änderungsaufkommen) mit großem Speicherbedarf, z.B. den im eigenen Netzwerk allen Clients zugänglichen Multimedia-Dateien, für die es optional sogar weitere HDs geben könnte. Dieses Medium ist gleichzeitig auch Backup der SSD durch den tägl. Synchronisations-Lauf.
	HD2	1 Speichermedium zur Aufnahme der zyklischen Backups aus Betriebssystem (SDC) und persönliche Daten (SSD), sowie für explizit bestimmte Fremd-Dateien (HD1) in komprimierter Form.

... was dann zu folgendem Hardware-Einsatz führt: