Backupkonzept - Gedanken und Denkanstöße

[PROLOG]

Ich hatte hier einst über die Erstellung von Backups mit HBS3 berichtet, doch der Gedanke an Backups fängt eigentlich schon viel früher an: bei einem Backupkonzept. Denn was nützt es, wenn man sich planlos in HBS3 herumtummelt und "wild" sein Backup aufbaut, wenn man nicht weiß, wovor man sich schützen will und wie man das am besten tut, sodass schlussendlich dann doch einige Szenarien unberücksichtigt bleiben?

Bei mir ist das Thema mit der Zeit mehr oder weniger "untergegangen", wohl eher aber derart mit dem Leben verschmolzen, dass es stets mitgewachsen ist. Mittlerweile ist mein Konzept weitgehend ausgereift, zumindest wie ich finde, auch wenn immer noch eine Lücke in dem Konzept klafft, welche ich bis heute nicht geschlossen habe. Diskutiert man über dieses Konzept, würden sich sicherlich noch einige weitere Optimierungsmöglichkeiten auftun, doch wie es überall im Leben ist, kann man auch beim Backup nun mal nicht alles haben.

Im Folgenden möchte ich ein paar Denkanstöße zu wichtigen Fragestellungen beim Konzipieren der Backups geben, meine Gedanken dazu teilen und anhand meines Backupkonzepts erläutern.

[EREIGNISSE DIE EIN BACKUP ERFORDERN]

Allem voran gilt es sich Gedanken zu machen, vor welchen Situationen oder Einflüssen man seine Daten schützen möchte, denn Datenverlust droht längst nicht nur durch versehentliche Löschung oder eine defekte Festplatte. Nachfolgend beschreibe ich die Ereignisse, vor denen ich meine Daten schützen möchte, bzw. vor denen man seine Daten schützen kann.

Datenträgerausfall

Das ist sowas wie ein Klassiker, denn die meisten Leute denken bei Datenverlust vornehmlich an eine defekte Festplatte. Dabei spreche ich hier nicht von einem defekten Dateisystem, sondern von physischen oder elektrischen Schäden á la „Disk wird nicht mehr erkannt“, „Disk läuft nicht mehr an“ oder einem klassischen Headcrash.

Systemausfall

Durch den Ausfall des Systems (des NAS) droht nicht immer zwangsläufig auch ein Datenverlust, es ist gut möglich, dass das System zwar defekt, die Daten aber völlig intakt sind. Im Fall von QNAP NAS steht man allerdings vor dem Problem, dass man in der Regel nur mit einem anderen QNAP NAS wieder an die Daten kommt. Zudem kann es natürlich sein, dass durch den Systemausfall, sei es durch einen hard- oder softwareseitigen Fehler, die Daten beschädigt werden oder man einfach nicht mehr drankommt, weil z.B. die Datenträgerkonfiguration zerschossen ist.

Löschung von Daten

Hierbei spreche ich vornehmlich von versehentlicher Löschung durch eigenes Verschulden. Insbesondere von der Arbeit kenne ich es, dass Daten „einfach so verschwinden“ (natürlich immer von Geisterhand).

Änderung von Daten

Auch hierbei spreche ich vornehmlich von versehentlichen Änderungen und auch dieses Szenario kenne ich sehr gut von der Arbeit. Plötzlich ist ein Teil des Inhalts einer Datei verschwunden oder wurde mit „falschen Daten“ beschrieben und gespeichert.

Ransomware / Malware

Viren sind aus der heutigen Welt unmöglich wegzudenken. Auch wenn hierbei meist Daten verändert oder gelöscht werden, muss dies als eigenständiges Ereignis angesehen werden, denn die Folgen können sehr viel weitreichender sein, als es bei den zuvor genannten „versehentlichen Ereignissen“ der Fall war, schließlich kann eine Malware auch auf das Backup übergreifen.

Dateisystemschäden / logische Datenträgerschäden
Sei es durch Stromausfall oder wie so oft von Geisterhand: Manchmal verabschiedet sich einfach das Dateisystem oder weist Fehler auf. Nicht zwingend gehen Daten dabei verloren oder kaputt, aber es ist denkbar. Ähnlich steht es um logische Schäden an den Blöcken, welche allerdings auf einer anderen Ebene stattfinden und daher auch etwas anders zu berücksichtigen sind. Hier spielen auch „Bit-rots“ mit rein, ein Phänomen, welches auch für die Daten im Backup zu berücksichtigen ist.

