Wie gut ist die Datensicherheit?

[tuep]

Hallo,

ganz kurz zu meiner Situation:
ich nutze jetzt seit einigen Jahren eine DS413 mit zur Zeit 2 Platten im SHR. Zusätzlich mache ich unregelmäßig ein Backup auf eine externe USB Platte.
Ich habe mich bis lang damit zu Frieden gegeben, dass dies schon mal wesentlich sicherer ist, als zuvor, wo ich einfach eine Datenplatte in einem Rechner hatte, ganz abgesehen von den weiteren Vorteilen einer NAS.

Mich interessiert jetzt aber noch mal genauer, wie sicher das ganze ist.

Der Impuls kam aus zwei Beobachtungen. Ich habe vor kurzem meine CDS als FLAC archiviert und gelesen, dass wohl dabei in die Dateien eine Prüfsumme geschrieben wird und man unter Linux einfach mit einem Befehl die Sammlung überprüfen kann, ob irgendwo ein Fehler aufgetreten ist. Die zweite Sache ist, dass ich festgestellt habe, dass in meiner Fotosammlung die Metadaten total im Eimer sind. Ich weiß nicht, wann und wie das passiert ist, da ich eigentlich keine Verwaltungssoftware dafür benutze. Wollte die Ordnernamen mit Datum versehen, da fiel das auf. Nicht nur sind die Daten falsch auch wurde die Kamera etc. geändert. Vermutlich liegt es entweder daran, dass ich dochmal innerhalb der letzten Jahre mal eine Fotoverwaltungssoftware genutzt habe oder es ist bei den früher häufigen verschieben der Daten passiert also von Datengrab hin zur Externen, von der Externen auf ein neues System etc. Jedenfalls ist es mir nie aufgefallen und jetzt ist es halt alles zu spät, da natürlich das Back Up zig mal überschrieben wurde.

Jetzt ist mir natürlich klar, wenn irgend eine Software schuld sein sollte, kann man nichts machen. Woher soll ja auch die Diskstation wissen, was eine intendierte Änderung und was eine Änderung durch Fehler ist.
Aber wie ist das mit dem anderen Fall. Angenommen ein Bit dreht sich um auf der Platte? Erkennt die DS das und woher weiß sie, welche Version die richtige ist. Und wenn ich eine Datei verschiebe innerhalb der DS von irgend einem externen PC aus wird da überprüft ob beim schreiben ein Fehler passiert ist. Im Ram zum Beispiel. Selbiges für die Backups auf der Platte. Wird noch mal übrerprüft, ob die Daten und das Backup tatsächlich identisch sind?

Und wenn das nicht der Fall ist, wie kann ich mich davor schützen?

 

[dil88]

Die Datensicherung erkennt in diesem Fall lediglich, dass sich die Datei geändert hat und überschreibt sie im Backup oder benennt die alte Datei um und kopiert die Neue dazu (je nach Konfiguration). Im letzteren Fall hat man zwar die Chance, sich der Sache später anzunehmen, das Backup müllt aber sehr schnell zu. Insofern ist eine Backupsoftware, die Versionen unterstützt, hierfür günstiger (z.B. das Paket Time Backup). Hier werden bei jedem Lauf alle Dateien in einem neuen Verzeichnis gesichert, wobei unveränderte Dateien lediglich durch einen Verweis (Hardlink) abgebildet werden und insofern so gut wie keinen Speicherplatz belegen. In diesem Fall kann man einfach in den alten Versionen suchen, bis man eine korrekte Datei findet, und dann diesen Stand restaurieren.

Einen ähnlichen Effekt kann man auch mit der Datensicherung erreichen, wenn man mit mehreren Platten und Backupgenerationen arbeitet. In Deinem Fall würde man dann in den älteren Backups schauen, bis man ein fehlerfreies findet.

 

[Frogman]

Das Thema der "Bitfäule" trifft allerdings sowohl RAID- wie auch Backup-Systeme. Es tritt dann immer wieder in verschiedenen Konstellationen die Frage auf, welche Dateiversion die richtige ist...

 

[dil88]

Keine Frage, das läßt sich nicht vermeiden. Der große Vorteil der Versionierung liegt für mich darin, dass einmal suchen bei einem systematischen Problem - wie oben beschrieben - reicht, während man bei haufenweise Kopien im gleichen Verzeichnis im worst case bei jeder Datei 'reinschauen und entscheiden muss.

 

[Frogman]

Ich seh da keinen Vorteil, wenn eine Versionskette durch ein gedrehtes Bit unbrauchbar geworden ist, weil's mein Backupprogramm schön sortiert übernommen hat...

 

