Datenverlust bei Raid 1 inkl. USB Backup. Möglich?

[mrieglhofer]

Ein Fall, der mich nicht betrifft, aber interessiert.

Ein Laie hat mir berichtet, das in ihrer Firma alle Daten verloren gegangen seien, da das Raid durch einen Systemfehler gelöscht wurde und die angeschlossene USB Festplatte beim nächsten Backup ebenso.
Mein erster Gedanke war, das gibt es so nicht. Nach Durchspielen aller Konstellationen bin ich mir nicht mehr so sicher,

Denkbar wäre:
1) eine Kontrollerfehler, der das Volumen korrumbiert oder zerstört.
2) Das Backupsystem stellt fest, dass die Daten weg sind und löscht alle Shares.

Meine Bedenken:
Wenn das Volumen nicht lesbar ist,darf doch die Backup-Software den Job nicht mehr ausführen. Am Web Interface klar, aber in den Systemtiefen bin ich mir nicht sicher.
Wenn das Volume lesbar ist, müsste ein Softwarefehler die Shares entfernt haben. Dann dürfte aber die Backup Software auch den Job nicht mehr durchführen.. Ist das so?

Wenn das passieren könnte, dann wären die Optionen:" Gesicherte Dateien immer beibehalten" die einzige Rettung davor. Bei mir eh immer ein.
Die Option "Externes Geräteziel nach Sicherung auswerfen" würde auch helfen, ist aber im autonomen Betrieb nicht gangbar.

Klar, dass ein zweites Backup an einem anderen Standort bzw. das Trennen der Backupplatten für einen sicheren Betrieb ein wichtiges Thema ist. Aber ich denke, dass viele Leute ihre NAS wie oben geschildert betreiben.

Weitere Informationen habe ich nicht, hoffe aber , sie zu bekommen. Aber vielleicht ist so etwas schon jemanden passiert oder jemand hat das mal im Rahmen eines Notfallplanes durchgespielt. Da wäre ich für Erfahrungen dankbar.

 

[dil88]

Es gibt verschiedene Szenarien, die beim von Dir geschilderten Setup zu diesem katastrophalen Ergebnis führen können. Du hast einen "single-point-of-failure", also eine Einheit, die insgesamt gestohlen oder zerstört werden kann. Und Du hast ein automatisches Backup, was auch dann läuft, wenn man eigentlich schon wissen könnte, dass da etwas kaputt gegangen ist. Ein "Gesicherte Daten immer beibehalten" ist für mich keine Lösung, denn damit erhalte ich mir in meinem Backup mit viel Mühe gelöschte Dateien und damit letztlich ein für mich inkonsistentes Backup. Meine Lösungen sind Backup räumlich getrennt lagern (kann auch nur eine USB-Platte sein, die aber eben nicht an der DS verbleibt), nicht nur automatische Backups und Versionierung. In diesem Thread findest Du eine ganze Menge Ideen und Konzepte zum Thema Backup.

 

[Aevin]

Hi mrieglhofer,

dieses Problem ist mir fast genauso schon passiert in der Vergangenheit.
Ein Raid ging "flöten", ich habe es dann neu erstellt, alle Ordner neu angelegt und begonnen die einzelnen Backups zurückzuspielen.
Genau in dieser Zeit begann aber ein weiterer zeitlich festgelegter Backupjob Daten auf dem Backuplaufwerk zu löschen, da ja mein "neu" erstelltes Raid noch ziemlich viele leere Ordner hatte.

Ich weiß nicht ob dies immer noch so passieren kann, aber wenn eine Rückspielaktion läuft, sollten automatisch alle anderen Backupjobs auf "Stopp" stehen bleiben.

Wohl gemerkt es geht um die interne DS-Version der Backups, also keine externen Backupprogramme.

 

[mrieglhofer]

@dil88:
Kann ich dir nur zustimmen. Single Point of failure ist klar, Brand, Blitzschlag, Diebstahl, für eine Firma wäre es fahrlässig.
Ich habe auch 2 Disk, die ich räumlich getrennt lagere und austausche.
Aber mir ging es eigentlich darum, bei welchen Szenario ein NAS ohne Benutzereingriff das Backup zerstören kann.

@Aevin:
Das Szenario kann ich nachvollzieren. Ist aber keine Fehlfunktion des Gerätes, sondern des Bedieners . Auch wenn ich mir das gut vorstellen kann, dass man vergisst, die automatischen Backups abzustellen. Ich denke, dass ich mir das auf meinen persönlichen Disaster Recovery Zettel draufschreiben werde.

 

[Aevin]