Lokale Umwelteinflüsse
Ab hier kommen wir schon zu Ereignissen, die von vielen einfach nicht berücksichtigt werden. Ich spreche von Überspannung und Blitzeinschlägen, von Feuer und von Wasserschäden durch Rohrbruch oder Löscharbeiten, nicht zuletzt aber auch von Diebstahl und Vandalismus.

Also so ziemlich alle Ereignisse, die lokal auf ein Objekt wirken und eine Zerstörung der Datenträger nach sich ziehen können. Ein Backup das neben den Quelldaten steht schützt dabei wenig und selbst ein Backup in einem anderen Raum bietet unter Umständen nur bedingten Schutz.
Ein No-go nicht für dieses Szenario: Externe Datenträger dauerhaft (logisch und/oder physisch) mit dem NAS verbunden lassen.

Regionale Umwelteinflüsse

Ein bitterböses Szenario, dessen Tragweite kaum abschätzbar ist und weit hergeholt klingt, leider aber bittere Realität ist. Spätestens diese Ereignisse dürften die wenigsten User bewusst berücksichtigen. Ich spreche nicht nur von regionalen Überspannungen, sondern auch von Überflutung und Krieg, also Ereignisse, die nicht nur lokal wirken, sondern in einem größeren Umkreis. Das Stichwort dazu lautet „Georedundanz“, womit ein Wirkungsradius von bis zu 200km beschrieben ist.

Weitere / individuelle Einflüsse

Hier muss jeder den Teufel selbst an die Wand malen… wer z.B. seine Daten in der Nähe eines aktiven AKW oder in der Einflugschneise eines Flughafens lagert, sollte etwaige Risiken berücksichtigen. Insbesondere in Unternehmen spielt auch Sabotage durch vertraute Personen (Admins) eine große Rolle.

Die wichtigste Frage zu den unterschiedlichen Ereignissen lautet nun: Wie muss das Backup in seiner Gesamtheit beschaffen sein, damit die Daten vor allen Ereignissen sicher sind? Dabei dürfen die nachfolgenden Abschnitte nicht aus den Augen verloren werden, auch wenn wir sie eigentlich genau jetzt berücksichtigen müssten… eben dies macht es so kompliziert ein Backupkonzept von Grund auf aus dem Boden zu stampfen.

[BACKUPINTERVALL]

An diesem Punkt muss festgelegt werden, wie oft ein Backup erfolgen soll. Ausschlaggebend ist hier nicht nur die Häufigkeit der Änderungen am Datenbestand, sondern vor allem die Frage nach der Aktualität des Backups, sprich „Über welchen Zeitraum kann/ will ich mir einen Datenverlust erlauben?“, auch RPO genannt.

Wird ein Backup beispielsweise täglich ausgeführt, so muss man schlimmstenfalls mit einem Datenverlust von 24 Stunden rechnen. Ebenfalls entscheidend ist dabei natürlich auch der Zeitpunkt, zu dem das Backup erfolgt, in welchem Zeitraum die Daten vornehmlich bearbeitet werden und zu welchem Zeitpunkt es wahrscheinlicher ist, dass ein entsprechendes Ereignis (z.B. versehentliche Änderung) eintritt.

Klar scheint sicherlich eins: Je öfter ein Backup erfolgt, desto weniger Datenverlust muss man hinnehmen. Backup bedeutet jedoch auch Aufwand/ Kosten, sodass man gut abwägen muss, wie oft ein Backup wirklich erfolgen soll. Mit dazu gesellt sich ein weiteres Problem, denn häufige Backups bergen die große Gefahr, dass „defekte“ Dateien gesichert werden, sei es durch versehentliche Änderung oder Malware. Dies bringt uns dann auch direkt zum nächsten Punkt, bei dem wir versuchen uns davor zu schützen und kurze Backupintervalle sicherer machen.

[AUFBEWAHRUNGSFRIST UND VERSIONIERUNG]

Oft wird das Backup so betrachtet oder ausgeführt, dass es ausschließlich den Datenbestand eines bestimmten Zeitpunkts aufweist. Dies birgt, wie schon angemerkt, die Gefahr, dass bereits beschädigte Daten im Backup landen und es keine Kopie der funktionierenden Daten mehr gibt. Eine einfache Möglichkeit sich davor zu schützen sind versionierte Backups, zu denen ich hier schon berichtet hatte. Dies sorgt dafür, dass eine bestimmte Anzahl unterschiedlicher Dateiversionen vorgehalten wird, sodass neben einer defekten Datei auch immer ein oder mehrere funktionierende Dateien im Backup liegen.

