< 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:

 

Datenstrukturen

Für die Anwender im Netzwerk sind faktisch nur zwei Datenspeicher relevant. Die schnelle SSD, die ohne Aufwachzeiten sofort bereitsteht, um z.B. direkt die Mailordner zu öffnen, oder verzögerungsfrei den Card/Cal-Sync von Smartphone und Thunderbird zu ermöglichen oder ohne Wartezeiten den Umgang mit eigenen Office-Dokumenten ermöglicht. Lediglich beim Öffnen einer Multimedia-Datei von der Festplatte kann es zu kurzer Wartezeit kommen, wenn zunächst die Festplatte aus dem Sleep geweckt werden muss. Das hat sich bei uns allerdings als absolut unproblematisch erwiesen, weil der hohe Datenzugriffs-Anteil von der schnellen SSD bewältigt wird. Beide Harddisks verbringen die meiste Zeit des Tages stromsparend im Sleep-Modus.

Für alle Anwender mit ihren Client-PCs ist die Server-SSD der massgebliche Speicherort ihrer persönlichen Dateien. Die SSD speichert alle persönlichen User-Dateien jeweils in eigenen User-Verzeichnissen des Ordners /Home. Diese privaten zusätzlichen Server-Verzeichnisse der Anwender ersetzen nicht das Server-Homedir und auch nicht das lokale Client-Homedir, sie werden stattdessen explizit ins tatsächliche Linux-Homedir des Users auf dem Server gemountet, um dann auf dem Server via Samba-Share-Definitionss [homes] auf dem Client endgültig individuell in die tatsächlichen Home-Dirs gemountet werden zu können. Ob diese Vorgehensweise auch für einen große sehr Anzahl Anwender geeignet ist, kann ich ad hoc nicht beantworten. Aber da ich hier nur eine familiäre Perspektive habe, interessiert es mich auch nicht weiter, ob viele Anwender vielleicht ein Problem darstellen würden.

Das Verzeichnis /Mail enthält ebenfalls ausschließlich User-spezifische Verzeichnisse, z.B. die E-Mail-Postfächer, die Datenbanken für Cal/Dav-Snchronisation, Mail-Filterbedingungen, sowie die Abholeinstellungen für E-Mails zum Mail-ISP. Die Besonderheit ist hier, dass der Zugriff nur über dedizierte Anwendungsprogramme möglich ist. Ein willkürlicher Zugriff z.B. mit einem Dateimanager ist nicht möglich.

Das Verzeichnis /Alle ist ein gemeinsamer Ordner für alle Netzwerk-Clients, für den Datenaustausch, für Dateien und Dokumente, die alle betreffen und für Ordner und Dateien, auf die alle User Zugriff haben müssen.

Der zweite für die Netzwerk-User relevante Datenspeicher ist die Festplatte mit mehreren TB Kapazität. Für die Anwender zugänglich enthält sie nur /MultiMedia mit Lese-Berechtigung. Das Verzeichnis /Install enthält Setup-Pakete, Source-Codes und Compiler-Anweisungen, Setup-Notizen, usw. von verschiedenen Programmen und ist nur für Administrations-Aufgaben mit root-Berechtigung auf den Clients interessant.

Die primären und zur Sicherung relevanten Dateien und Verzeichnisse hier im Überblick:

 

Entscheidungen

