Linux Linux Server - SSD "ab-ge-raucht" oder doch anderes Problem?

[Tetradrachm]

Servus...

ich bin kein Linux Profi und brauche daher bitte Eure Hilfe. Ich versuche mal alles am besten zu umschreiben, damit Ihr Euch ein Bild machen könnt. Ich habe einen kleinen Rechner gekauft - meines Wissens ist es so ein ARM Rechner - ähnlich dem Raspery - nur jedoch mit größerer Platine (microATX), echten RAM Riegeln, passiv gekühlt. Als Speicher dient eine PCIe NVMe 2 TB SSD. Diesen Rechner betreibe ich als Server - installiert habe ich ein Linux Ubuntu (aktuellste Version).

Erstes Problem.

Dieser kleine Server dient für eine Gruppe von kreativen Künstlern als Workspace hier bei mir. Es sind verschiedene Benutzer eingerichtet, verschiedene Rechte des Zugriffes auf Ordner und freigegebene Netzlaufwerke - was alles einwandfrei funktioniert hat - bis heute Morgen. Seitdem kann ich den "Server" Rechner nicht mehr hoch fahren.

Ich habe Euch mal zwei Bilder angehängt - diese Meldung kam heute Vormittag.

1. Dann habe ich mal gewartet bis heute Nachmittag. Wenn ich den Rechner nun anschalte, dann kommt gar nichts mehr - als nur das Bild des Start-BIOS und dann nur noch ein blinkender Cursor. Sonst gar nichts.

2. Dann habe ich mal testweise die SSD ausgebaut - dann startet wenigstens der Rechner, bringt aber, dass er kein Betriebssystem hat, das er booten kann. Aber immerhin kommt eine Fehlermeldung bei ausgebauter SSD, anstatt wie bei (1) nur der blinkende Cursor.

3. Da ich für mich paar Daten brauche, dachte ich, probiere doch mal aus die SSD in ein T490s zu brauen und zu booten. Dachte das klappt mit Linux so einfach die SSD in einen anderen Rechner und starten. Tut es aber nicht - es kommen Meldungen wie fehlendes ACPI (oder so ähnlich) und ich soll ein manuelles fsck laufen lassen. Aber da traue ich mich erst mal nicht weiter - daher habe ich da jetzt mal nicht weiter gemacht.

* Ok - das ist der Stand des Rechners / Servers mit der SSD. Könnt Ihr bereits da was erkennen was schief gelaufen ist oder läuft?

* Da ich an die Daten heran kommen sollte - überlege ich mir einen PCIe NVMe USB Adapter zu kaufen um die SSD auszulesen. Kann ich die SSD einfach an einen Windows oder Mac Rechner anschließen und die Daten auslesen?

So und jetzt kommt das zweite Problem!

Daten von der SSD auslesen? Hast Du etwa kein Backup Deiner Daten? Doch!

Ich habe an den Linus Rechner / Server eine externe USB HDD angeschlossen. Ubuntu Linux bietet ein eigenes Backup Programm an, dass selbständig die Daten vom Rechner auf ein anderes Medien sichert. Das habe ich auch gemacht! Aber - ich weiß nicht 100% auch seit heute - die externe HDD ist auf einmal leer! Das ist ganz komisch.

Auf der externen HDD gibt es einen Order "linuxserver" (das ist der Rechnername) mit einem TimeStamp vom Dezember 2022. An dem Tag habe ich das erste Mal das Linux Backup Tool gestartet und dabei hat es diesen Ordner erzeugt. Und in diesen Ordner hinein macht das hauseigene Ubuntu Backup Tool ja die Backups. Und ich habe auch immer wieder mal die externe HDD kontrolliert! Und die Ordner waren da! Ich kann nicht sagen ob wirklich immer alles gesichert wurde bis zur letzten Datei - aber unter "linuxserver" waren einzelne Backup Ordner mit meinen ganzen Ordnern und Dateien! Und jetzt - ist nur noch der leere Ordner da!

Also das ein backup nur teilweise gemacht wurde oder einzelne Dateien nicht vorhanden mag alles vorkommen - aber der Linux Server, respektive das Ubuntu backup Programm, löscht doch nicht in dem Haupt-Backup-Ordner auf einmal alle Inhalte!?!

* Entweder Ihr sagt mir jetzt - dass ich mit einem Windows bzw. Mac Rechner auch gar nicht die Ordner und Dateien sehe wenn ich auf die externe HDD anschließe. Das ich dafür Linux benötige.

* Oder ich weiß auch nicht. Man könnte fast meinen - jemand hat auf die externe USB HDD zugegriffen und unter dem Backupordner alle Dateien per Hand gelöscht!? Also ich habe noch nie erlebt, dass ein Backup Programm Ordner und Dateien gelöscht hat - aber den "Ober-Ordner" übrig gelassen hat. Da müsste doch die ganze externe HDD verkorkst sein?



Ok. Ich bitte um Hilfe. Hat jemand Tipps wie ich bei dem Linux Rechner / Server am besten vorgehe? Kann jemand den Log lesen? Kann ich die SSD in ein Thinkpad einbauen zum Testen? Soll ich die interne Linux SSD an einen USB NVMe Adapter anschließen und versuchen mit meinen anderen Rechnern darauf zuzugreifen?

