Backup Device regelmäßig auf Fehler prüfen
-
Wartet, ich beantrage gleich ne Umbenennung in
mnam.
Oderuewu.
-
Ich dachte zuerst, nman führt Selbstgespräche
Dabei ist der TE gar früher registriert worden als nman selbst!
-
Fun fact: Ich wollte mir ursprünglich den Namen "mman" registrieren, der allerdings schon belegt war, worauf ich ohne groß nachzudenken ("Den Account verwende ich bestimmt nicht lange.") einfach auf den nächsten Buchstaben im Alphabet und somit "nman" ausgewichen bin.
Und jetzt bitte zurück zum Thread-Thema, für weitere Namensanmerkungen könnt ihr gerne einen neuen Thread aufmachen.
-
mman schrieb:
Hallo zusammen,
ich habe zuhause einen Linux-Server den ich auch zur Datenablage nutze.
Von den wichtigen Daten mache ich regelmäßig ein Backup per rsync auf eine externen USB Platte.Jetzt würde ich ganz gerne die Backup Platte regelmäßig prüfen um feststellen zu können ob dort die Daten (genauer eigneltich die gesamte Platte) noch in Ordnung sind.
Puh, so ein Backup taugt sowieso nix, weil nur einstufig.
Birgt immer das Risiko, daß Du Dein letztes, möglicherweise noch gutes Backup mit maroden Daten überspielst. Oder, wenn das Medium nen Schuß hat, totalen Mist baut.
SMART hilft Dir dabei gar nix.Kennst Du den Witz mit dem Backupprogramm für 5 € und dem dazugehörigen Restoreprogramm für 500 €?
Mindestens zweistufig, besser dreistufig. Und um einen kompletten Mediencheck zu bekommen, mach' das mit DD oder sowas.
Angenommen, Du hast einen BOD (Bunch of Disks): Kopiere Disk 2 auf Disk 3, danach Disk 1 auf Disk 2, danach aktualisierst Du das Backup auf Disk 1.
Zum Schluß über alle einen fsck laufen lassen. Wenn Du ganz sicher gehen magst und lokale Katastrophen wie Brand, Diebstahl oder so ausschließen magst, schleust Du eine vierte Platte ein, die Du an einen anderen Ort transportierst. Aber bei jedem Kopiervorgang kriegst Du mit, ob es da Probleme gab.Statt DD kannst Du natürlich auch fileweise kopieren, das erhöht die Sicherheit, läßt aber die Kopierzeit in die Höhe schnellen.
Mit jeder Platte weniger erhöhst Du das Risiko, Daten zu verlieren, kommt halt drauf an, wieviel Dir die Risikominimierung wert ist.
Das Minimum sind eigentlich zwei Platten, auf denen Du wechselweise Deine Backups aktualisierst.
-
Vielen Dank für die Antwort nman (und sorry dass ich dir deinen bevorzugten Nutzernamen weggeschnappt habe
).Vorrangig möchte ich gerne frühzeitig erkennen ob die Platte selbst langsam das zeitliche segnet bzw. fehlerhaft wird.
Meine Frage zielte mehr darauf ab, dass ich nach meinem Verständnis, um aussagekräftige SMART Ergebnisse zu bekommen, auch regelmäßig auf die Daten zugreifen muss (also mindestens hin und wieder Daten lesen).
Wenn ich das machen muss bin ich aber auch schnell an dem Punkt, dass wenn ich die Daten ohnehin schon lesen, von diesen auch gleich Checksummen bilden kann.Um aussagekräftige SMART Werte zu bekommen wird es aber wahrscheinlich reichen einen kleinen Teil der Daten zu lesen (so zumindest mein Verständnis vom SMART Mechanismus, korrigiert mich wenn ich hier falsch liege).
Ich dachte jetzt an eine Art Lösung die, um die Last bzw die Dauer einer solchen Prüfung zu minimieren, z.B. einmal die Woche nur einen kleinen Teil der Daten liest und die Checksumme prüft. Eine Woche später wird der nächste kleine Teil der Daten per Checksumme geprüft usw. bis alle Daten durch sind, dann geht es wieder von vorne los.
Dadurch hätte ich aktuelle SMART Daten und über längere Zeit auch immer wieder Checksummen geprüfte Dateien um z.B. auch Bitrot zu detektieren.
Ich hoffe ich konnte einigermaßen verständlich machen worauf ich hinaus will
.
-
@pointercrash():
Ein guter Hinweis. Zur Zeit habe ich in der Tat nur eine Platte.
Aber grundsätzlich spricht bei meinem beschreibenen Konzept ja auch nichts gegen mehrere Platten.Jedesmal die gesamten Daten zu kopieren wollte ich eigentlich vermeiden, daher benutzte ich zur Zeit ja auch rsync.
Siehst du bei der Nutzung mit rsync ein Problem oder würde hier auch einfach ein mehrstufiges Backup ausreichen um mehr Sicherheit zu erreichen?
Edit:
Noch ein kleiner Hinweis zu meinem vorherigen Post:
Ein Backup per rsync mache ich relativ selten (genauer ist das eher Bedarfsabhängig), sonst würde vermutlich ja schon das ausführen von rsync ausreichen um die SMART Werte aktuell zu halten.
-
mman schrieb:
Vielen Dank für die Antwort nman (und sorry dass ich dir deinen bevorzugten Nutzernamen weggeschnappt habe
).Zu spät gekommen und vom Leben bestraft.
Vorrangig möchte ich gerne frühzeitig erkennen ob die Platte selbst langsam das zeitliche segnet bzw. fehlerhaft wird.
Ja, dann solltest du scrubbing verwenden.
Meine Frage zielte mehr darauf ab, dass ich nach meinem Verständnis, um aussagekräftige SMART Ergebnisse zu bekommen, auch regelmäßig auf die Daten zugreifen muss (also mindestens hin und wieder Daten lesen).
Ja, wobei du dann trotzdem keine Absicherung gegen Bitrot hast. Es könnten ja Bits flippen, ohne dass es Lesefehler gibt.
Um aussagekräftige SMART Werte zu bekommen wird es aber wahrscheinlich reichen einen kleinen Teil der Daten zu lesen (so zumindest mein Verständnis vom SMART Mechanismus, korrigiert mich wenn ich hier falsch liege).
Nein, häufig gehen nur bestimmte Bereiche der Disk ein.
Ich hoffe ich konnte einigermaßen verständlich machen worauf ich hinaus will
.Ja, sehr gut sogar. Aber ich würde sowas nicht selbst stricken, sondern lieber ZFS verwenden und von Zeit zu Zeit scrubben lassen. Und wie schon gesagt, wenn du das nicht möchtest, nimm obnam oä., das bringt auch fsck und verify mit, wobei letzteres besonders im Zusammenspiel mit Volume-Snapshots praktisch ist.
Ein Backup per rsync mache ich relativ selten (genauer ist das eher Bedarfsabhängig), sonst würde vermutlich ja schon das ausführen von rsync ausreichen um die SMART Werte aktuell zu halten.
Nein, das reicht nicht. Damit die SMART-Werte aussagekräftig sein können, müsstest du die gesamte Disk schreiben und wieder auslesen. Sonst könnte dir ein bestimmter Bereich deiner Disk kaputtgehen, ohne dass du es merkst. Im wesentlichen brauchst du das, was "badblocks -w" macht, was aber natürlich deine Daten überschreiben würde.
pointercrash: dd würde ich persönlich nicht für Backups verwenden. Damit sicherst du ja auch korrupte Dateisysteme ohne Nachfrage weg.
-
nman schrieb:
pointercrash: dd würde ich persönlich nicht für Backups verwenden. Damit sicherst du ja auch korrupte Dateisysteme ohne Nachfrage weg.
Im Prinzip hast Du eh' schon alles gesagt.
Ich hätte noch sagen sollen, daß man zuerst vom Original einen fsck durchlaufen lassen sollte und das weitere Tun reiflich überlegen, wenn der auch nur Flohhusten diagnostiziert hat, also scripte dann stoppen lassen.
Dann habe ich recht wenig Skrupel, das Zeug komplett blockweise ohne Ansehen des Dateisystems umschaufeln zu lassen.
Ehrlich, ich weiß nicht, ob mein Schema wirklich wasserdicht ist, weil ich so einen Supergau moch nie hatte, die meisten sind aus persönlicher Blödheit generiert. Das Ein- Platten- Backup hat mich aber schonmal Daten gekostet
-
pointercrash() schrieb:
Das Ein- Platten- Backup hat mich aber schonmal Daten gekostet
Nein, schon klar, das alleine würde ich auch nicht machen. Ich habe typischerweise auch versionierte Backups auf Fileserver mit RAID1 und Offsite-Backup.
-
Vielen Dank euch beiden für die ausführliche Hilfe.
Ich denke ich habe jetzt einen recht guten Überblick über die Möglichkeiten.
Werde mir mal die von nman vorgeschlagenen Programme anschauen.