Natürlich ist all das, was ich hier beschreibe, keine Empfehlung es auch genau so zu machen... nein, überhaupt nicht. Es soll allein dabei helfen bzw. einem Laien ermöglichen, mit dem besseren Verständnis von Problemen und Gegebenheiten bessere eigene Entscheidungen treffen zu können. Für sichere Backups ist eben meiner Meinung nach etwas mehr notwendig, als sich lediglich für irgendein Backup-Programm zu entscheiden und zu glauben, dass jetzt alles gut ist. Letztendlich muss das Backup auch halten, was man sich selber davon verspricht. Ansonsten kann man die damit verschwendete Zeit auch wirklich sinnvoller verbringen. Und ich möchte gerne das Bewusstsein für die Idee schärfen, dass der wahre Nutzen für uns in der Einfachheit unserer eigenen IT-Infrastruktur liegt. Alles das, was unnötig (oder gar unverhältnismäßig) kompliziert ist, wird auf Dauer in der Produktivbetreuung der laufenden IT auch für unnötig großen Aufwand sorgen. Dabei ist es absolut nicht so, dass nur das gut funktioniert, was auch wirklich kompliziert ist - eher das Gegenteil ist der Fall... denn die einfachen Lösungen gut und intelligent angewandt, sind in ihrem Ergebnis fast nie schlechter. Anstatt eine perfekte Integration von vielen Komponenten anzustreben und versuchen das auch zu realisieren, empfehle ich meistens auch eher auf Kapselung und Trennung zu setzen - wenn dann isolierte Prozesse "sterben", bleibt wenigstens der Rest unberührt. In einer vollständig integrierten Installation von vielen einzelnen Komponenten sind die Folgen allerdings unübersehbar.

Als Fazit habe ich bezogen auf unsere Server- und Clientkonfiguration schließlich folgenden Entschluss gefasst: Ich will und werde gar nicht erst versuchen, ein defektes System über irgendein Backup zu retten. Die dafür notwendige Zeit ist mir schlichtweg zu kostbar. Ist ein System tot, aus welchen Gründen auch immer, lade ich kurzerhand ein aktuelles Image aus dem Netz, installiere es, installiere im zweiten Schritt die benötigte Software und übernehme einfach die Einstellungen besonderer Programme aus dem Backup. Die Erfahrungen aus der Vergangenheit haben gezeigt, dass ich die Wiederinbetriebnahme eines Rechners nicht mit weniger eigenem Aufwand leisten kann. Natürlich gibt's jetzt auch wieder ganz Schlaue, die nun behaupten, via Snapshot repariere ich das in Minuten. Klar geht das, nur wird dabei verschwiegen, dass der vorherige Aufwand, um sich da einzuarbeiten und die Snapshots dann auch permanent aktuell zu halten, in keinem Verhältnis zu dem steht, was ich in Summe überhaupt bereit bin, an eigener Arbeit zu investieren.... und nur darauf kommt es an... ganz am Ende auf die Summe geleisteter eigener Stunden. Für mich gilt hier zweifelsfrei die Devise "So viel wie nötig, so wenig wie möglich"... die sich auch 1:1 zu meiner grundsätzlichen Einstellung auf die IT-Infrastruktur übertragen lässt "So einfach wie möglich, so kompliziert wie nötig".

Ergänzende technische Hinweise

Wer es tatsächlich geschafft hat und sich geduldig bis hierhin durchgekämpft hat, sollte jetzt eigentlich verstanden haben, dass ich mich bisher noch gar nicht endgültig mit der Erstellung eines Backups befasst habe, sondern stattdessen das Thema von allen möglichen anderen Seiten betrachtet habe. Nur zur Beantwortung der Frage 'Wie erstelle ich ein Backup?' ist dieser Artikel wirklich völlig ungeeignet, das beschreibt auch viel besser die Dokumentation zu ExtraBAK. Aber das war hier auch nicht meine Intention. Meine Absicht war es, mich tiefergehend mit der Frage zu beschäftigen Wie schütze ich wirksam und mit vertretbaren Aufwand meine Daten? Und das erfordert eben, sich doch ein wenig umfassender mit dem Thema zu befassen. Neben den Tools zur Erstellung von Backups sind für einen wirksamen Schutz u.a. also auch eine effiziente und strukturierte Datengrundlage notwendig. Und darüber noch hinaus ist unbedingt ein restriktives Zugriffsmanagement ein maßgeblicher Aspekt, damit Anwender diesen Schutz nicht wieder fahrlässig oder auch absichtlich untergraben können. Ein weiterer Aspekt ist das regelmäßige Controlling, welches zwar effektiv sein soll, aber dennoch keine ausufernde Arbeit nach sich ziehen soll. Und schließlich war für mich auch das Verhältnis von "Aufwand" und "Ertrag" ein wichtiger Faktor bei allen Überlegungen, denn letztendlich sind für einen wirtschaftlich vertretbaren Serverbetrieb auch die Folge-Energiekosten relevant. Für diese zusätzlichen Nebenaspekte habe ich hier hoch ein paar lose und unsortierte Gedanken und Hinweise angehängt.