Was ist mit der externen Backup HDD passiert? Kann sich jemand vorstellen was da passiert sein könnte? Dass die SSD heute ausfällt und gleichzeitig auf der externen HDD auf einmal der Oberordner noch da ist aber die Unterordner alle gelöscht - finde ich einen ziemlich komischen Zufall.


DANKE!

 

[zwieblum]

Mach' bitte einenen 1:1 Mirror mit Software-RAID ... und Backups.

 

[cuco]

So ist es, für so wichtige Dinge ist die Datenverfügbarkeit wichtig (RAID) und ebenso die Datensicherung (Backups). Und bei letzterem ist auch besonders die Integrität (Unveränderlichkeit des Backups) wichtig.
Für die Datenverfügbarkeit also durch z.B. ein RAID vorsorgen.
Backups sprechen für sich selbst. Muss aber unbedingt auch mal getestet werden - Schrödingers Backup, bei dem man erst im Ernstfall feststellt, ob es eigentlich geklappt hat, ist kein richtiges Backup.
Aber Integrität der Backups ist noch wichtig. Hier mal Beispiele, die häufig gemacht werden, aber alle ein Problem haben:
- Ich nehme einen Datenträger meiner Wahl (z.B. externe HDD), mache ein Backup drauf. Wenn ich das nächste Backup machen will, lösche ich zunächst das alte um Platz zu schaffen, dann mache ich das neue. Falsch: In der Zeit zwischen Löschen des alten Backups und der Erstellung des neuen Backups hast du keines mehr. Schlägt bei der Erstellung des neuen etwas fehl, hat man verloren.
- Ich nehme einen Datenträger meiner Wahl, stecke ihn in den PC und lasse laufend aktuelle Backups darauf spielen. Falsch: Ich brauche unbedingt ein Offline-Backup - ansonsten kann z.B. ein Verschlüsselungstrojaner das Backup gleich live mit verschlüsseln oder auch ein Blitzschlag vernichtet meinen Server und das Backup-Medium gleichzeitig.
-> Daher: 3-2-1-Regel bei Backups betrachten - das bedeutet: 3 Kopien der Daten (1x original, 2x Backup) auf 2 unterschiedlichen Medien (z.B. original auf SSD, Backups auf HDDs), davon 1 an einem anderen Ort (also mindestens eines der beiden Backups physisch getrennt an einem anderen Ort vom Original oder anderen Backup aufbewahren, z.B. in der Cloud oder bei den Eltern, ...)

 

[hikaru]

-> Daher: 3-2-1-Regel bei Backups betrachten - das bedeutet: 3 Kopien der Daten (1x original, 2x Backup) auf 2 unterschiedlichen Medien (z.B. original auf SSD, Backups auf HDDs), davon 1 an einem anderen Ort (also mindestens eines der beiden Backups physisch getrennt an einem anderen Ort vom Original oder anderen Backup aufbewahren, z.B. in der Cloud oder bei den Eltern, ...)

Eigentlich müsste es "4-3-1" heißen, denn um das Offsite-Backup zu aktualisieren muss ich es vorübergehend aus seiner Backuprolle entnehmen:
1. Entweder muss ich die HDD mit dem Off-Site-Backup von meinen Eltern zu mir nach Hause mitnehmen, wo es wie die Arbeitsdaten und das On-Site-Backup Gefahr läuft durch eine Katastrophe (z.B. Hausbrand) zerstört zu werden, oder
2. neue Daten zu meinen Eltern transportieren, wobei aber ein inkrementeller Austauschdatenträger während des Transports ein Single Point of Failure ist und die Konsistenz zwischen Arbeitsdaten/On-Site-Backup und Off-Site-Backup nicht mehr gegeben ist, oder
3. ein Cloud-Backup zur Aktualisierung vorübergehend an meine lokale Infrastruktur anbinden, wobei es wie die heimgeholte HDD aus 1. Gefahr läuft kompromittiert zu werden.

Alle drei Szenarien lassen sich abwenden, wenn ein viertes Vollbackup als zweites Off-Site-Backup zum Einsatz kommt, welches immer abwechselnd mit dem 1. Off-Site-Backup vollständig getauscht, und während der Aktualisierung gegen die Arbeitsdaten auf Konsistenz geprüft wird.
Wenn ich nämlich gerade das 1. Off-Site-Backup zu Hause/Online habe um es zu aktualisieren und mir währenddessen die Bude mit Arbeitsdaten, On-Site- und Off-Site-Backup abbrennt, dann habe ich immer noch das zweite Off-Site-Backup sicher, wenn auch möglicherweise etwas veraltet.

Aus Sicherheitssicht könnte man noch am ehesten auf das On-Site-Backup verzichten, nicht aber auf das zweite Off-Site-Backup. Das On-Site-Backup dient eigentlich nur der Bequemlichkeit, weil es im Backupfall einfacher erreichbar ist als die Off-Site-Backups.

 

[cuco]

Die 3-2-1-Regel ist gängige Empfehlung, basiert jetzt aber auch nicht auf Wissenschaft, sondern auf der Empfehlung eines einzelnen Fotografen. Als Richtwert schon ziemlich gut, außerdem leicht zu merken und verdeutlicht die Probleme die viele in ihrer Backup-Strategie haben. Aber klar, je nach Anforderungen an die Verfügbarkeit der Daten kann auch eine andere Strategie Sinn ergeben.