Bei der Versionierung stellt sich insbesondere die Frage, wann man einen Datenverlust / Beschädigung voraussichtlich feststellen würde. Für mindestens diesen Zeitraum muss also der Datenbestand vorgehalten werden, immer in der Version zum Erstellungszeitpunkt. Auch hier gilt wieder, dass eine lange Aufbewahrung sicherlich am besten schützt - wieder verbunden mit höherem Aufwand/ Kosten, da dies auch mehr Kapazität erfordert. An dieser Stelle darf man auch nicht aus den Augen verlieren, dass der Eintritt eines Ereignisses derart ungünstig gelegen sein kann, dass bei recht später Feststellung einer Abweichung nur noch sehr alte Versionen der Daten vorhanden sein könnten.

Das ist zwar wichtig zu berücksichtigen, allerdings egalisiert es sich fast wieder von allein, denn eine späte Feststellung erfolgt meist nur bei Daten, die selten verwendet werden, sodass es unter Umständen nicht sonderlich dramatisch sein muss, wenn man nach 2 Jahren eine Datei aus einer 3 Jahre alten Sicherung wiederherstellt.

Eine Versionierung kann automatisch/ softwareseitig erfolgen, oder aber auch manuell, z.B. durch Vorhalten mehrerer Datenträger die im Wechsel für die Datensicherung verwendet werden.

[UNBRAUCHBARE BACKUPS]

Das schönste Backupkonzept hilft natürlich nichts, wenn das/ die Backups unbrauchbar sind, und das kann auf viele erdenkliche Weisen passieren. So hatte ich hier davon berichtet, wie HBS3 unbemerkt einfach nichts mehr gemacht hat und meine HBS-Backups nicht aktualisiert wurden. Ein Riesengraus: Ransomware die sich nicht nur an den originalen Daten zu schaffen macht, sondern auch auf Backups übergreift.

Es hilft auch wenig, wenn das Backup zwar intakt ist, man aus anderen Gründen aber keinen Zugriff darauf erlangt, was vor allem in Stresssituationen sehr ungemütlich werden kann. So mag eine Verschlüsselung des Backups zwar toll klingen, doch ist man auch wirklich stets in der Lage, dieses im Ernstfall zu entschlüsseln? Ein weiteres schönes Beispiel ist QuDedup, ein Containerformat welches man optional (standardmäßig eingeschaltet) in HBS3 verwenden kann, denn um auf die Daten zugreifen zu können, wird eine bestimmte Software von QNAP benötigt… und was ist, wenn diese Software nicht richtig funktioniert?

[WIEDERHERSTELLUNG]

Im Privatbereich mag es weniger von Relevanz sein, im geschäftlichen Umfeld kann es jedoch enorm wichtig sein: Die Zeit, die die Wiederherstellung (Restore) eines Backups benötigt, auch RTO genannt. Wie sich spätestens im nächsten Absatz noch herausstellen wird, wird man mit einem einzigen Backup nicht glücklich, man braucht mehrere. So unterschiedlich die Methoden auch sind, so unterschiedlich kann sich dabei auch die Zeit eines Restore gestalten. Wichtig ist dabei zu berücksichtigen, bei welchem Ereignis ein Backup greift. So ist es beispielsweise nicht akzeptabel, wenn der Restore nach versehentlicher Löschung einer Datei mehr als 3 Stunden beansprucht, weil man die Sicherungsfestplatte erstmal aus dem 150km entfernten Schließfach holen muss. Sollten die Originaldaten von einer Flutwelle weggespült worden sein, hat man sicherlich erstmal andere Sorgen, da darf der Restore später gerne auch etwas zeitintensiver sein.

[MEIN BACKUPKONZEPT - ZUSAMMENFASSUNG]

Dies alles gilt es nun zu einem Backupkonzept zusammen zu rühren, mit dem man sich persönlich für alle relevanten Situationen gut abgesichert fühlt.

Dazu habe ich es als sehr praktisch empfunden eine Matrix zu erstellen, in der dargestellt wird, mit welcher Backupmethode welche Ereignisse abgesichert werden und welche weiteren Eigenschaften die jeweilige Backupmethode aufweist.