Sicherheitsrisko "privilegierter Benutzer"

Obwohl ich selber der System-Administrator unseres Netzwerkes bin, habe ich als User weder auf dem Server selber und auch von keinem einzigen Client-PC aus direkten Zugang zu allen Daten und Einstellungen des Servers, weder mit meiner UserID, noch mit der eines Client-root, noch mit irgendeiner anderen UserID. Das ist einer der Eckpfeiler des Sicherheitskonzeptes dieses privaten Netzwerks, welches man sich vielleicht durchaus bewusst machen sollte, auch wenn das möglicherweise im krassen Gegensatz zu den Vorstellungen eines unerfahrenen Neu-Linux-Admins steht, der es von Windows gewohnt ist, immer und für alles Administrator-Rechte zu haben. Aber genau diese umfassenden Rechte, über die er als eigentlich rechteloser Normal-User gar nicht verfügen sollte, sind neben der Verwendung von "sudo" das offene Einfallstor für digitale Invasoren, für die mögliche 'feindliche'Übernahme' des Rechners mit Zugriff auf alle private Daten, bis hin zum möglichen Verlust aller Daten bei mutwilliger Zerstörung durch einen böswilligen Computer-Virus oder bei 'Entführung' durch einen Erpressungstrojaner. Ich glaube, wer in einem Netzwerk mit Server und vielen Client-PCs auf umfassende Administrator-Rechte für sich selber und unter seiner UID besteht und das als bevorzugtes Privileg versteht, hat es eigentlich nicht wirklich verstanden. Nicht das Privileg schützt die Daten, ganz im Gegenteil, dieses Privileg beinhaltet das höchste Risiko und die größte Gefahr für System und Daten. Stattdessen sind beschränkte Rechte, Sachkenntnis, Verantwortung, Sorgfalt, Ordnungsmäßigkeit und Disziplin diejenigen Faktoren, die System und Daten zuverlässig schützen. Der obligatorisch berechtigte und sich meist selbst überschätzende (oder Angreifer unterschätzende) User ist in jedem Fall immer der erste Unsicherheitsfaktor und immer ein unnötiges Risiko für System und Daten.

Es gibt hier tatsächlich nur einen einzigen User, der wirklich unbeschränkten Zugang zu allen Dateien des Servers hat, und das ist ganz allein "root" des Servers. Das bedeutet, für Wartungsarbeiten oder um bestimmte anwendereigene Dateien wiederherzustellen, melde ich mich zuerst via SSH als "ich selber" am Server an, was wiederum auch nur mir wegen Key-File-Identifikation möglich ist und wechsel dann vorübergehend in den root-Account für die notwendigen Tätigkeiten. Das ein User unter seiner eigenen UserID (z.B. unter Verwendung des sudo-Kommandos) administrative Veränderungen an einem unserer Systeme durchführen darf oder Dateneinsicht außerhalb seiner Berechtigung nehmen kann ist hier ein absolutes NoGo und wird rigoros unterbunden... das gilt konsequent auch für mich selber. Ich lege unbedingt Wert darauf, dass es sowohl auf den Servern als auch auf den Client-PCs grundsätzlich keine Berechtigungen für normale User außerhalb ihres lokalen Homedirs gibt - insbesondere auch nicht mit "sudo". Das ist eine Entscheidung vor dem Hintergrund der Feststellung, dass immer nur ein berechtigter User die Sicherheit eines Systems und die Integrität seiner Daten außer Kraft setzen kann, völlig egal ob unwissend, fahrlässig oder gar vorsätzlich. Und die umfassende Verwendung von "sudo" durch Anwender erachte ich zum Beispiel als grob fahrlässig.