Zu deinen Punkten würde ich aber sagen, dass sie durch 3-2-1 schon gar nicht schlecht abgedeckt sind:
1.) Wenn ich den Datenträger mit einem der zwei Backups von meinen Eltern mit zu mir nehme, wo auch das andere Backup und die Originaldaten liegen, verletze ich die 1 in 3-2-1, denn nun habe ich keine Kopie mehr an einem weiteren Ort. Wenn ich die Regel einhalten will, muss ich also stattdessen das zweite Backup mit zu meinen Eltern nehmen. Dann sind Originaldaten und Backups weiterhin an zwei unterschiedlichen Orten. Im Anschluss kann ich aber natürlich das ältere der zwei Backups gleich wieder zu mir mitnehmen.
2.) Inkrementelle Backups kann man natürlich machen, aber das reine Inkrement ist kein eigenes Backup. Während ich also ein Inkrement mit zu meinen Eltern nehme, habe ich keinen SPOF, da das Backup bei meinen Eltern ja trotzdem erst einmal noch okay ist, nur halt nicht mehr brandaktuell. Kommt mein Inkrement unterwegs weg, habe ich immer noch das ältere Backup bei meinen Eltern und das aktuellere Backup bei mir. 3-2-1 wird dabei nicht verletzt, und da das Inkrement kein eigenes Backup ist, bin ich auch nicht bei 4-3-1, sondern immer noch bei 3-2-1.
3.) Klar, während ich ein Backup mache, ist genau dieses bzw. genau dieser Datenträger gefährdet. Entweder nehme ich das in Kauf und vertraue auf das zweite Backup im Fall der Fälle - oder ich habe halt während bzw. kurz nach der Erstellung tatsächlich 4-3-1, bis ich das nun unnötige alte Backup lösche und damit wieder auf 3-2-1 reduziere.

Das soll nicht heißen, dass 4-3-1 jetzt falsch ist. Im Gegenteil, natürlich besser als 3-2-1. Man könnte sogar noch überlegen, ein 4-3-2 daraus zu machen bei dir. Aber wie gesagt, das hängt auch von den Anforderungen ab. Und der Datenmenge. Und dem Budget. Grundsätzlich ist jedes Backup besser als keines und 3-2-1 schon eine sinnvolle "Grunsicherung" für alle Daten, egal ob im privaten oder unternehmerischen Umfeld. Alles darüber kommt eben drauf an, wie wichtig meine Daten sind und wie sehr ich schwarzmale
Habe aber gerade mal überlegt, für einige Daten komme ich auch auf (mindestens) 4-3-2. Beispielsweise Daten auf PC/Laptop, die gelegentlich auf den Heimserver gesichert werden. Und da der wiederum in der Cloud sowie auf Band gesichert wird, komme ich schon unabsichtlich auf 4-3-2. In der Regel nutze ich aber auch nur 3-2-1, sonst wird es bei meinen Datenmengen auch schwer bezahlbar.

 

[Ambrosius]

Das erinnert mich an stark an Zen and the Art of IT Backup

Kennt das wer?

 

[hikaru]

Wenn ich die Regel einhalten will, muss ich also stattdessen das zweite Backup mit zu meinen Eltern nehmen. Dann sind Originaldaten und Backups weiterhin an zwei unterschiedlichen Orten. Im Anschluss kann ich aber natürlich das ältere der zwei Backups gleich wieder zu mir mitnehmen.

Ja, das ist dann äquivalent zum Fall "2x Off-Site-Backup ohne On-Site-Backup".

Während ich also ein Inkrement mit zu meinen Eltern nehme, habe ich keinen SPOF, da das Backup bei meinen Eltern ja trotzdem erst einmal noch okay ist, nur halt nicht mehr brandaktuell. Kommt mein Inkrement unterwegs weg, habe ich immer noch das ältere Backup bei meinen Eltern und das aktuellere Backup bei mir. 3-2-1 wird dabei nicht verletzt, und da das Inkrement kein eigenes Backup ist, bin ich auch nicht bei 4-3-1, sondern immer noch bei 3-2-1.

Hier nimmst du an, dass du eine Kompromittierung des Inkrements zuverlässig erkennen kannst. Das ist aber ein Trugschluss. Wenn dein Inkrement zwischen seiner Erstellung und der Übertragung auf das Off-Site-Backup still kompromttiert wird, es also augenscheinlich funktioniert, aber nicht die Daten enthält die du erwartest, dann kompromittierst du damit auch dein Off-Site-Backup. Und da du nie direkt zwischen Arbeitsdaten und Off-Site-Backup direkt prüfst, sondern immer über den Mittelsmann des Inkrements, fällt das möglicherweise nie auf.
Ersetzt du das Inkrement hingegen durch ein weiteres Vollbackup, dann fällt dir die Kompromittierung spätestens beim übernächsten Austausch auf, wenn du das dann zurückgetauschte Vollbackup direkt mit deinen Arbeitsdaten abgleichst.

Fazit:
Backups immer direkt von den Arbeitsdaten ziehen, nie von einem anderen Backup, denn Backupfehler pflanzen sich fort!

 

[zwieblum]

Und da du nie direkt zwischen Arbeitsdaten und Off-Site-Backup direkt prüfst, sondern immer über den Mittelsmann des Inkrements, fällt das möglicherweise nie auf.

Hatte da mal einen Bekannten, der jahrelang seine Backups auf DAT-Bänder sicherte, jede Woche. Nach ein paar Jahren brauchte er dann eine Datei - und stellte zu seinem Entsetzen fest, dass die Bänder recht jungräulich waren

 