Bei mir sieht das wie folgt aus, anhand dieses Beispiels möchte einige Überlegungen zu den vorgenannten Punkten aufzeigen. Um es etwas komplizierter zu gestalten, habe ich hier noch die Verfügbarkeit / Ausfallsicherheit mit drin, die ersten beiden Zeilen können also ignoriert werden.

Dennoch, auch wenn korrekter Weise ständig gepredigt wird, dass ein RAID kein Backup ist: Vor einem reinen Datenträgerausfall schützt ein RAID 1+ durchaus, aber auch ausschließlich davor! Dies ist hier eher von informativer Natur und sagt mir lediglich, dass ich bei einem Datenträgerausfall keines meiner richtigen Backups heranziehen muss.

001_backupkonzept.PNG

Legende zu den Symbolen in der Matrix:

x Schutz durch Maßnahme vorhanden und vorrangig von Bedeutung

o Schutz durch Maßnahme vorhanden aber nicht vorrangig von Bedeutung

(o) bedingter Schutz bzw. Schutz unter bestimmten Voraussetzungen

- kein Schutz durch Maßnahme

/ Ereignis für Maßnahme unrelevant

Im ersten Step gilt es dafür zu sorgen, dass man für jedes Ereignis mindestens eine wirksame Maßnahme hat. Dies ist für regionale Umwelteinflüsse bei mir nicht gegeben, bzw. nur unter bestimmten Umständen. Im zweiten Step stellt sich dann die Frage, wie lange man wahrscheinlich/ typisch oder schlimmstenfalls/ maximal braucht, um ein Ereignis zu bemerken und darauf zu reagieren (Reaktionszeit). Gleicht man dann diese Zeiten mit der „Rückwirkenden Verfügbarkeit“ (Aufbewahrungsfrist) ab, so sollte die Verfügbarkeit bei einer wirksamen Maßnahme immer höher sein als die Reaktionszeit. Dies ist bei mir in den gelb markierten Fällen nicht wirklich gegeben, nämlich nur für mein externes HDD-Backup, dessen Aktualität durchaus ein halbes Jahr zurückliegen kann und daher nicht optimal ist. Hier besteht eindeutig Verbesserungsbedarf, dazu läuft bereits eine Testphase.

Erläuterungen

Die Ebene beschreibt quasi die Priorität einer Maßnahme für den Restore.

So sind die Snapshots in Ebene 1 für die am wahrscheinlichsten eintretenden Ereignisse (Löschung / Änderung) heranzuziehen, da der Restore am schnellsten und einfachsten abgeschlossen ist. Außerdem können Snapshots unter Umständen auch bei weiteren Ereignissen herangezogen werden. Die externe HDD, die immer einen recht alten Datenstand hat, hat demnach die niedrigste Prio und wird nur herangezogen, wenn wirklich alle anderen Maßnahmen versagen.

Die Reihenfolge der Ereignisse sagt übrigens nichts über die Wahrscheinlichkeit des Eintritts aus, hätte ich aber sinnvoller Weise so gestalten sollen.

In der zweiten Ebene ist das NAS mit den ausgelagerten Snapshots (Snapshot Vault). Dies kann ebenfalls bei fast allen Ereignissen herangezogen werden und schützt zusätzlich vor Systemausfall (wenn die Daten dabei beschädigt oder unleserlich werden), allerdings ist dessen Aufbewahrungsfrist kürzer und die Aktualität reicht nur 24h zurück. Davon abgesehen ist der Restore ein kleines Bisschen aufwändiger. Das System steht direkt neben dem Quellsystem.

In der dritten Ebene ist mein internes Backup-NAS, welches sich im angrenzenden Gebäude zum Quellsystem befindet. Diese Maßnahme stellt im Wesentlichen eine längerfristige Versionierung bereit, schützt aber definitiv auch vor irreparablen Dateisystemfehlern, was bei Snapshots zwar auch der Fall sein sollte, ich mich hier aber nicht zu 100% darauf verlassen mag. Da es doch eine recht ordentliche räumliche Trennung gibt, kann diese Maßnahme auch bei lokalen Umwelteinflüssen schützen. Der Backup-Job ist versioniert und wird mit QuDedup ausgeführt, damit die Versionierung stets problemlos beibehalten werden kann, was bei den versionierten Backups durch Snapshots nicht der Fall ist. Der Restore dauert allerdings deutlich länger als bei den Snapshots. Die hier angegebene Dauer des Restore basiert übrigens auf einer wiederherzustellenden Kapazität von 2TB samt Vorbereitung, ist aber weitgehend geschätzt.