@Aevin:
Das Szenario kann ich nachvollzieren. Ist aber keine Fehlfunktion des Gerätes, sondern des Bedieners . Auch wenn ich mir das gut vorstellen kann, dass man vergisst, die automatischen Backups abzustellen. Ich denke, dass ich mir das auf meinen persönlichen Disaster Recovery Zettel draufschreiben werde.

Na so einfach laß ich das mal nicht stehen, ein Fehler des Bedieners ist es meiner Meinung nach nicht. Es ist ein und die selbe Software und da es um eine Backupfunktion geht, MUSS die Software bei Restoreschritten ihre andere Funktion außer Betrieb nehmen... Meiner Meinung nach ganz klar ein Softwarelogikfehler.

Aber kannst glauben, passiert mir kein 2. Mal.

 

[mrieglhofer]

An sich eh egal, ich hätte an das auch nicht gedacht und habe mir das jetzt zu meinem Disaster Recovery Doku dazugeschrieben.

Ich gebe dir absolut Recht, dass angesichts der Zielgruppe der Syno durchaus solche Prüfung erwartbar sind. Andererseits aus der alten NAS Zeit hat ja der Bediener alles genau bestimmt. Und dem Linux ist dass ja völlig egal, ob die Software A gerade was tut, während ein Cron Job die gleiche Software was anderes tun lässt. Daher ist es für mich klar, dass das System so reagiert, auch wenn es nicht unbedingt wünschenswert ist. Aber ich danke für die Erfahrung, mir wäre das sicher auch passiert.

 

[dil88]

Aevin hat natürlich recht. Aber Abhilfe für das Szenario, dass automatisiert fehlende oder kompromittierte Daten vorhandene Backupdaten löschen, ist das auch nicht.

@mrieglhofer: Auf diesen Punkt bin ich ja auch eingegangen: Wenn man ein manuelles Backup fährt, kann das nur passieren, wenn man es nicht mitbekommt. Kombiniert man dies mit einem dry-run, den man protokolliert und überprüft, ist man schon sehr sicher. Ein Backup mit Versionierung ist die Alternative bzw. eine gute Ergänzung.

 

[mrieglhofer]

@dil88:
Klar, wenn der Operator vor Ort ist oder das ein privates NAS ist, ist manuelles Backup durchaus eine sinnvolle Lösung.

Das Problem sehe ich, und im konkreten Fall war es offensichtlich so, dass der Admin irgendwann das System so einstellt, dass es es täglich automatisch ein Backup erstellt. Einfach deshalb, da der ja alle paar Wochen oder bei einer Fehlermeldung einsteigt und am System arbeitet. Ich selbst habe auch 2 solche Installationen laufen. Sonst müsste man ja täglich einmal einsteigen, die Daten kurz checken und dann manuell das Backup starten.

Aber der Hinweis mit der Versionierung, die ja seit der letzten DSM Version unterstützt wird, ist gut. Das werde ich mir mal sicherheitshalber auch anschauen. Bisher habe das ignoriert, weil da der benötigte Speicherplatz natürlich ansteigt und ich derzeit auch im Backup gleich große Platten wie im NAS habe.

Offen bleibt trotzdem die Frage, ob ein Backup durchgeführt wird, wenn das Volume oder der Share gar nicht vorhanden ist. Beim Share kann ich das ja mal testen, beim Volume eher schwieirg ;-)

EDIT:
Ich habe jetzt einen Share angelegt, gesichert und danach gelöscht.
Wenn man jetzt das Backup laufen lässt, bricht es mit der Fehlermeldung ab: Backup Folder <Name> failed. (The Folder doesn't exist. Please check aour backup configuration).
Dies tritt auch auf, obwohl ich die Beibehaltung der gesicherten Daten nicht angeklickt hatte.

Daraus folgt: durch Löschen oder Zerstören eines Share kann das nachfolgende Backup nicht gelöscht/zerstört werden. Daraus folgt für mich auch, dass zumindest bei Synology auf Share Ebene ein Szenario wie im Eingangspost beschrieben, nicht auftreten kann. Nehme an auch nicht, wenn das Volume fehlt, weil da je die Shares auch nicht mehr vorhanden sind.

 

[dil88]

Versionierung gibts mit dem Paket Time Backup ja schon länger.

 

[mrieglhofer]

Man lernt nie aus. Ich dachte immer, dass das die Time Machine für Macs ist und habe mir das noch nie genauer angeschaut ;-)
Schaut recht vernünftig aus. Allerdings hatte ich in den letzten 10 Jahren noch nie den Fall, dass jemand die letzten Versionen gebraucht hätte. Aber gerade an Dokumenten, die gemeinsame bearbeitet werden, ist so eine Versionierung ideal.