Ist das nicht alles sehr übertrieben für eine private EDV-Nutzung? Tja, mag sein, vielleicht, vielleicht aber auch nicht. Wer das nach Snowden, TKÜ, Ransomware, Viren, Trojanern, Ausspähung, Tracking, Programmfehlern, systematische Ausnutzung von Exploits, Backdoors, Botnets usw. wirklich meint, der soll halt keine Zeit mit Überlegungen zur Unantastbarkeit von digitaler Privatsphäre und auch nicht zur Wahrung der Integrität von System und Daten verschwenden.

Ransomware (Erpressungstrojaner)

Wie schützt man sich davor? Nun ja, auch wenn das bis heute eher ein Windows-Phänomen ist, will ich nicht irgendwann zu denen gehören, die als erste die Erfahrung machen müssen, dass diese Art krimineller Energie jetzt auch Linux erreicht hat. Dabei gibt es meiner Meinung nach einfache und durchaus wirksame Präventiv-Maßnahmen, die ausreichenden Schutz gewährleisten.

- mein Server ist ein Headless-Server (Es fehlen Bildschirm, Maus und Tastatur - eine unmittelbare Anmeldung ist regulär nicht möglich)

- es ist kein grafischer Desktop installiert

- es sind neben dem Linux-Standard (nach Installer) keine weiteren Anwenderprogramme installiert

- alle unbenötigten Services sind deaktiviert bzw. sogar deinstalliert

- per IPtables ist dem Server der Zugang zum Internet verboten (Prämisse: Es ist alles verboten, was nicht ausdrücklich erlaubt ist)

- die als HD2 eingesetzte Backup-Festplatte ist nicht per se gemountet. (Bei Verwendung muss sie zuerst mit root-Rechten gemountet werden)

- beide Festplatten HD1 und HD2 können als "Harddisk-Itself" grundsätzlich nicht von Clients gemountet werden

- normale Client-PCs haben auf der HD1 keine Zugriffsmöglichkeit außerhalb des einzigen Share-Verzeichnisses "Multimedia"

- auf der Festplatte HD1 kann von den Clients nur der Multimedia-Share gemountet werden

- auf HD1 bestehen nur Lese-Rechte

Für mich bedeutet das, eine auf einem Client laufende Ransom-Software hätte nie die Möglichkeit, die Backups auf HD1 und HD2 zu erreichen. Und weil für jeden Anwender bei seiner Anmeldung nur die eigenen Shares gemountet werden, wäre ein Schaden auf diesen Anwender begrenzt. Auf dem Server selber kann keine Ransomware laufen, da Anwender dort keine Software installieren können. Der Server kann sich nicht selber infizieren, da er nur einen stark eingeschränkten Zugriff auf das Internet hat und nur explizit ausgewählte Services installiert sind. Und als letzte Sicherheit liegt eben die schon zuvor erwähnte 2"-HD im Schließfach. Alles zusammengenommen bewerte ich für mich als eine ausreichende Sicherheit.

Mail To  (Benachrichtigungs-Emails)

Für eine kontinuierliche Kontrolle das mein Server auch das tut, was ich von ihm erwarte, halte ich es für wichtig und auch notwendig mich zu vergewissern, dass es auch wirklich so ist. Und diese Information, dass er seinen Job auch tatsächlich ordnungsgemäß verrichtet, kann man wunderbar mit Emails erreichen. Diese besondere und wegen des installierten Mailservers für mich selbstverständliche Funktion unseres Servers, und zwar das maschinelle Erstellen und Senden von Benachrichtigungs-Emails, ist jedoch möglicherweise auf einem anderen als Server arbeitenden Computer u.U.nicht selbstverständlich, denn dafür ist üblicherweise ein spezielles Programm notwendig. Auf meinem Server ist diese Funktionalität durch den installierten Mailserver und dem dadurch vorhandenen Programm sendmail ermöglicht. Mit dem folgenden Befehl kann überprüft werden, ob sendmail bereits vorhanden ist:

which sendmail

Allerdings gilt ganz allgemein die Konfiguration von sendmail als eine der kompliziertesten Linuxaufgaben überhaupt und kann deshalb natürlich nicht Bestandteil dieses Artikels sein. Und meine Lösung eines vollwertigen Mailservers ist auch ein wenig oversized, wenn tatsächlich nur eine Benachrichtigung über erstellte Backup-Archive per Email gesendet werden soll. Es gibt jedoch eine einfache Alternative und deutlich leichter zu bewerkstelligende Einrichtung dieser Funktion, mit der man sich selber eine Mailbenachrichtigung zusenden lassen kann. Hier folgend beschreibe ich kurz die Installation und Inbetriebnahme des Programms msmtp. welches mit folgendem Befehl installiert werden kann (sofern nicht schon ein anderer MTA wie z.B. Exim installiert ist).

Installation:

apt update; apt install msmtp

Mit diesen einfachen Konfigurationseinstellungen ist das Programm sofort in der Lage, eine Email zu versenden:

nano /etc/msmtprc

chown 600 /etc/msmtprc

chown root:root /etc/msmtprc

mkdir /var/log/msmtp

/etc/msmtprc:

defaults

        logfile /var/log/msmtp/mail.log

account gmx

        protocol smtp

        tls on

        tls_trust_file /etc/ssl/certs/ca-certificates.crt

        host mail.gmx.net

        auth on

        port 587

        user toml@gmx.de

        password geheimespwd

        from toml@gmx.de

account default : gmx

Die gelb markierten Felder sind anzupassen und beinhalten die Absender-Adresse sowie die Zugangsdaten zum Mail-ISP, dessen SMTP als Relayhost verwendet wird. Der Accountname gmx ist eine willkürliche Vorgabe, das bedeutet, man kann nach gleichem Muster abgegrenzt auch mehrere Accounts hier anlegen. Wird im Sende-Befehl kein bestimmter zu verwendender Account angegeben, wird automatisch der Default-Account verwendet. Nach dem Setup des Programms kann der Sendevorgang mit einem dem folgenden Befehle im Terminal getestet werden..... aber bitte nicht mit thomas@toml.de als Empfänger-Adresse:

echo -e "Subject: Test Mail $(date)\r\n\r\nTest-Mail vom:  $(date)\r\n" | msmtp --debug -t thomas@toml.de --timeout=5

echo -e "Subject: Test Mail $(date)\r\n\r\nTest-Mail vom:  $(date)\r\n" | msmtp  -t thomas@toml.de  --timeout=5

echo -e "Subject: Test Mail $(date)\r\n\r\nTest-Mail vom:  $(date)\r\n" | msmtp  -t thomas@toml.de  --account=gmx --timeout=5

ExtraBAK verwendet je nach Verfügbarkeit entweder sendmail oder msmtp. Andere Mail-Transfer-Agents werden derzeit nicht unterstützt. Der Aufruf der Programme unterscheidet sich geringfügig - siehe folgende Tabelle. Da das Senden innerhalb des Programms jedoch als eigene Funktion eingerichtet ist, sollte es auch relativ einfach sein, einen weiteren Aufruf einzubauen, wenn ein anderer MTA verwendet wird und andere Parameter erfordert.

Für beide MTAs kann in den jeweiligen ExtraBAK-Confs neben der Empfänger-Adresse "MailTo" auch eine Absender-Adresse "MailFrom" eingerichtet werden. Bei mir funktioniert es auch, wenn es keine reale EMail-Adresse ist, sie muss nur ein gültiges Aussehen (FQDN) haben. Das bedeutet, Mailfrom = xtbak@raspi3.de wird gesendet und ich sehe bei Empfang der Mail am Absender, welches Programm von welchem Rechner diese Mail gesendet hat.. Das muss aber von Fall zu Fall getestet werden, weil unterschiedliche Mail-ISP unterschiedlich restriktiv entscheiden, ob sie eine Mail senden oder als wahrscheinlichen Spam vielleicht auch direkt verwerfen.