[dil88]

Ok, dann werden wir konkreter: Bleiben wir bei Fotos (siehe Threadstart). Was ist, wenn ich die Fotos häufiger editiert habe, bevor das Unglück passiert ist? Einige Fotos vielleicht dreimal, einige einmal usw. Nun kommt die böse Software und ändert alles. Das Backup erzeugt bei manchen eine Kopie .4, bei anderen .2 usw. Nun restauriere das 'mal sauber. Habe ich Versionen oder Backupgenerationen suche ich die, die vor dem "Einschlag" erstellt wurde und restauriere die. Fertig.

 

[Merthos]

Angenommen ein Bit dreht sich um auf der Platte?

Aufgrund der hohen Datendichte auf aktuellen Platten ist das mehr oder weniger der Standardfall (Lesefehler). Sprich es wird generell schon (intern) über die Prüfsummen korrigiert.

Sollte trotzdem mal so ein Fehler auftreten (dazu muss nicht nur eines sondern mehrere Bits passend "umfallen"), erkennt das die DS im Allgemeinen nicht. Bei einigen Raid-Varianten könnte so was korrigiert werden, aber afaik erfolgt das nur bei Lesefehlern von der Platte (und die haben wir hier ja nicht). Es gibt auch einige Dateisysteme, welche zusätzlich zur Platte / Raid nochmal eigene Paritäten vorhalten und das erkennen können, aber keines auf der DS.

Oberhalb des Dateisystems kann man mit Prüfsummen (MD5 oder SFV [CRC32] sieht man häufig bei Downloads, erlauben das Erkennen) oder zusätzlich Paritätsdaten (z.B. par2 im Usenet, erlauben auch das Wiederherstellen) arbeiten.

Persönlich füge ich bei der Archivierung (z.B. eine Foto-Jahr, welches abgeschlossen ist) immer zusätzliche par2-Daten hinzu, je nach "Wichtigkeit" wenig (nur eine kaputte Datei kann korrigiert werden) bzw. bis zu 30% Redundanz.

 

[tuep]

Hmm aber das Problem bei inkrementellen Backups ist doch, dass diese auch nur eine gewisse Zeit zurückreichen.
Und ehrlich gesagt, habe ich da auch viel Bewegung. Also zum Beispiel wenn ich Fotos noch mal umsortiere, wie gerade geschehen. Dann wächst das Backup ja mächtig an. Und es werden ja auch immer wieder Abilder verworfen, um Platz zu machen.

Es ist ja auch so, dass es eventuell Jahre dauern kann, bis ich mal merke, dass etwas korrumpiert ist. Also zum Beispiel, irgendeine Datei, die ich mal im Studium erstellt habe. Wenn ich 5 Jahre später mal feststelle, dass die defekt ist, dann habe ich eventuell keine heile Version mehr und ich muss mir ja auch dann die Frage stellen, habe ich vlt. andere Dateien verloren oder sind die beschädigt. Ich kann ja nicht zig tausende Dateien durchsuchen und überprüfen. Aber generell auf eine alte Version will ich ja dann auch nicht zurück. Bei manchen Dateien sind ja auch gewollte Veränderungen durchgeführt worden.

Ich hatte gehofft, dass mit der DS vlt. sowas möglich ist, dass sie die Daten zu einem Zeitpunkt T0 einliest, von dem man ausgehen muss, dass alles in Ordnung ist, bzw. der auf Grund von Alternativlosigkeit als aktuelle Datenlage akzeptiert werden muss. Dann wird für jede Datei eine Prüfsumme erstellt. Wird die Datei von einem Programm manipuliert, dann wird die Prüfsumme aktualisiert. Dann kann die DS, falls mal fehlerhafte sektoren da sind oder die Versionen im Raid sich unterscheiden, einfach über die Prüfsumme entscheiden, welche Version richtig ist. Auch kann dann bei einem Backup überprüft werden, ob beim schreiben kein Fehler aufgetreten ist.

Ich denke der Vorteil von inkrementellen Backups liegt eher darin, wenn man Sorge hat, dass man eine gelöschte Datei vlt. doch noch mal braucht oder eine frühere Version braucht. Beim aufspüren und rekonstruieren von schreibfehlern hilft das eher wenig.

Edit: Warum ich vlt. doch auf inkrementelle Backups umschwenke: Ich habe vor einiger Zeit festgestellt, dass ein Ordner mit Fotos verschwunden ist. Ich weiß nicht, ob der gelöscht wurde oder irgendwie anders verschwunden ist. Auf jeden Fall hätte ich ihn vlt. mit so einem Backup retten können. Ändert jedoch nichts an den Bemerkungen oben.

 