Die vierte Ebene ist ein externes NAS, welches eigentlich nur vor lokalen Umwelteinflüssen schützen soll. Es handelt sich um einen einfachen Sync mit direkt lesbaren Daten, denn so eine „einfache“ Sicherung habe ich bislang noch nicht, finde ich aber wichtig, denn je einfacher etwas gehalten wird, desto weniger fehleranfällig ist es auch. Momentan werden die Daten hier testweise auch noch intern mit Versionierung auf eine weitere HDD repliziert, sodass dieses Backup durchaus auch vor Änderung und Ransomware schützen kann, außerdem wird die Aufbewahrungsrichtlinie dadurch verlängert, sodass die gelb markierten "Unstimmigkeiten" wettgemacht werden.

In der fünften Ebene befindet ebenfalls ein internes Backup-NAS, allerdings nicht mit QTS als Betriebssystem und dieses System holt sich die Daten selbst von der Quelle (Pull-Sync). Dieses System soll mich vor allem unabhängig von QNAP machen, außerdem soll es in erster Linie vor QNAP-Malware schützen, da eine solche wahrscheinlich nicht auf dieses System übergreifen kann. Da die Daten direkt lesbar sind und ich lokalen Zugriff habe, ist ein Restore schneller abgetan als mit dem Backup mit QuDedup, oder mit dem externen NAS, dass ich erstmal ranholen und im LAN einbinden müsste um den Restore nicht über das Internet/ VPN machen zu müssen. Eine wichtige Gemeinsamkeit hat dieses Backup-System allerdings mit dem anderen internen sowie externen System: Keines der Systeme ist über die „üblichen“ Wege wie SMB oder FTP erreichbar, sodass eine Malware, die auf einem Rechner ausbricht, hier nicht rumtoben kann. Während die anderen beiden Systeme lediglich über den QNAP-eigenen RTRR-Dienst erreichbar sind, ist dieses System hier über gar kein Datenübertragungsprotokoll erreichbar.

Die sechste Ebene enthält mein einziges manuelles Backup und hat eine Datenintegritätsprüfung (die ich kurz „Vollbackup“ genannt habe), welches nur sporadisch erfolgt und daher bis zu 180 Tage alt sein kann, es hat eine Versionierung über mehrere Jahre, wobei ich hier aktuell nur 2 Jahre/ 720 Tage zugrunde lege, da die Versionierung noch nicht so weit fortgeschritten ist. Die verschlüsselte externe HDD wird extern gelagert, sodass dieses Backup in fast allen Szenarios herangezogen werden kann. Da der externe Standort nur wenige Kilometer von der Quelle entfernt ist, steht mir leider auch hiermit keine Maßnahme für regionale Umwelteinflüsse bereit. Diese, sowie manch andere Maßnahme mag aber immerhin bedingt geeignet sein, sodass ich mit diesem „Lag“ für die allerschlimmsten Ereignisse noch relativ gut leben kann.

Die ominöse „Zusatzebene“ (+) ist tatsächlich der Netzwerkpapierkorb, denn auch dieser kann Teil des Backup- bzw. Restorekonzepts sein. Wird eine Datei versehentlich gelöscht, kann diese einfach aus dem Papierkorb wiederhergestellt werden, dafür muss dann kein Backup angefasst werden. Einen kleinen zusätzlichen Schutz bringt der Papierkorb außerdem auch noch: Wird eine bearbeitete Datei zwischen den Backup-Intervallen versehentlich gelöscht, hat man mit dem Papierkorb die Chance wieder an diese Datei heranzukommen und die RPO für dieses Ereignis zu reduzieren. Ist primitiv, gehört aber dazu.

Natürlich kann nicht stur nach den Ebenen/ Prio eine Maßnahme für einen Restore gewählt werden, hierzu muss auch der Zeitpunkt des Auftretens eines Ereignisses berücksichtigt werden und zu welcher Zeit das entsprechende Backup erfolgte. Die Ausführung des internen und externen Backups sind daher auch gezielt um 12h versetzt, was sicherstellt, dass für die relevanten Ereignisse schlussendlich ein Datenverlust von maximal 12 statt 24 Stunden hingenommen werden muss, wenn nicht sogar noch die Maßnahmen der ersten Ebenen greifen. Die Zeit für Ebene 5 hätte ich entsprechend meiner Nutzung durchaus optimaler gestalten können, hier wollte ich das System aber zwingend nachts laufen lassen.