Höhere Gewalt

Eine meiner wichtigsten Vorgaben beim Schutz unserer Daten war es, dass mir eine zuverlässige Datensicherung nicht gleichermaßen zuverlässig auch permanent Arbeit beschert. Idealerweise sollen die Prozesse unbemerkt und automatisch laufen und meine Arbeit beschränkt sich darauf stichprobenartig zu kontrollieren, dass alles wie gewünscht funktioniert. In dem die Anwender nur auf der SSD arbeiten können und die Datensicherung  automatisch nach HD1 und HD2  erfolgt, habe ich eigentlich genau das erreicht. Allerdings beinhaltet dieses System leider auch ein nicht zu unterschätzendes Risiko für Datenverlust durch höhere Gewalt. Wegen der automatischen Läufe sind in diesem Modell die beiden Backup-Medien HD1 und HD2 derzeit ununterbrochen am Server angeschlossen. Aber genau deswegen sind sie natürlich auch bei einem möglichen Blitzschlag für die hohe Energie eines Blitzes erreichbar, wenn das häusliche Stromnetz betroffen ist. Mit anderen Worten, ein Blitzeinschlag kann schlimmstenfalls alle angeschlossenen Speichermedien regelrecht grillen und in Bruchteilen von Sekunden den kompletten Datenbestand zerstören, einschließlich der Sicherungskopien.

Um diese durchaus reale Gefahr auszuschließen gibt es nur eine Möglichkeit, und zwar regelmäßig eine aktuelle Version der Datensicherung außerhalb des Hauses aufzubewahren. Welchen regelmäßigen Rhythmus man dafür wählt, entscheidet wieder die Frage nach dem Schadensmaß und wie stark die gespeicherten Daten Veränderungen unterliegen. Aber man kann sogar auch diesen Prozess automatisieren. Zum Beispiel, in dem periodisch (man muss selber festlegen, wie oft) ein verschlüsseltes Backup-Archiv z.B. auf den Webspace der eigenen Homepage hochgeladen wird. ExtraBAK unterstützt das, in dem es von einem fertig erstellten Archiv direkt eine mit AES256 oder RSA2048 verschlüsselte Kopie erstellt und diese via FTP auf einen Web-Space hochladen kann. Das geht relativ fix, ist nicht aufwendig und meiner Meinung nach absolut zuverlässig.

Eine andere Möglichkeit ist, eine kleine mobile 2,5"-Platte außer Haus aufzubewahren. Die muss natürlich durch Menschen hin und her transportiert werden und manuell auf aktuellem Stand gehalten werden. Aber, und daran gibt es keinen Zweifel, ist das tatsächliche oder auch nur empfundene Schadensmaß bei Verlust der Daten hoch, sollte man eine solche zusätzliche Aufbewahrung einrichten.

Hierzu noch ein ergänzender Hinweis: Nach meinem Kenntnisstand ist es nicht ratsam, für solch eine Außer-Haus-Sicherung USB-Sticks oder andere auf NAND-Technologie basierende Speichermedien zu verwenden. Häufige Schreibzugriffe auf einen solchen Speicher reduzieren nachgewiesenermaßen die Data-Retention, womit die Lebensdauer der Daten gemeint ist. Werden auf einem USB-Stick häufig MP3-Files gespeichert, wird man ein gekipptes Bit in einem Musiktitel überhaupt nicht bemerken. Kippt aber ein Bit in einem für die Entschlüsselung einer verschlüsselten Archivdatei notwendigen Bereich, kann es passieren, dass das ganze Archiv nicht mehr entschlüsselt werden kann - was faktisch einem Totalverlust dieses Speichermediums entspricht. Fazit: Besser für diesen Zweck keine USB-Sticks verwenden.