[dil88]

Ich verfolge in dem Zusammenhang zwei Ansätze. Einerseits sichere ich wichtige Unikate auf alte Platten und lege sie in den Schrank. Andererseits fahre ich eine zusätzlich Backupgeneration mit eigenen rsync-Skripten, bei denen ich zunächst einen Testlauf (dry run) durchführe, anschließend die Logfiles im Detail kontrolliere und erst dann den produktiven Lauf mache, wenn alles ok ist. Klingt nach viel Aufwand, funktioniert aber in der Praxis sehr gut. Die Software, die Deine EXIF-Daten verändert hat, hätte mir dieses Backup nicht zerschießen können, es sei denn, ich hätte sie selbst ausgelöst.

 

[tuep]

Das klingt nach einem großen Materialaufwand. Den kann und will ich ungern leisten.
Ich weiß auch nicht, ob das mit dem Exif Daten wirklich an einer Software liegt. Das ist ein sehr seltsames verhalten, bei manchen Dateien wurden die Exifdaten auch anders angezeigt, nachdem ich die dateien nicht mit windows auf der nas betrachtet, sondern rüber auf einen rechner kopiert und mit linux angeschaut habe. Allerdings war das nicht bei allen so. Hab natürlich so versucht das zu retten. Wenn du dich da auskennst, gibt es vlt. die Möglichkeit bei Fotos, wo es jetzt stimmt oder die neu dazukommen das Datum und die Uhrzeit automatisch als Dateinamen zu setzen, sodass man das nachher vlt. sogar automatisiert wieder herstellen kann? Denn der Zeitstempel ist für mich eigentlich das wichitgste. Kamera Licht etc. interssiert mich nicht so.

 

[dil88]

Es ist ja auch so, dass es eventuell Jahre dauern kann, bis ich mal merke, dass etwas korrumpiert ist.

Aber diesen Punkt kann man m.E. nicht ohne einen gewissen Hardwareaufwand adressieren. Meiner besteht aktuell in einer 2TB Platte und ein paar alten 250GB Platten, die ansonsten zu nichts mehr nütze sind. Den Aufwand halte ich im Verhältnis zum Nutzen für geradezu minimal.

Um Aufnahme-Datum und -Zeitpunkt in den Dateinamen zu übernehmen, nutze ich unter Windows exiftool und folgendes cmd-Skript:

@ECHO OFF
SETLOCAL
IF "%1" == "" (
  ECHO Es wurde kein Verzeichnis uebergeben, es wird f:\photo verwendet.
  SET pfad="f:\photo"
) ELSE (
  SET pfad="%1"
)
C:\Users\xyz\bin\exiftool.exe -P "-FileName<DateTimeOriginal" -d %%Y-%%m-%%d_%%H%%M_%%%%f.%%%%e %pfad%
PAUSE

Man kann einen Pfad übergeben. Tut man es nicht, wird ein Standardpfad im Skript verwendet.

 

[tuep]

Aha andersrum geht das wahrscheinlich auch oder?
Also durch den Dateinamen Datum definieren.

Danke auf jeden Fall für eure Einblcike.

 

[dil88]

Exiftool ist ein ziemlich fettes Ding. Ob es aus Dateinamen direkt EXIF-Daten extrahieren kann, da wäre ich mir nicht so sicher, aber mit einem Skript sollte das ggfs. kein Problem sein. Hier die Dokumentation von exiftool.

 

[Frogman]

Hier gibt's einen Hinweis dazu...

 

[JoGi65]

Sollte trotzdem mal so ein Fehler auftreten (dazu muss nicht nur eines sondern mehrere Bits passend "umfallen"), erkennt das die DS im Allgemeinen nicht.

Wie ist das genau zu verstehen? Meinst Du auf zwei Platten gleichzeitig?

 

[Merthos]

Eine Platte liest immer ganze Blöcke, welche auch Paritätsdaten enthalten. Es müssen also mehrere Bits in einem Block kaputt sein und das auch noch in einer richtigen Kombination, damit die Platte das nicht schon selbst als Fehler erkennt.

 

[JoGi65]

Wie ist das dann mit der Angabe von den generellen Lesefehlern von den Platten - Error rate non-recoverable zB 1/10 hoch 14 bit read.
Sind das die Fehler, die nicht ausgeglichen/erkannt werden? Greift dann da übergeordnet das Raid 5(zB) oder nicht?

 

[Merthos]

Ja und ja (wenn man ein Raid hat).