Bewertung des Konzepts

Ich maße mir einfach mal an, mein Konzept selbst zu bewerten um noch einmal die (mir) wichtigsten Punkte aufzuzeigen. Es macht den Anschein, als würde ich es mit insgesamt 6 Backups übertreiben, aber ich empfinde das überhaupt nicht so, denn jedes Backup erfüllt einen bestimmten Zweck, den die anderen Backups (alleine) nicht erfüllen. Sicherlich gibt es auch andere Möglichkeiten, dies einfacher umzusetzen oder zu optimieren, aber für mich ist dieses gewachsene Konzept weitgehend passend, wohl aber auch, weil ich gefühlt mit NAS um mich werfen kann und sich der finzanzielle Aufwand für ein weiteres Backup daher in Grenzen hält.

Tatsächlich ist das Konzept sogar etwas vereinfacht dargestellt, denn ich schere hier alle Daten über einen Kamm und habe zumindest bei manchen Maßnahmen andere Intervalle oder Aufbewahrungsfristen für bestimmte "Datenarten"; dies habe ich aber auch in der Spalte, die nicht auf dem Screenshot zu sehen ist, vermerkt. So habe ich z.B. keine Versionierung bei dem dateibasierten Backup mit HBS für Images meiner VM´s, da dies zu viel Kapazität benötigen würde.

Schutz vor Ereignissen:

Vor den meisten Ereignissen, vor allem vor denen, die am wahrscheinlichsten eintreten, bin ich mehrfach geschützt. Ausgenommen sind regionale Umwelteinflüsse, für die nur ein bedingter Schutz besteht, die allerdings auch am unwahrscheinlichsten sind. Es muss ja auch nicht zwingend so unglücklich laufen, dass der anrollende Panzer gleich alle beide Standorte niederstreckt. Ein Cloud-Backup würde hier einfache Abhilfe schaffen, allerdings möchte ich meine Daten bei mir haben, und nicht irgendwo anders. Alle Backup Geräte sind nur für kurze Zeit aktiv, sodass ein Übergriff durch Malware zwar geringgehalten wird, aber nicht ausgeschlossen werden kann. Für den Fall, dass es alle Systeme erwischt, hätte ich dann aber wenigstens noch das Offline-Backup in Form der externen HDD.

Multiple Backups:

Für jedes Ereignis habe ich mehrere unterschiedliche Backups. Das ist insofern wichtig, da man sich niemals auf nur ein Backup verlassen darf und dabei auch berücksichtigt werden muss, vor welchen Ereignissen das Backup schützt. Das führt dazu, dass ich so viele Backups habe. Als Vereinfachung wäre vorstellbar das externe Backup aus Ebene 4 abzuschaffen und dafür das interne Backup aus Ebene 5 extern zu platzieren und eine Versionierung einzurichten.

Aktualität:

Meine Backups sind für fast alle Ereignisse auf maximal einen Tag aktuell, lediglich die externen Backups könnten unter Umständen zu alt sein, wenn das Ereignis festgestellt wird. Allerdings muss man auch hier sehen, dass die externe HDD nur im äußersten Notfall herangezogen wird, beim externen NAS ist die Aktualität von nur einem Tag weniger dramatisch, da dies primär für lokale Umwelteinflüsse eingesetzt wird und bei einem solchen Ereignis davon auszugehen ist, dass nach dessen Eintritt keine Quelldaten mehr verändert werden, sodass dieses Backup voraussichtlich sehr aktuell sein wird, wenn es benötigt wird. Die angesetzten 21 Tage bis zur Feststellung kommen übrigens von dem Gedanken, dass ich verreist bin und z.B. Vandalismus erst nach meiner Rückkehr feststelle. Wurde mein Quell-NAS dabei zerstört, hat das externe Backup den letzten Datenstand natürlich noch vorrätig, auch wenn dieser 21 Tage alt ist.

Durch den Versatz der dateibasierten, automatischen Backups von 12h, erreiche ich kombiniert nochmals eine bessere Aktualität/ RPO für die entsprechenden Ereignisse.

Unterschiedliche Methoden / Unabhängigkeit:

Mit automatischen Backups durch Snapshots, HBS3 und dem Pull-Backup sowie einem manuellen Backup auf externe HDD kann ich sicherstellen, dass ich einem erneuten Totalausfall von HBS3 nicht zum Opfer fallen werde. Das Pull-Backup, welches lediglich auf die Erreichbarkeit der Daten angewiesen ist und im Gegensatz zu den anderen NAS mit einem anderen Betriebssystem betrieben wird, trägt nochmal dazu bei unabhängiger von QNAP Software zu werden (das hatte ich übrigens hier beschrieben).