[cuco]

Ja, das ist dann äquivalent zum Fall "2x Off-Site-Backup ohne On-Site-Backup".

Ja, für den kurzen Moment hast du beide Backups an einem Ort, bis du den alten Datenträger wieder mitnimmst. Ist aber ja nicht schlimm, schließlich hast du deine Originaldaten an einem anderen Ort und damit die Georedundanz gewahrt.

Hier nimmst du an, dass du eine Kompromittierung des Inkrements zuverlässig erkennen kannst. Das ist aber ein Trugschluss. Wenn dein Inkrement zwischen seiner Erstellung und der Übertragung auf das Off-Site-Backup still kompromttiert wird, es also augenscheinlich funktioniert, aber nicht die Daten enthält die du erwartest, dann kompromittierst du damit auch dein Off-Site-Backup. Und da du nie direkt zwischen Arbeitsdaten und Off-Site-Backup direkt prüfst, sondern immer über den Mittelsmann des Inkrements, fällt das möglicherweise nie auf. Ersetzt du das Inkrement hingegen durch ein weiteres Vollbackup, dann fällt dir die Kompromittierung spätestens beim übernächsten Austausch auf, wenn du das dann zurückgetauschte Vollbackup direkt mit deinen Arbeitsdaten abgleichst.

Also erstens ist die Kompromittierung eines Backups kein Problem von Inkrementen, sondern von allen Backups und allen Backupformen, daher sollte man dafür immer Vorkehrungen treffen (z.B. durch Checksummen) und zweitens prüfst du nie gegen die Arbeitsdaten, denn die können sich seit der Erstellung des Backups längst verändert haben. Daher ist für deinen angenommenen Fall mit dem Inkrement kein Unterschied zu machen. Entweder der Fall würde auch beim Vollbackup auftreten und nicht nur beim Inkrement oder dein Inkrement ist genau so "geschützt", dass du auch dort Veränderungen erkennen würdest.

Fazit:
Backups immer direkt von den Arbeitsdaten ziehen, nie von einem anderen Backup, denn Backupfehler pflanzen sich fort!

Gut, klar, wobei das bei ausreichenden Checks (Checksummen) nicht so kritisch ist. Backups vom Backup ziehen ergibt aber durchaus trotzdem Sinn und wird auch häufig gemacht, nämlich um alte Backups auf alten Backupmedien mal auf "frische" Medien umzukopieren. Damit nicht irgendwann auffällt, dass die 10 Jahre im Schrank liegende HDD gar nicht mehr anläuft, die 5 Jahre im Schrank liegende SSD alle Daten vergessen hat (Flash-Speicher ist ohne Stromversorgung langfrisitig ggf. flüchtig!) oder die Bandsicherung gar nicht mehr eingelesen werden kann, weil das Laufwerk den alten LTO-Standard gar nicht mehr liest.

 

[hikaru]

Also erstens ist die Kompromittierung eines Backups kein Problem von Inkrementen, sondern von allen Backups und allen Backupformen, daher sollte man dafür immer Vorkehrungen treffen (z.B. durch Checksummen)

Die Nutzung von Inkrementen führt aber eine zusätzliche Fehlerquelle ein. Wenn ich von meinen Arbeitsdaten ein Inkrement ziehe um es auf mein Off-Site-Backup zu übertragen, dann habe ich ein Backup, aber zwei potenziell fehlerbehaftete Kopiervorgänge (Arbeitsdaten -> Inkrement, Inkrement -> Backup). Ersetze ich das Inkrement hingegen durch ein zweites Vollbackup, welches ich jeweils gegen das erste Backup austausche, dann habe ich immer noch zwei Kopiervorgänge (Arbeitsdaten -> Backup1, Arbeitsdaten -> Backup2), aber auch zwei Backups.
Durch die Nutzung eines zweiten Vollbackups statt eines Inkrements kann ich also praktisch kostenlos (im Sinne des Aufwands) die Redundanz um N+1 erhöhen. Ich finde das ist ein echtes Schnäppchen.

und zweitens prüfst du nie gegen die Arbeitsdaten, denn die können sich seit der Erstellung des Backups längst verändert haben.

Den Diff zwischen Arbeitsdaten und Backup kann ich aber einfach auf Plausibilität prüfen. Hänge ich ein Inkrement dazwischen, dann verdreifacht sich der Aufwand, denn ich muss nun 1. Arbeitsdaten gegen Inkrement, 2. Inkrement nach der Erstellung aus Arbeitsdaten gegen Inkrement vor der Übertragung auf's Backup und 3. Inkrement gegen Backup prüfen.

Backups vom Backup ziehen ergibt aber durchaus trotzdem Sinn und wird auch häufig gemacht, nämlich um alte Backups auf alten Backupmedien mal auf "frische" Medien umzukopieren.

Ja, aber das ist dann eben kein Backup der "echten" Arbeitsdaten sondern ein Backup vom Backup, mit allen im Quellbackup enthaltenen Fehlern.
Das kann man machen und es gibt gute Gründe das zu tun, aber man sollte sich eben des Details bewusst sein, dass es eine Kopie einer Kopie ist. Das bedeutet im einfachsten Fall erhöhten Prüfaufwand (der sich aber gegenüber einem erneuten Backup aus Arbeitsdaten lohnen kann), im schlimmsten Fall bedeutet es stillen Datenverlust.

 

