Verwendet ihr für eure Backuplösungen Parchive?



  • volkard schrieb:

    Die Zuverlässigkeit von USB-Sticks. Disketten und CDs hatten immer mal Probleme, USB-Sticks niemals.

    Hm, also bei einem Flashspeicher können theoretisch betrachtet IMO auch Bits kippen. Immerhin ist das AFAIK nur ne elektrische Ladung, und die kann über die Zeit verloren gehen.
    Und hier würde ich davon ausgehen, dass der Ladungsverlust für jedes einzelne Bit zu unterschiedlichen Zeiten stattfinden kann, es also auch nicht so ist, dass der Flashspeicher alles auf einmal verliert.

    Das richtige Backup schrieb:

    Als ich sowas noch nutze, da war es die Fehlerkorrektur, die bei rar dabei ist.

    Hast du alle deine Dateien auf deinem Backupmedium in RAR Dateien verpackt?

    Nicht mehr. Heute machts eher robocopy unkomprimiert auf Sticks und Platten. Officedateien lassen sich ja nicht mehr packen, die P*rn*sammlung auch nicht, das Bißchen Quellcode ist irrelevant.

    Deswegen wäre meiner Meinung nach ein Errorcode sinnvoll, der auf unkomprimierte Daten wirkt.
    Das Problem kann ja schließlich auch heute noch bei Festplatten auftreten und genau solche Medien nutze ich aufgrund der Datenmengen heutzutage, wenn ich ein Backup erstelle.

    Bei Videos wird's natürlich recht egal sein, wenn da ein Bit kippt, dann geht das eh unter. Prinzipiell dürfte das für alle verlustbehaftete Formate gelten.
    Das der Quellcode nicht die Welt ist, da stimme ich dir zu.

    OpenOffice Dateien werden sowieso in ZIP Dateien gepackt, die kommen schon mit einer Fehlerkorrektur, da sehe ich das Problem nicht.

    Aber es gibt ja noch die Patches für Software und die findet man auch nicht alle mehr im Internet.
    Gerade für diese dürfte das besonders interessant sein.

    Keine AHnung. Für den gpg-Schlüssel und ie Bitcoin-Schlüssel kann man ja mehrere Sticks beschreiben und einen bei der Oma hinterlegen.

    Den GPG Schlüssel würde ich als ASCII Zeichen auf Papier ausdrucken.
    GPG bietet dafür sogar explizit Möglichkeiten an.

    GPG Archive sind für gekippte Bits sehr anfällig.
    Bei Truecrypt Archiven weiß ich es nicht.



  • Nicht mehr. Heute machts eher robocopy unkomprimiert auf Sticks und Platten. Officedateien lassen sich ja nicht mehr packen, die P*rn*sammlung auch nicht, das Bißchen Quellcode ist irrelevant.

    Naja so irrelevant finde ich das nicht. Je nach Daten komme ich da auf durchschnittliche Kompressionraten von 10%-20%, das sind dann etliche Gigabyte Speicher die du sparst.

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Wie jede andere Datei auch. Ich verwende ja eh ne billige selbstgestrickte Backuplösung, alles zusammenfassen und in Archive stecken. Integritätscheck mach ich da keinen, aber eventuell bieten meine zip/7z Archive da was, da kenn ich micht nicht soo gut aus. Und falls irgendwo ein Fehler drin ist, sind Teile der Daten halt futsch, halte ich aber für sehr unwahrscheinlich.



  • volkard schrieb:

    Die Zuverlässigkeit von USB-Sticks. Disketten und CDs hatten immer mal Probleme, USB-Sticks niemals.

    Ich habe schon diverse kaputte USB-Sticks erlebt (zum Glück mit einer Ausnahme nicht bei meinen Eigenen).



  • Für "wirklich wichtige" Sachen (paar Rechnungen, Steuererklärungen und so Scheiss) hab ich momentan ein ReFS mit "integrity streams" auf nem gespiegelten Storage Space.
    Quasi ZFS für Arme.

    Bin aber am Überlegen auf nen Drobo umzusteigen (der Server wird schön langsam alt).



  • DarkShadow44 schrieb:

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Wie jede andere Datei auch. Ich verwende ja eh ne billige selbstgestrickte Backuplösung, alles zusammenfassen und in Archive stecken. Integritätscheck mach ich da keinen, aber eventuell bieten meine zip/7z Archive da was, da kenn ich micht nicht soo gut aus. Und falls irgendwo ein Fehler drin ist, sind Teile der Daten halt futsch, halte ich aber für sehr unwahrscheinlich.

    7z verfügt über keinerlei Recovery Record Möglichkeit, d.h. wenn da nur ein einziges Bit kippt, dann weißt du zwar, dass das Archive kaputt ist, denn über einen Integritätscheck verfügt es noch, aber du kommst auch nicht mehr an deine Dateien heran.
    Denn wenn da nur ein Bit kaputt ist, dann ist das ganze Archiv kaputt und nicht nur Teile davon.
    ZIP ist da ein ganz klein wenig robuster, da es immerhin mit einem einfachen gekippten Bit noch klar kommt und die Dateien einzeln entpackt werden können.
    Aber für eine echte Fehlerkorrektur brauchst du ein Format mit Recovery Record Funktikon, das bietet momentan von den gängigen Formaten nur RAR oder du nimmst eine externe Lösung wie par2.
    http://en.wikipedia.org/wiki/Comparison_of_archive_formats#Comparison

    PS:
    Das mit dem gekippten Bit kann man ganz einfach mit einem Hexeditor testen.
    Datei packen, gepackte Datei in einem Hexeditor öffnen, einen Hexwert nehmen und den so ändern, dass in Binärdarstellung nur ein Bit verändert werden würde.
    Das wäre der einfachste Fall.


  • Mod

    hustbaer schrieb:

    Für "wirklich wichtige" Sachen (paar Rechnungen, Steuererklärungen und so Scheiss) hab ich momentan ein ReFS mit "integrity streams" auf nem gespiegelten Storage Space.
    Quasi ZFS für Arme.

    Bin aber am Überlegen auf nen Drobo umzusteigen (der Server wird schön langsam alt).

    Warum nicht in die Cloud? TrueCrypt FS einfach reinlegen und los? Auch sicher vor Brand, Katastrophen und Diebstahl.

    MfG SideWinder



  • @SideWinder
    Ich hab' mich mit dem Thema noch nicht so befasst. Wie tut man da? Also dass ich nen TrueCrypt Container machen kann, und den dann auf mein XYZ-Cloud-Drive legen, ist mir klar. Ist aber super unpraktisch.
    Also wie tut man da wenn man praktisch möchte? 🙂



  • Offsite-Backups mache ich seit einigen Jahren auf Tarsnap. Bin sehr zufrieden damit.



  • Das richtige Backup schrieb:

    Oder verwendet ihr überhaupt irgendeine Lösung mit Errorcorrection?

    Ich habe zwei RAID 5 in meinem Storage-Server. 4x500GB mit 7 Jahre alten Platten, die aber bisher keinen Ausfall hatten und 4x2000GB, etwa 4 Jahre alt, bei der mal eine HDD nach ein paar Badblocks ausgetauscht wurde. Beide RAIDs sind eigentlich vom Alter der Platten her schon zu alt, aber zum einen liegen wichtige Daten teilweise redundant auf beiden RAIDs, also kein Verlust, wenn ein RAID komplett ausfallen sollte und zum anderen ist das 6TB RAID einfach noch nicht voll.

    Mein Webserver läuft auf einem RAID 1 mit 2x160GB. Auch davon musste bereits eine Platte gewechselt werden.

    Ich plane derzeit mein Subversion-Repository, was auf dem 4x2TB RAID liegt, per Hook automatisiert auf den Webserver zu sichern. So ein RAID nutzt ja auch nix, wenn die Wohnung abfackelt und der USB-Stick, den ich immer mit mir rumschleppe, wird einfach nicht regelmäßig genug aktualisiert.

    Schlussfolgerung: USB Stick als Notfall-Backup ungeeignet.
    Die RAIDs haben sich in jedem Fall schon bezahlt gemacht.

    Par-Archive sind zum Beispiel nützlich, wenn man Daten teilt. z.B. 15MB auf vier Server zu je 5MB. Wenn jemand 5MB Daten findet, kann er nichts damit anfangen, da unvollständig.
    Egal welcher Server verschwindet, die Daten sind vollständig erhalten.

    Je nach Bedarf können par-Archive durchaus Teil einer gelungenen Backup-Strategie sein.

    Das richtige Backup schrieb:

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Gar nicht. Bevor man das Backup ausliest, installiert man sich lieber eine aktuelle Version.

    Ich archiviere nur Daten.



  • Xin schrieb:

    Das richtige Backup schrieb:

    Oder verwendet ihr überhaupt irgendeine Lösung mit Errorcorrection?

    Ich habe zwei RAID 5 in meinem Storage-Server. 4x500GB mit 7 Jahre alten Platten, die aber bisher keinen Ausfall hatten und 4x2000GB, etwa 4 Jahre alt, bei der mal eine HDD nach ein paar Badblocks ausgetauscht wurde. Beide RAIDs sind eigentlich vom Alter der Platten her schon zu alt, aber zum einen liegen wichtige Daten teilweise redundant auf beiden RAIDs, also kein Verlust, wenn ein RAID komplett ausfallen sollte und zum anderen ist das 6TB RAID einfach noch nicht voll.

    Soweit ich weiss können die meisten RAID Systeme keine "bit rot" Fehler erkennen/korrigieren, wenn die Fehler von den HDDs nicht erkannt werden.
    D.h. wenn alle HDDs melden "da haste die Daten, alles OK", dann geht das RAID System davon aus dass wirklich alles OK ist, und verwendet die einfach.
    Dummerweise soll das auch durchaus vorkommen - d.h. man kann sich nicht 100% auf die ECC Mechanismen in der HDD verlassen. Nichtmal darauf dass Fehler zuverlässig erkannt werden.

    Daher gibt es ja auch Technologien wie ZFS, ReFS, Beyond RAID etc.



  • hustbaer schrieb:

    Soweit ich weiss können die meisten RAID Systeme keine "bit rot" Fehler erkennen/korrigieren, wenn die Fehler von den HDDs nicht erkannt werden.
    D.h. wenn alle HDDs melden "da haste die Daten, alles OK", dann geht das RAID System davon aus dass wirklich alles OK ist, und verwendet die einfach.

    Naja, wenn eine HDD falsch liegt, kann man erkennen, dass hier was schief geht, weil das RAID ja erkennen kann, dass die Prüfsumme im RAID nicht stimmt.
    Ob nun die Prüfsumme falsch ist oder die Daten der Platte, lässt sich hoffentlich daran erkennen, dass eine Platte einen Schaden meldet - sonst muss man tatsächlich raten.

    hustbaer schrieb:

    Daher gibt es ja auch Technologien wie ZFS, ReFS, Beyond RAID etc.

    Da habe ich noch nicht eingelesen. Die nächste Aufrüstung dauert noch ein wenig, deswegen verfolge ich sowas nur am Rand.

    Aktuelles Problem ist, dass der Tausch der 2GB Platte mehrere Stunden für das Resync in Anspruch nimmt. Geht in der Zeit eine 2. Platte hops, sind alle Daten weg. Hier möchte ich also auch mehr Redundanz schaffen.



  • Xin schrieb:

    hustbaer schrieb:

    Soweit ich weiss können die meisten RAID Systeme keine "bit rot" Fehler erkennen/korrigieren, wenn die Fehler von den HDDs nicht erkannt werden.
    D.h. wenn alle HDDs melden "da haste die Daten, alles OK", dann geht das RAID System davon aus dass wirklich alles OK ist, und verwendet die einfach.

    Naja, wenn eine HDD falsch liegt, kann man erkennen, dass hier was schief geht, weil das RAID ja erkennen kann, dass die Prüfsumme im RAID nicht stimmt.
    Ob nun die Prüfsumme falsch ist oder die Daten der Platte, lässt sich hoffentlich daran erkennen, dass eine Platte einen Schaden meldet - sonst muss man tatsächlich raten.

    Die meisten RAID Controller verlassen sich auf die ECC Daten der Platte, und haben selbst keine Prüfsummen.
    Und anscheinend sind die Platten was Fehlererkennung angeht lange nicht so gut wie sie es sein sollten.
    http://storagemojo.com/2007/09/19/cerns-data-corruption-research/

    Ich hatte nochmal nen Artikel von den ZFS Entwicklern gelesen, den find' ich auf die Schnelle aber nicht.

    hustbaer schrieb:

    Daher gibt es ja auch Technologien wie ZFS, ReFS, Beyond RAID etc.

    Da habe ich noch nicht eingelesen. Die nächste Aufrüstung dauert noch ein wenig, deswegen verfolge ich sowas nur am Rand.

    Aktuelles Problem ist, dass der Tausch der 2GB Platte mehrere Stunden für das Resync in Anspruch nimmt. Geht in der Zeit eine 2. Platte hops, sind alle Daten weg. Hier möchte ich also auch mehr Redundanz schaffen.

    Was für ne RAID Lösung verwendest du denn? Hardware? Bzw. kann der RAID 6? Das wäre wohl die einfachste Lösung mal schnell für mehr Redundanz zu sorgen.



  • hustbaer schrieb:

    Die meisten RAID Controller verlassen sich auf die ECC Daten der Platte, und haben selbst keine Prüfsummen.

    Sagen wir mal so... ich hoffe, dass ein RAID 5 alle Platten ausliest und auf Plausibilität prüft... andererseits bedeutet das noch höhere Prozessorlast und Festplatten laufen normalerweise auch zuverlässig, ohne dass ein RAID existiert. Im Normalfall sollte man sich die Frage also sparen können.

    hustbaer schrieb:

    Und anscheinend sind die Platten was Fehlererkennung angeht lange nicht so gut wie sie es sein sollten.

    Aber dann müsste doch im Prinzip laufend Windows abstürzen, weil irgendwo ein Bit umgekippt ist... moment... 😉

    hustbaer schrieb:

    Was für ne RAID Lösung verwendest du denn? Hardware? Bzw. kann der RAID 6? Das wäre wohl die einfachste Lösung mal schnell für mehr Redundanz zu sorgen.

    Software-RAID. Hardware-Controller haben den Nachteil, dass sie sehr teuer sind und bei Ausfall keiner einem garantieren kann, dass man das RAID nochmal ausgelesen bekommt. Beim Software-RAID Stöpsel ich die Platten in einen anderen PC und läuft.

    RAID 6 habe ich für das nächste RAID angedacht. Aber in dem Bereich tut sich wohl so einiges, so dass meine RAID 5+ext3-Lösung heute eigentlich eher eine Anfängerlösung darstellt. Ich habe auch schon überlegt, ob man einfach eine 5. Platte dazuhängen kann, die dann auf RAID6 gesynct wird, ohne dass man das RAID5 kopieren muss... 6 TB bekomme ich nicht mal eben auf eine externe Platten ausgelagert. 😉
    Das müsste ich erstmal anderswo ausprobieren und mich einlesen, bevor ich solche Aktionen angehe...

    Da die Kiste aber sowieso mein Privatvergnügen ist und noch läuft, Smart noch ruhig ist und ich zuletzt auch keine Baublocks fand, plane ich als nächste Backuplösung erstmal statt einer Datenstrom eine Luftstromlösung, damit ich wenn man mal wieder ins kalte Wasser geworfen wird
    mein Überleben sicherstellen kann. Ein RAID1 zum Tauchen: einen vereisungssicheren redundanten Atemregler.
    Das wird finanziell auch etwa auf's Gleiche rauskommen, wie ein neues RAID6 und deswegen muss das RAID6 noch was warten. 😕



  • Xin schrieb:

    Das richtige Backup schrieb:

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Gar nicht. Bevor man das Backup ausliest, installiert man sich lieber eine aktuelle Version.

    Wo nimmst du die her, wenn nicht aus deinem eigenen Backup?



  • Das richtige Backup schrieb:

    Xin schrieb:

    Das richtige Backup schrieb:

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Gar nicht. Bevor man das Backup ausliest, installiert man sich lieber eine aktuelle Version.

    Wo nimmst du die her, wenn nicht aus deinem eigenen Backup?

    Ein Softwarehersteller sollte Quellen haben. Wenn Du die Software nicht selbst herstellst, würde ich die Software dort wieder herholen, wo ich die erste Version herbekommen habe.

    Executables sind in der Regel leicht wieder zu bekommen. Die Daten, die damit erstellt werden, sind in der Regel schwerer zu bekommen. Ich mache Backups von Quelltexten, nicht von Compilern.



  • Xin schrieb:

    hustbaer schrieb:

    Die meisten RAID Controller verlassen sich auf die ECC Daten der Platte, und haben selbst keine Prüfsummen.

    Sagen wir mal so... ich hoffe, dass ein RAID 5 alle Platten ausliest und auf Plausibilität prüft... andererseits bedeutet das noch höhere Prozessorlast und Festplatten laufen normalerweise auch zuverlässig, ohne dass ein RAID existiert. Im Normalfall sollte man sich die Frage also sparen können.

    Der mdraid-Maintainer hat mal beschrieben, warum er das nicht implementiert: http://neil.brown.name/blog/20100211050355

    Da geht es mehr um Recovery nach einem Absturz und weniger um error checking im Betrieb. Auf der mdraid-Mailingliste ist die vorherrschende Meinung aber (scheint mir), dass die Chance, einen Bitfehler im Arbeitsspeicher zu haben viel höher ist, als einen unerkannten Bitfehler auf einer Festplatte zu haben. Solange man also nicht ECC-RAM einsetzt, ist es völlig überflüssig, die Fehlerkorrektur der Festplatten anzuzweifeln, denn man hat dann eine viel größere Fehlerquelle.

    Xin schrieb:

    Ich habe auch schon überlegt, ob man einfach eine 5. Platte dazuhängen kann, die dann auf RAID6 gesynct wird, ohne dass man das RAID5 kopieren muss...

    An VMs mal ausprobieren kann nicht schaden, aber mit mdraid unter Linux macht es viel Spaß, sowas zu machen, weil sehr einfach geht. Du musst tatsächlich nur die Platte dazuhängen, zum RAID als spare hinzufügen und dann reshape machen auf RAID6 mit einer Platte mehr. Das RAID kann während der ganzen Aktion online bleiben, und am Ende hast du ein normales RAID6.



  • Christoph schrieb:

    Solange man also nicht ECC-RAM einsetzt, ist es völlig überflüssig, die Fehlerkorrektur der Festplatten anzuzweifeln, denn man hat dann eine viel größere Fehlerquelle.

    Naja... ein false Positive hat aber etwas sympathisches, wenn die Alternative ein unentdeckter Fehler ist.

    Christoph schrieb:

    Xin schrieb:

    Ich habe auch schon überlegt, ob man einfach eine 5. Platte dazuhängen kann, die dann auf RAID6 gesynct wird, ohne dass man das RAID5 kopieren muss...

    An VMs mal ausprobieren kann nicht schaden, aber mit mdraid unter Linux macht es viel Spaß, sowas zu machen, weil sehr einfach geht. Du musst tatsächlich nur die Platte dazuhängen, zum RAID als spare hinzufügen und dann reshape machen auf RAID6 mit einer Platte mehr. Das RAID kann während der ganzen Aktion online bleiben, und am Ende hast du ein normales RAID6.

    Vielleicht probiere ich das mal in den nächsten Monaten. Ich wollte sowieso einen neue Reserve-Platte besorgen, weil eben diese erstmal übergangsweise für anderes genutzt wurde.

    Erstmal ein Test-RAID über Dateien erweitern, wenn das vertrauenserweckend wirkt, kann man über die Erweiterung des RAIDs nachdenken. ^^



  • Xin schrieb:

    Das richtige Backup schrieb:

    Xin schrieb:

    Das richtige Backup schrieb:

    Wie würdet ihr z.B. eine Windows Executable archivieren?

    Gar nicht. Bevor man das Backup ausliest, installiert man sich lieber eine aktuelle Version.

    Wo nimmst du die her, wenn nicht aus deinem eigenen Backup?

    Ein Softwarehersteller sollte Quellen haben. Wenn Du die Software nicht selbst herstellst, würde ich die Software dort wieder herholen, wo ich die erste Version herbekommen habe.

    Tja, leider ist der Hersteller vom Markt verschwunden, deswegen macht man ja selbst Backups.

    Executables sind in der Regel leicht wieder zu bekommen.

    Gib mal nen Link zu dem Patch für das Computerspiel M1 Tank Platoon 2 direkt vom Hersteller.
    Bei dem Alter des Spieles wirst du es schon schwer haben, den Patch wenigstens von einer anderen vertrauenswürdigen Quelle, wie z.B. einem Spielemagazin zu erhalten.

    Genau für solche Dinge macht man deswegen Backups von Executables und Binärdateien.

    Aber auch von deinen MS DOS 6.0 Disketten wirst du keine Exectuables vom Hersteller bekommen, und falls doch, dann nicht kostenlos.
    Deswegen hat man ne Sicherungskopie.



  • Xin schrieb:

    Christoph schrieb:

    Solange man also nicht ECC-RAM einsetzt, ist es völlig überflüssig, die Fehlerkorrektur der Festplatten anzuzweifeln, denn man hat dann eine viel größere Fehlerquelle.

    Naja... ein false Positive hat aber etwas sympathisches, wenn die Alternative ein unentdeckter Fehler ist.

    mdraid prüft bei RAID6 beim normalen Lesen die Parität nicht, sondern liest nur die Datenblöcke. Du kannst aber regelmäßige checks machen, was bei Ubuntu sogar per default eingerichtet ist. Dann prüft mdraid alle Paritätsblöcke auf Konsistenz, repariert aber nichts.

    Wenn das einen Fehler entdeckt, hast du immer noch die Möglichkeit, das Programm raid6_check aus dem mdraid-git-Repository zu kompilieren und damit die Info zu bekommen, welche Platte man ignorieren müsste, damit die Parität konsistent ist.


Anmelden zum Antworten