Lesbarkeit / Wiederherstellung und Dauer der Wiederherstellung:

Mit dem externen NAS ist ein Backup vorhanden, dass vor den meisten Ereignissen schützt und direkt lesbar ist. Bei der verschlüsselten Disk im Notfall kann ich sicher sein: Das Kennwort zum Entschlüsseln kenne ich auch in der heikelsten Situation. Die Snapshots, die ebenfalls vor den meisten Ereignissen schützen sind superschnell und supereinfach wiederhergestellt. Ich muss mit meiner Aufstellung also keine Sorgen haben, dass ich an irgendwelche Backupdaten nicht drankomme - und wenn, dann habe ich ja noch weitere passende Backups, wo das garantiert möglich sein wird. Für die wahrscheinlichsten Ereignisse ist der Restore auch sehr schnell erledigt, in Ausnahmesituationen mag dies einige Stunden dauern, aber das dürfte zu verkraften sein.

Ich hatte es zwischendurch nur kurz angesprochen und auch wenn sie selten auftreten, sind sie nicht zu vernachlässigen: Bit-rots spielen im Backup eine große Rolle, denn insbesondere im Backup stellt man diese „verdrehten“ Bits und dadurch fehlerhaften Daten nicht selbst fest. Durch die üblichen, einfachen Backup-Mechanismen, bei denen nur Dateigröße und Änderungsdatum verglichen werden, kann ein Bit-rot nicht erkannt oder korrigiert werden, da die zu vergleichenden Parameter unverändert bleiben. Hierbei könnte ein Vollbackup Abhilfe schaffen, welches die Daten nochmal komplett neu schreibt ( Mavalok2 da haben wir es wieder… es macht Sinn. Du hast gewonnen. 😉 ) oder aber eine Datenintegritätsprüfung, die die Dateiinhalte auf Gleichheit prüft. Das Dateisystem kann allerdings auch etwas dagegen tun, denn ZFS und BTRFS haben eigene Prüfmechanismen, die dem vorbeugen können.

Zusammengefasst fühle ich mich damit gut abgesichert, wobei mir ein Pull-Sync beim 1. internen sowie beim externen Backup noch mehr Sicherheit geben würde, allerdings mag ich es lieber, wenn die Aufträge zentral (an der Quelle) verwaltet sind.
Der Aufand ist... naja... eigentlich recht hoch. Für meine Backups sind damit 4 weitere NAS und insgesamt 8 HDD als Datenspeicher in Betrieb, was zunächst einen hohen Beschaffungsaufwand darstellt. Wirklich teuer war es für mich nicht, denn nicht eins der NAS wurde neu gekauft, sondern immer gebraucht oder gar defekt und daher sehr günstig. Die Disks stammen weitestgehend aus dem Quellsystem und wurden zwecks Kapazitätserweiterung getauscht, weniger als die Hälfte wurde neu angeschafft.
Diesem Beschaffungsaufwand steht der Aufwand gegenüber, den ich alltäglich mit dem Backup habe, denn der alltägliche Aufwand geht gegen Null, da fast alles automatisch abläuft und nur alle paar Monate die externe Disk angestöpselt werden muss. Überwachung muss natürlich trotzdem sein, hier reicht mir meist aber ein gelegentlicher Blick in das entsprechende System bzw. die Logs, meist gibt es ja außerdem auch eine Infomail, wenn etwas nicht passt.

[TRIVIA]

Apropos „Multiple Backups“ und „Unterschiedliche Methoden / Unabhängigkeit“:

Während ich diesen Artikel verfasst habe, wollte ich doch direkt mal wieder meine externe HDD auf aktuellen Stand bringen… ich hätte es eigentlich wissen müssen: Klappt nicht, da QTS in den letzten Versionen bei manchen Modellen Probleme damit hat USB-Laufwerke zu erkennen. Gut, dass ich nicht nur die Methode „USB-Festplatte“ verwende, da hätten mir auch 5 HDD im Wechsel nichts gebracht!

Und wie es der Teufel will tritt noch vor Fertigstellung des Artikels das nächste Problem bezüglich der Thematik ein:

Seit QTS 5.0.1 habe ich immer wieder massive Probleme mit Snapshot Replika. Deren Übertragung dauert gelegentlich so lange, dass das Zielsystem vorzeitig heruntergefahren wird und die Replika fehlschlagen. Das hat zur Folge, dass für betroffene Volumes keine Snapshots mehr aufgenommen werden können und das System in einen derart desolaten Zustand verfällt, dass selbst HBS3 nicht mehr funktioniert. Immerhin funktioniert dann noch der Zugriff auf die Freigaben, sodass mein Pull-Backup weiterhin aktualisiert wird. Mittlerweile weiß ich damit umzugehen und starte das System nach dem Problem neu, glücklicherweise wird mir das Problem ja per Mail mitgeteilt, das funktioniert auch noch. Sollte das allerdings auch in Mitleidenschaft gezogen werden, so würde ich unter Umständen fröhlich und munter auf den Freigaben arbeiten und gar nicht mitbekommen, dass nur noch eins meiner Backups aktuell gehalten wird. Gut, dass ich dieses „unabhängige“ Backup habe!

Der eine oder andere wird sicherlich bemerkt haben, dass ich hier Snapshots und Syncs als Backup einsetze, obwohl immer wieder die Rede davon ist, dass solche Maßnahmen kein Backup sind, denn schließlich liegen Snapshots ja auf dem Quellsystem und ein Sync ist nun mal ein Sync und kein Backup. Tatsächlich müsste die Aussage dazu allerdings lauten, dass diese Maßnahmen allein kein Backup mit vollständigem Schutz gegen alle Ereignisse darstellen können.

Übrigens habe ich in meinem Konzept auch zu den einzelnen Maßnahmen beschrieben, wann und vor allem wie diese angewendet werden, denn nichts wäre fataler, als im Ernstfall nicht mit der Situation umgehen zu können… Stellt euch vor, es wurden versehentlich Daten verändert und nun muss die Backup-HDD ran… wie doof es wäre, wenn beim Anschließen der Disk automatisch ein Backup ohne Versionierung startet und die letzten intakten Daten überschreibt.

Kurzer Nachtrag: Am Folgetag nach der Veröffentlichung des Artikels passiert es mal wieder... Plötzlich ist eine Datei auf der Arbeit verschwunden. Nachdem die Kollegin mir den Vorfall geschildert hat, brauchte ich dank Snapshots in erster Restore-Ebene nichtmal von dem Arbeitsplatz wegtreten, sondern konnte die Datei über die "Vorgängerversionen" des Ordners direkt aus dem Windows Explorer wiederherstellen. Die RPO beträgt hier eine Stunde, die Datei wurde allerdings nicht verändert. Die RTO ist mit etwa einer Minute kaum zu toppen.

[EPILOG]

Ich hoffe, dass ich das Thema halbwegs gut durchleuchten konnte und ich ein paar Denkanstöße gegeben habe, denn über ein (mein) Backupkonzept zu berichten ist nahezu genau so kompliziert und verworren, wie die Ausarbeitung selbst, klare Vorgaben gibt es leider nicht.

Es ist aber sicherlich klar geworden, dass es niemals einen vollständigen Schutz für alle erdenklichen Situationen geben wird, vor allem da diese teilweise unschätzbare Auswirkungen und Ausmaße haben können, denn wer weiß schon, was die Ransomware von morgen alles anstellt?

Es wird auch deutlich, dass bei Backups stets die Rede davon ist, wie groß der Datenverlust sein darf, den man in Kauf nimmt und dass die Abschätzung von Wahrscheinlichkeiten für den Eintritt von Ereignissen ebenfalls eine entscheidende Rolle spielt. Dass ein Krieg ausbricht, der ausgerechnet unsere Daten in Gefahr bringt, können wir im Einzelnen nur schwer beeinflussen, über die Wahrscheinlichkeit mag ich mir aber auch kein Urteil erlauben. Gegen Ransomware können wir uns und unsere Daten aber durchaus schützen, und wenn das erfolgt ist, dann kann man das Thema „Backup“ sicherlich auch deutlich entspannter angehen. Backups sind letzten Endes Versicherungen die unverzichtbar sind, wir können aber schon vorab einiges tun, damit der Versicherungsfall möglichst gar nicht erst eintritt.

Komme was da wolle, ich fühle mich bereit und lehne mich bis dahin entspannt zurück. Da ja auch meine eigene Dummheit abgesichert ist, kann ich mir sogar ein oder zwei Kaltgetränke mehr erlauben… cheers!