[cuco]

Die Nutzung von Inkrementen führt aber eine zusätzliche Fehlerquelle ein. Wenn ich von meinen Arbeitsdaten ein Inkrement ziehe um es auf mein Off-Site-Backup zu übertragen, dann habe ich ein Backup, aber zwei potenziell fehlerbehaftete Kopiervorgänge (Arbeitsdaten -> Inkrement, Inkrement -> Backup). Ersetze ich das Inkrement hingegen durch ein zweites Vollbackup, welches ich jeweils gegen das erste Backup austausche, dann habe ich immer noch zwei Kopiervorgänge (Arbeitsdaten -> Backup1, Arbeitsdaten -> Backup2), aber auch zwei Backups.

Mein Inkrement kopiere ich aber niemals ins Backup (das Backup bleibt dabei unangetastet!), sondern lege es zusätzlich ab. Das Backup bleibt so wie es ist. Okay, ich kann natürlich die gleiche externe HDD auch für's Inkrement nutzen. Aber auch dann gilt: Wenn ich Checksummen nutze, dann merke ich, falls beim Kopiervorgang etwas kaputt geht, dann kann mir der zusätzliche Kopiervorgang egal sein.

Durch die Nutzung eines zweiten Vollbackups statt eines Inkrements kann ich also praktisch kostenlos (im Sinne des Aufwands) die Redundanz um N+1 erhöhen. Ich finde das ist ein echtes Schnäppchen.

Das ist aber alles andere als kostenlos. Ein Vollbackup dauert in der Regel deutlich länger und braucht deutlich mehr Platz als ein Inkrement. Deswegen macht man ja gerade inkrementelle Backups, das ist gängige Praxis.

Den Diff zwischen Arbeitsdaten und Backup kann ich aber einfach auf Plausibilität prüfen. Hänge ich ein Inkrement dazwischen, dann verdreifacht sich der Aufwand, denn ich muss nun 1. Arbeitsdaten gegen Inkrement, 2. Inkrement nach der Erstellung aus Arbeitsdaten gegen Inkrement vor der Übertragung auf's Backup und 3. Inkrement gegen Backup prüfen.

Nochmal: Man testet sein Backup in der Regel nie gegen die aktuellen Arbeitsdaten. Wenn überhaupt dann teste ich gegen den dafür erstellten unveränderlichen Snapshot, aber in der Regel erstelle ich beim Backup Checksummen (dafür sind sie da...) und dann prüfe ich später mein Backup nur noch gegen die Checksummen. Und dann habe ich keinen wirklichen Zusatzaufwand durch Inkremente.

Ja, aber das ist dann eben kein Backup der "echten" Arbeitsdaten sondern ein Backup vom Backup, mit allen im Quellbackup enthaltenen Fehlern.

Deshalb: Checksummen.

Das kann man machen und es gibt gute Gründe das zu tun, aber man sollte sich eben des Details bewusst sein, dass es eine Kopie einer Kopie ist. Das bedeutet im einfachsten Fall erhöhten Prüfaufwand (der sich aber gegenüber einem erneuten Backup aus Arbeitsdaten lohnen kann), im schlimmsten Fall bedeutet es stillen Datenverlust.

Deshalb: Checksummen.

 

[hikaru]

Mein Inkrement kopiere ich aber niemals ins Backup (das Backup bleibt dabei unangetastet!), sondern lege es zusätzlich ab.

Ich fürchte, wir reden aneinander vorbei, was die Begriffe "Inkrement" und "Vollbackup" angeht. Du meinst den kompletten Vorgang eines inkrementellen Backups, bei dem du das vollständige Backup mit den Arbeitsdaten vergleichst und die Differenz zusätzlich zum vollständigen Backup ablegst. Was das angeht, stimme ich dir zu. Dann kannst du direkt Vergleiche zwischen Arbeitsdaten und Backup anstellen, denn es gibt keine räumliche Trennung, die du überbrücken musst.
Ich meinte mit "Inkrement" bisher nur die Differenz zwischen zwei Datenständen, also das was du letztendlich auf einem eher kleinen Austauschdatenträger als Brücke von A nach B bewegst um ein Off-Site-Backup zu aktualisieren. Der Begriff "Inkrement" war hier vielleicht schlecht gewählt und "Vollbackup" war sicher eine unkluge Verkürzung für "vollständiges Backup" im Sinne einer kompletten Kopie aller Daten. Lies meine bisherigen Beiträge nochmal mit 's/Inkrement/Diff/g' und 's/Vollbackup/vollständiges Backup/g', dann dürfte klarer werden, was ich meine!

Nochmal: Man testet sein Backup in der Regel nie gegen die aktuellen Arbeitsdaten. Wenn überhaupt dann teste ich gegen den dafür erstellten unveränderlichen Snapshot, aber in der Regel erstelle ich beim Backup Checksummen (dafür sind sie da...) und dann prüfe ich später mein Backup nur noch gegen die Checksummen.