Stromverbrauch

Ja, ich bin der Meinung, dass man auch den Überlegungen zum Stromverbrauch durchaus ein paar Minuten Zeit opfern sollte. Unser Server läuft heute rund um die Uhr ohne Abschaltung. Das bedeutet, er verursacht damit durchgängig Energiekosten. Und als negativen Folgeaspekt bedeutet das gleichzeitig, dass er auch dann Energiekosten verursacht, wenn die Server-Dienste gar nicht genutzt werden. Wenn ich überschlägig das tägliche Wirken der Anwender im User-Zeitfenster schätze, dazu die automatischen Schedule-Jobs addiere, plus die Aktionen eines zweiten PI hinzurechne, dann glaube ich nicht, dass im Jahresmittel eine tatsächliche tägliche Server-Nutzungsdauer von mehr als 6h/d besteht. Es wird vermutlich weniger sein. Das bedeutet, es werden das ganz Jahr über mindestens ca. 3/4 eines jeden Tages Energiekosten verursacht, hinter denen keine Nutzung steht. Da die Nutzung des Servers und seiner Dienste allerdings weitestgehend willkürlich über den Tag verteilt stattfindet und insbesondere durch die Smartphones nicht vorhersagbar ist, sind 3/4 des Tages also auch Bereitschaftszeit, in der der Server auf Arbeit wartet. Ein wenig ist es so, als würde man 2 mal am Tag mit dem Auto zur Arbeit und wieder nachhause fahren und man lässt das Auto den ganzen Tag im Leerlauf laufen. Natürlich macht das kein Mensch, aber dennoch passt der Vergleich ein wenig. Aber bezogen auf den Server ist das nicht zu ändern, allenfalls durch Verzicht auf einen solchen IT-Einsatz... aber das ist wiederum für uns keine Alternative.

Am Server sind derzeit 3 externe Speichermedien permanent angeschlossen und betriebsbereit, die SSD und zwei Festplatten. Die SSD ist als primärer Speicher für "schnelle" Anwenderdaten permanent sofort verfügbar. Die beiden Festplatten wurden ausdrücklich nach der Prämisse geringer Energieverbrauch ausgewählt. Beide Festplatten führen nach einer gewissen Zeit automatisch einen Spin-Down durch und wechseln in den Sleep-Mode. Am Gehäuse der Platten (Vibration, Laufgeräusche) ist danach keinerlei Aktivität mehr wahrnehmbar. Das hat allerdings den Nachteil, dass sie 5-10 Sekunden nach dem Ansprechen benötigen, bis sie wieder bereit sind.

Weil HD2 allerdings nur ein reines Backup-Medium ohne Anwenderzugriffe ist, wird sie auch nur einmal am Tag durch ExtraBAK zur Durchführung der Backups "geweckt". HD1 wird ebenfalls mindestens einmal täglich durch ExtraBAK beim rsync-Lauf geweckt und ansonsten nur dann, wenn ein Anwender auf Multimedia-Dateien zugreift. Beide Platten verbringen deshalb vermutlich im Jahresmittel deutlich mehr als 90% des Tages im energiesparenden Sleepmode. Vor dem Hintergrund, dass die beiden Platten also eher gering beansprucht werden, ist es auch nicht störend, wenn man beim ersten Öffnen einer Multimedia-Datei ein paar Sekunden warten muss, bis die Datei "anläuft". Alle anderen Dateien jedoch, die häufig geöffnet werden, schnell geöffnet sein sollen oder mit hohem Änderungsaufkommen, werden vollständig von der SSD abgewickelt. Und an diesem Punkt ist nun meine Meinung, ein Rasberry PI als Server und eine SSD ohne Mechanik und Motoren sind zweifelsfrei hinsichtlich des Stromverbrauch die kostengünstigste Alternative. Laut Datenblatt meiner SSD wird Idle mit 0,4 W und Device Sleep mit 2 mW angegeben. Das ist für mich völlig OK.

< zurück >        < Programmbeschreibung >