Ja, das mit den Snapshots ist klar. Aber wie überprüfst du, ob ein Diff, das du von A nach B transportierst um dein Off-Site-Backup zu aktualisieren, intakt ist? Klar, du kannst noch an der Quelle nach der Erstellung des Diffs dessen Checksumme ermitteln und die am Ziel gegenprüfen, bevor du das Diff auf dein Backup anwendest. Aber wie stellst du sicher, dass das Diff nicht schon während der Ermittelung der Checksumme an der Quelle defekt war oder dass während des Updates des Backups am Ziel etwas schief geht?
Natürlich kannst du hinterher überprüfen, ob die Checksummen von Quelle und Ziel übereinstimmen, aber wenn sie nicht stimmen, dann ist das Kind in den Brunnen gefallen und dein Backup kaputt. Auch ein von A nach B transportiertes vollständiges Backup (das durchaus inkrementell erstellt sein kann, aber eben alle Daten enthält und nicht nur das Diff) kann Schaden nehmen, aber wenn du ein zweites vollständiges Backup hast, dann ist wenigstens das noch intakt. Und wenn du die beiden vollständigen Backups jeweils im Wechsel physisch austauschst, dan brauchst du keine Diffs mehr hin- und hertransportieren, und sie fallen als mögliche Fehlerquelle weg.

 

[paluba]

Nochmal: Man testet sein Backup in der Regel nie gegen die aktuellen Arbeitsdaten. Wenn überhaupt dann teste ich gegen den dafür erstellten unveränderlichen Snapshot, aber in der Regel erstelle ich beim Backup Checksummen (dafür sind sie da...) und dann prüfe ich später mein Backup nur noch gegen die Checksummen. Und dann habe ich keinen wirklichen Zusatzaufwand durch Inkremente.

Mit welcher Software kann ich denn (unter Win) solche Checksummen relativ bequem erstellen und überprüfen?

 

[zwieblum]

Get-FileHash (Microsoft.PowerShell.Utility) - PowerShell

The Get-FileHash cmdlet computes the hash value for a file by using a specified hash algorithm. A hash value is a unique value that corresponds to the content of the file. Rather than identifying the contents of a file by its file name, extension, or other designation, a hash assigns a unique...

learn.microsoft.com

 

[cuco]

Ich fürchte, wir reden aneinander vorbei, was die Begriffe "Inkrement" und "Vollbackup" angeht. Du meinst den kompletten Vorgang eines inkrementellen Backups, bei dem du das vollständige Backup mit den Arbeitsdaten vergleichst und die Differenz zusätzlich zum vollständigen Backup ablegst. Was das angeht, stimme ich dir zu. Dann kannst du direkt Vergleiche zwischen Arbeitsdaten und Backup anstellen, denn es gibt keine räumliche Trennung, die du überbrücken musst.
Ich meinte mit "Inkrement" bisher nur die Differenz zwischen zwei Datenständen, also das was du letztendlich auf einem eher kleinen Austauschdatenträger als Brücke von A nach B bewegst um ein Off-Site-Backup zu aktualisieren. Der Begriff "Inkrement" war hier vielleicht schlecht gewählt und "Vollbackup" war sicher eine unkluge Verkürzung für "vollständiges Backup" im Sinne einer kompletten Kopie aller Daten. Lies meine bisherigen Beiträge nochmal mit 's/Inkrement/Diff/g' und 's/Vollbackup/vollständiges Backup/g', dann dürfte klarer werden, was ich meine!

So viel klarer wird es nicht. Ich würde sagen: Entweder machst du ein (erneutes) Vollbackup, das nimmst du mit und legst es irgendwo anders ab. Oder du machst (nachträglich) ein inkrementelles Backup und legst es zusätzlich zum Vollbackup ab.
Willst du ein Diff irgendwie zu transportieren und damit das Vollbackup zu verändern? Dann bitte nicht. Leg das Diff/Inkrement einfach zusätzlich ab.

Ja, das mit den Snapshots ist klar. Aber wie überprüfst du, ob ein Diff, das du von A nach B transportierst um dein Off-Site-Backup zu aktualisieren, intakt ist? Klar, du kannst noch an der Quelle nach der Erstellung des Diffs dessen Checksumme ermitteln und die am Ziel gegenprüfen, bevor du das Diff auf dein Backup anwendest.

Die Integrität eines Backups sollte immer gewahrt sein. Deshalb wendet man auch kein Diff auf einem Backup an. Man legt es zusätzlich ab.

Aber wie stellst du sicher, dass das Diff nicht schon während der Ermittelung der Checksumme an der Quelle defekt war

Klag kann ein Diff/Inkrement (und genau so auch ein Vollbackup!) schon bei der Erstellung kaputt gehen. Dann bringt mir die Checksumme vom Diff/Vollbackup nichts. In der Regel bietet die verwendete Backup-Software dafür aber nochmal Möglichkeiten an. Zum Beispiel indem sie den Snapshot der Daten vorhält und das Backup/Diff nochmal gegenprüft (in der Regel in dem Metadaten und/oder Checksummen verglichen werden, ggf. aber auch vollständiger Abgleich). Wenn das passt, sind auch eventuelle Checksummen der Einzeldateien/-blöcke im Backup sowie die Checksumme des gesamten Backupcontainers gültig.

oder dass während des Updates des Backups am Ziel etwas schief geht?

Nein, s.o., Backups werden nicht nachträglich verändert! Entweder überschrieben und somit durch ein neues Backup ersetzt oder ein Inkrement zusätzlich abgelegt.

Natürlich kannst du hinterher überprüfen, ob die Checksummen von Quelle und Ziel übereinstimmen, aber wenn sie nicht stimmen, dann ist das Kind in den Brunnen gefallen und dein Backup kaputt.

Dann erstelle ich es halt nochmal. Wie willst du es sonst machen? Falls das auch wieder fehlschlägt, habe ich ein ganz anderes Problem, zum Beispiel einen Hardwareschaden. Dann muss ich halt im Notfall das zweite noch vorhandene Backup bemühen. Deswegen macht man ja zwei Backups/Kopien der Originaldaten. Damit selbst im Falle eines kaputten Backups der Verlust der Originaldaten kein Problem ist, dann ist immer noch die dritte Kopie (Backup Nr. 2) da.

Auch ein von A nach B transportiertes vollständiges Backup (das durchaus inkrementell erstellt sein kann, aber eben alle Daten enthält und nicht nur das Diff) kann Schaden nehmen, aber wenn du ein zweites vollständiges Backup hast, dann ist wenigstens das noch intakt. Und wenn du die beiden vollständigen Backups jeweils im Wechsel physisch austauschst, dan brauchst du keine Diffs mehr hin- und hertransportieren, und sie fallen als mögliche Fehlerquelle weg.

Richtig, es sei denn ich will inkrementelle Backups machen, damit ich nicht so riesige Datenmengen transportieren muss.

Mit welcher Software kann ich denn (unter Win) solche Checksummen relativ bequem erstellen und überprüfen?

Such dir was aus. In der Regel übernimmt deine Backup-Software das schon für dich oder bietet es optional an. Ansonsten:

Microsoft File Checksum Integrity Verifier - Prüfsummen berechnen

Sonstiges Download: Mit dem File Checksum Integrity Verifier (FCIV) 2.5 von Microsoft lassen sich Prüfsummen von Dateien berechnen, um diese auf etwaige ...

winfuture.de

Checksum Calculator

WinMD5Checksum

WinMD5Checksum erstellt, berechnet und vergleicht MD5- und SHA256-Hashes.

www.heise.de

Hash Tool

Mit dem Hash Tool lassen sich unter Windows Hashwerte von Dateien berechnen.

www.heise.de

oder der verlinkte Power-Shell-Befehl oder oder oder
Auch WinRAR kann dir Checksummen für alle Einzeldateien im Archiv sowie für das gesamte Archiv erstellen (auf Wunsch auch plus Wiederherstellungsdaten, so dass Beschädigungen nicht nur erkannt, sondern auch behoben werden können). Andere Archivformate/-programme sollten das genau so können (7zip z.B.).

 

[zwieblum]

... aber immer dran denken: Indentische Prüfsummen heiß nicht identische Files - nur hohe Wahrscheinlichkeit, dass die Files identisch sind. Und wenn du nicht die Hashes in einem File ablegst und dann die Hashes der "neuen" Files gegen diese gespeicherten Hashes prüfst kkannst du genau so gut einen1:1 Vergleich der Files machen.

 

[cuco]

... aber immer dran denken: Indentische Prüfsummen heiß nicht identische Files - nur hohe Wahrscheinlichkeit, dass die Files identisch sind.

Hash-Kollisionen, vor allem zufällige, sind aber extremst selten - je nach Hash-Algorithmus. Klar, bei Algorithmen wie Fletcher ist die Wahrscheinlichkeit deutlich höher, aber die Wahrscheinlichkeit, dass man dadurch eine zufällig veränderte Datei nicht erkennt, dürfte auch trotzdem fast infinitesimal klein sein. Mit MD5 wird's noch unwahrscheinlicher, bei SHA256/SHA512 brauchen wir uns darüber wohl nicht mehr zu unterhalten.

Und wenn du nicht die Hashes in einem File ablegst und dann die Hashes der "neuen" Files gegen diese gespeicherten Hashes prüfst kkannst du genau so gut einen1:1 Vergleich der Files machen.

Nur wenn Backup und Quelldateien beide am gleichen Ort zur gleichen Zeit vorliegen. Mit einem Off-site-Backup ist der Check deutlich leichter, wenn man gegen Hashes prüft. Auch im Desaster-Fall kann man so das Backup bei der Wiederherstellung nochmal checken und so sicherstellen, dass die Daten wiederhergestellt werden, die man ins Backup geschrieben hat. Und falls man dabei feststellt, dass das Backup einen Fehler hat, kann man immer noch z.B. auf das zweite Backup zurückgreifen und die betroffene Datei (oder alles) aus diesem wiederherstellen.

 

[hikaru]

Nein, s.o., Backups werden nicht nachträglich verändert! Entweder überschrieben und somit durch ein neues Backup ersetzt oder ein Inkrement zusätzlich abgelegt.

Das ist nicht in jedem Fall praktikabel. Ich habe ca. 5TB zu sichernder Daten. Die im Falle eines Verlustes der Arbeitsdaten wiederherstellen zu können ist wichtig, daher das Backup. Die Historie ist aber eher wenig interessant. Hätte ich die mitgesichert, dann wäre mein Backup über 1PB groß.

 

[zwieblum]

Mit MD5 wird's noch unwahrscheinlicher, bei SHA256/SHA512 brauchen wir uns darüber wohl nicht mehr zu unterhalten.

Womit sich dann natürlich gleich die Frage stellt, warum Kompressionsprogramme so schreklich ineffizient sind, wenn es genügt, den Hashwert zu speichern und bei einem externen Provider aka google einfach nach dem dazu passenden Datenblock zu suchen ... IMO gibt es dazu auch eine Applikation bei besagter Firma.

 

[cuco]

Das ist nicht in jedem Fall praktikabel. Ich habe ca. 5TB zu sichernder Daten. Die im Falle eines Verlustes der Arbeitsdaten wiederherstellen zu können ist wichtig, daher das Backup. Die Historie ist aber eher wenig interessant. Hätte ich die mitgesichert, dann wäre mein Backup über 1PB groß.

Natürlich ist das praktikabel. Niemand hat gesagt, dass du unbegrenzt lange alle Versionen aufbewahren musst. Was du an Historie benötigst und wie lange deine Backups zurückreichen müssen, kannst nur du entscheiden. 5TB an zu sichernden Daten ist jetzt ja noch nicht gigantisch viel. Wie kommst du außerdem auf 1PB? Das wäre 200x 5TB, entspricht also 200 Vollbackups oder der Aufbewahrung von 2000 zusätzlichen Inkrementen, sofern sich bei jedem Inkrement 500GB (10%) der Daten verändert haben. Beides ergibt irgendwie keinen Sinn.
Ich würde sagen, du hast grundsätzlich die Möglichkeit, mit oder ohne Inkrementen zu arbeiten.
- Ohne inkrementelle Backups: Du machst zwei Vollbackups, davon legst du eines extern ab. Zur Aktualisierung erstellst du lokale Backup neu und bringst es nach extern. Dort nimmst du die dortigen Medien mit zurück zu dir und aktualisierst ggf. auch dieses Backup, in dem du es durch ein neues Vollbackup ersetzt. Kein Backup wird verändert, es wird nur durch vollständige neue Backups ersetzt.
- Mit inkrementellen Backups: Du machst zwei Vollbackups, davon legst du eines extern ab. Zur Aktualisierung sicherst du beim ersten Mal die Veränderungen seit dem Vollbackup, ebenfalls zweimal. Diese Änderungen legst du zusätzlich zum Vollbackup einmal lokal und einmal extern ab. Ab dem zweiten inkrementellen Backup kannst du dich entscheiden: Entweder sicherst du nur Veränderungen seit dem letzten Inkrement. Vorteil: Geringe Größe. Nachteil: Du hast nachher zig inkrementelle Backups, die du alle nach und nach einspielen musst. Auf jeden Fall legst du auch dieses Inkrement zusätzlich zum Vollbackup und zusätzlich zum letzten Inkrement bzw. den letzten Inkrementen lokal und extern ab. Alternative ist, dass du auch bei den nächsten inkrementellen Backups immer die Änderungen seit der letzten Vollsicherung (und nicht seit dem letzten Inkrement) sicherst. Nachteil: Das inkrementelle Backup wird jedes Mal größer. Vorteil: Man hat im Schadensfall nur genau ein Vollbackup plus genau ein Inkrement zurückzusichern - und nicht dutzende. Außerdem kannst du, wenn du dieses Inkrement zusätzlich zum Vollbackup lokal und extern ablegst, das jeweils vorhergehende Inkrement entsorgen. Damit wird der nötige Platz für das Inkrement im Vergleich zu laufenden Inkrementen deutlich geringer sein. In beiden Fällen veränderst du dein Vollbackup bei der Erstellung des Inkrements aber auf keinen Fall. Erst wenn deine Inkremente zu viele werden oder dein Inkrement zu groß wird, kannst du darüber nachdenken, mal das Vollbackup zu ersetzen wie bei der Methode ohne inkrementelle Backups. Also neues Vollbackup erstellen, nach extern bringen, dort das alte Vollbackup und alle Inkremente mitnehmen und lokal durch auch ein neues Vollbackup ersetzen.

Womit sich dann natürlich gleich die Frage stellt, warum Kompressionsprogramme so schreklich ineffizient sind, wenn es genügt, den Hashwert zu speichern und bei einem externen Provider aka google einfach nach dem dazu passenden Datenblock zu suchen ... IMO gibt es dazu auch eine Applikation bei besagter Firma.

Das hat mehrere Gründe.
Erstens: Wenn du Daten komprimierst, willst du wohl kaum davon abhängig sein, dass dieser Datenblock irgendwo bei Google gefunden werden kann, sondern du willst den echten Datenblock bei dir abspeichern.
Zweitens: Hash-Kollisionen sind zwar möglich, aber extrem selten. Und Hash-Funktionen sind Funktionen, die nur in eine Richtung vollständig berechenbar sind. Soll heißen: Ich kann zwar aus einem Datenblock oder einer Datei einen eindeutigen Hashwert berechnen (der sich normalerweise auch schon bei einer Veränderungen von nur einem Bit in dem Datenblock sehr deutlich verändert). Ich kann aber aus einem Hashwert nicht einfach auf den Datenblock zurückschließen.
Drittens: Die Berechnungen dafür (also den Datenblock anhand des Hashwerts aus einer Tabelle suchen) sind auch nicht ohne. In btrfs und ZFS kann man so z.B. Daten auf seinem Datenträger deduplizieren und Speicherplatz sparen, weil doppelte Daten nicht mehr doppelt vorgehalten werden. Braucht aber so viel RAM und Rechenleistung, dass das ganze so lahm wird, dass in den meisten Fällen von dieser Funktion abgeraten wird.
Aber: DropBox macht dies. Das ermöglicht auch Attacken: https://a3nm.net/blog/deduplication_attacks.html