Schei* auf Digital. Macht euch Sicherheitskopien!

[Blur]

*: Bisher habe ich keinen Beleg dafür, an der korrekten Implementierung dieser Basisbackupfunktionalität durch Acronis zu zweifeln. Aber Belegen kann ich es auch nicht.

Ist doch alles nicht so falsch.

Auf den Daten die gelesen wurden, wird auch eine Checksumme berechnet und diese mit ins Backup geschrieben.
Damit sichert man alle Fehler ab, die nach dem Lesen auftreten. Defekte Backup-Medien und Schreibfehler.

Fehler die beim Lesen auftreten, können nicht erkannt werden von der lesenden Software.
Eine Möglichkeit hier Probleme zu finden, ist mehrfaches Lesen (wie zum Beispiel ein zweites Mal bei einem binären Vergleich).

Würde nun bei so einem Vergleich ein Fehler auftreten, den die Checksumme des Backup nicht zeigt, weiß man nur, dass zweimal etwas verschiedenes gelesen wurde. Aber immer noch nicht, was nun richtig ist. Es kann auch beides falsch sein.

Ein Backup der sich per Checksumme prüft, geht davon aus, dass Lesen vom Medium fehlerfrei funktioniert, was ja irgendwie eine Grundvoraussetzung ist, damit der ganze Rechner überhaupt ordentlich läuft.

Oder andersum gesagt;
"Oh, ich habe gerade ganz viele Lesefehler, ich muss jetzt schnell ein Backup machen." ... ist nicht die richtige Backupstrategie

 

[nehonimo]

Jetzt verwirrst Du mich etwas.

Ich?

Hatte in meinen Tests (ist aber schon lange her, daher bin ich mir nicht 100% sicher), ein FullBackup gemacht, dann an einer großen Datei eine kleinigkeit geändert und dann ein incrementelles Backup gemacht. Das inc. Backup war wesentlich kleiner als die geänderte Datei. Ob dafür wirklich die Datei "konsistent" zum Zeitpunkt t auch gesichert werden muss, weis ich nicht wirklich.
Ich weis aber, das bei bestimmten Datenbanken auch Dateien gesichert werden, die mit der Datei auf Platte zu keinem Zeitpunkt t übereinstimmen. Es gibt dann noch Zusatzdaten, mit dennen dann aber die "DB Dateien" konsistent wiederhergestellt werden können.
Das kann bei Betriebssystem Dateien vielleicht auch so sein. Wichtig ist ja nur, dass die Dateien aus einem Backup wieder konsistent hergestellt werden können.

Ich habe da noch keine schlechte Erfahrung gemacht, aber ich musste das auch noch nicht wirklich oft restoren.

Gruß Nehonimo.

 

[das_teufelchen]

Kann es sein das es irgendwas mit Lightroom zu tun hat?
Denn es sind ausschließlich Ordner betroffen die ich so ablege:
-Lightroom Katalog
-1200x800 Pixel komprimiert
-Unkomprimiert
(Alles in einem Ordner, 1. und 2. sind in einem Unterordner)

Das kann doch kein Zufall sein

 

[ewm]

...
Ich erwarte, dass die Backupanwendung gewährleistet, dass die Sicherung einer Datei zu einem Zeitpunkt t ("open file for read") eine binär-identische Wiederherstellung exakt dieses (inhaltlichen) Zustandes zu einem beliebigen späteren Zeitpunkt ermöglicht...

Das wird wohl bei True Image nicht so sein, aber vielleicht weiß es wirklich jemand genauer.

Selbst das Verify beim Kopieren selbst (früher gab es mal bei xcopy den Schalter /V) ist für mich äußerst fragwürdig.

Was wird denn bitweise verglichen?

Zwischen Kopie und Vergleich müssten sämtliche Caches zwischen Quell- und Zielplatte neu gefüllt werden. Werden zufällig gleiche Speicherbereiche für den Vergleich gefüllt, würde eine fehlerhafte RAM- Zelle nicht mal auffallen.

TrueImage arbeitet imho so schnell bei der Erstellung der Images, dass ich nicht an ein Verify gleich nach dem Kopieren bestimmter Sektoren oder Blöcke glaube.

Gerade bei Images ganzer Partitionen wird nicht dateiweise, sondern sektorweise oder mit den kleinsten adressierbaren Blöcken gearbeitet.

Die werden dann in großen "Happen" in den RAM eingelesen und wieder geschrieben.

Ein bitweises Vorgehen wäre der Performance- Overkill!


Man konnte das früher übrigens auf gut beobachten, wenn die alten bootfähigen Diskclone- oder Imageprogramme ohne Cache- Stategien eingesetzt wurden.


Meine Strategie ist daher:

- Betriebssystem- + Programm-Images per TrueImage. Wenn da was kippt, dann bleiben die Selbstheilungskräfte des Betriebssystems, verhunzte Initialisierungen oder notfalls en Neuaufsetzen des Systems


- eigene Daten, wie z.B. Fotos werden dateiweise gesichert. Derzeit benutze ich dazu den TotalCommander.

- die Sicherung erfolgt auf eine interne separate Platte und eine externe USB- Platte mit gleichem Inhalt. Verglichen wird im Anschluss stichprobenweise.

- bei PC- Wechsel oder auch bei Austausch der Sicherungsmedien erfolgt eine Kopie der Datenträger und eine bitweise Kontrolle.

- die Festplatten der alten Systeme sind in der Regel so alt und es kostet zudem sehr viel Zeit zum sicheren Löschen, dass ich sie ausbaue und mindestens 1 Jahr lagere

- danach werden sie mittlerweile nicht mehr sicher gelöscht, sondern unbrauchbar gemacht (ca. 10 Bohrungen durch den Deckel im Bereich der Scheiben und Zerbohren der Chips) und dann in den Elektronikschrott gegeben

- ein sicheres Löschen halte ich bei Platten > 320 GB für Zeitverschwendung. 6...12 Stunden Rechnerlaufzeit sind mir die paar Euro nicht wert, die so eine Platte noch als Gebrauchtware bringt.


Gruß
ewm

 

[ewm]

Kann es sein das es irgendwas mit Lightroom zu tun hat?
Denn es sind ausschließlich Ordner betroffen die ich so ablege:
-Lightroom Katalog
-1200x800 Pixel komprimiert
-Unkomprimiert
(Alles in einem Ordner, 1. und 2. sind in einem Unterordner)

Das kann doch kein Zufall sein

Das sind doch aber Daten, die Du auf dem alten System schon benutzt (=geschrieben + gelesen) hast und da keine Fehler bemerkt hast. Oder?


Gruß
ewm

 

[IcheBins]

Ist doch alles nicht so falsch.

Auf den Daten die gelesen wurden, wird auch eine Checksumme berechnet und diese mit ins Backup geschrieben.
Damit sichert man alle Fehler ab, die nach dem Lesen auftreten. Defekte Backup-Medien und Schreibfehler.

Uff - genau das meinte ich. Danke.

Fehler die beim Lesen auftreten, können nicht erkannt werden von der lesenden Software.
Eine Möglichkeit hier Probleme zu finden, ist mehrfaches Lesen (wie zum Beispiel ein zweites Mal bei einem binären Vergleich).

Würde nun bei so einem Vergleich ein Fehler auftreten, den die Checksumme des Backup nicht zeigt, weiß man nur, dass zweimal etwas verschiedenes gelesen wurde. Aber immer noch nicht, was nun richtig ist. Es kann auch beides falsch sein.

Ein Backup der sich per Checksumme prüft, geht davon aus, dass Lesen vom Medium fehlerfrei funktioniert, was ja irgendwie eine Grundvoraussetzung ist, damit der ganze Rechner überhaupt ordentlich läuft.

Auch das deckt sich mit meiner Sicht auf die Dinge.


Grüße,
IcheBins

 

[IcheBins]

Ich?

Nein, ich meinte evm. Sorry für die Verwirrung.

Hatte in meinen Tests (ist aber schon lange her, daher bin ich mir nicht 100% sicher), ein FullBackup gemacht, dann an einer großen Datei eine kleinigkeit geändert und dann ein incrementelles Backup gemacht. Das inc. Backup war wesentlich kleiner als die geänderte Datei.

Wie ich schon schrieb, dürften hierbei sinnvollerweise nur die Delta-Informationen der Veränderung gespeichert werden, alles andere würde mich überaschen.

Bei den DB kann ich dann nur noch spekulieren: Das, was Du beschrieben hast, erinnert mich an RAID5 und seine Parittsinformationen. Aber das ist dann wirklich OT.


Grüße,
IcheBins

 

[IcheBins]

Selbst das Verify beim Kopieren selbst (früher gab es mal bei xcopy den Schalter /V) ist für mich äußerst fragwürdig.
Was wird denn bitweise verglichen?

Meine Annahme ist/war, das die binäre Identität mit Hilfe von geeigneten Prüfsummenverfahren relativ zügig verifiziert werden kann. Besondere Situationen wie das von Dir angeführte Beispiel mit der defekten RAM-Zelle werden damit natürlich noch nicht berücksichtigt.

TrueImage arbeitet imho so schnell bei der Erstellung der Images, dass ich nicht an ein Verify gleich nach dem Kopieren bestimmter Sektoren oder Blöcke glaube.

Gerade bei Images ganzer Partitionen wird nicht dateiweise, sondern sektorweise oder mit den kleinsten adressierbaren Blöcken gearbeitet.

Die werden dann in großen "Happen" in den RAM eingelesen und wieder geschrieben.

Ein bitweises Vorgehen wäre der Performance- Overkill!

Ja, einen "echten" bitweisen Vergleich halte ich auch für ausgeschlossen. Da kommen natürlich intelligentere Verfahren zum Einsatz. Paritätsinformationen gibt es ja auch schon seit einiger Zeit. Und ein RAID5-Setup adressiert das Problem der konsistenten Informationsredundanz immerhin in mehr oder weniger Echtzeit.


Auf jeden Fall: Danke an alle für den interessanten und sachlichen Austausch.


Grüße,
IcheBins

 

[nehonimo]

Wie ich schon schrieb, dürften hierbei sinnvollerweise nur die Delta-Informationen der Veränderung gespeichert werden, alles andere würde mich überaschen.

Wollte darlegen, dass nicht die komplette geänderte Datei gesichert wird, also nichts überraschendes

 

[isibitz]

Fall 1: Habe vor ca. 2 Jahren meine Negative/DIAs zwecks Digitalisierung gesichtet. Erschreckend. Es waren doch einige dabei, die fast unbrauchbar waren. Als Ursache ergab sich fehlerhafte Entwicklung, falsche Lagerung und Schäden durch Ausdünstung von Stoffen in den Möbeln (ein Wunder dass wir überhaupt noch gesund sind bei diesen Schadstoffen früher).
Fall2: Überschwemmung im Juli: 100 L/m² innerhalb von 6 Stunden. Mein Elternhaus unter Wasser. Alle Negative sind verloren gegangen. Warum-weshalb-wieso keine Ahnung. Vermutlich aus Versehen im Chaos entsorgt. PC: zwar voller Schlamm aber alle Daten noch vorhanden.
Dies nur zum Thema analoges Bildmaterial und keine Probleme.
Wenn man von solchen Dingen mal absieht hast Du schon Recht. Minimaler Aufwand um analoge Bilder zu archivieren.
Was mich ärgert, ist dass es keine Software zum Archivieren gibt. Naja bezahlbar meine ich. Backup hilft leider nur für erkennbaren Datenverlust. Für den Rest muss man halt doch einiges per Hand machen. Ach ja meine älteste Datei hat schon 30 Jahre auf dem Buckel.

 

[Unlimited]

Mit Acronis ist ein Verify genauso möglich, d.h. es wird sichergestellt, dass Original und Kopie binär identisch sind.

Wenn der Fehler aber schon im (korrupten) Original drin ist, dann verbleibt er auch im Backup.
Ich habe das Gefühl, beim Backuppen selber gibts keine Korruption der Daten.

Korruption scheint sich jedoch im Lauf der Jahre beim Original einzuschleichen.
Wenn man Pech hat, erkennt das Backupprogramm, dass das Original sich verändert hat und überschreibt die "gute, alte" Kopie auf dem Backup mit der korrupten neuen Version....

Daher sichere ich meine Daten jahresweise auf alte Festplatten, die ich danach nicht mehr anfasse.

 

[IcheBins]

Wenn der Fehler aber schon im (korrupten) Original drin ist, dann verbleibt er auch im Backup.

Auf diesen Umstand wurde im Verlaufe des Threads bereits mehrfach hingewiesen - und bisher hat auch niemand einen Einwand erhoben.


Grüße,
IcheBins

 

[Gast_251461]

Vom alten PC auf die externe HD und dann von dieser auf den neuen PC

Dann könnte die Fehlerquelle auch die externe HD gewesen sein, da, so wie ich es verstanden habe, aber die original Platte im PC geshreddert wurde hilft dir das auch nicht weiter, sonst könnte man dort ggf. noch "gute" Bilder finden.

Gerald

 

[JoeHomeskillet]

Mein Tip:
Kauf dir ein NAS im Raid 1 und lasse die Daten regelmässig sichern.
Dazu noch ab und zu auf eine externe Platte, die du nur für das benutzten solltest.

 

[das_teufelchen]

Das sind doch aber Daten, die Du auf dem alten System schon benutzt (=geschrieben + gelesen) hast und da keine Fehler bemerkt hast. Oder?


Gruß
ewm

Die Daten waren ursprünglich mal in Ordnung. Da bin ich mir sicher

Dann könnte die Fehlerquelle auch die externe HD gewesen sein, da, so wie ich es verstanden habe, aber die original Platte im PC geshreddert wurde hilft dir das auch nicht weiter, sonst könnte man dort ggf. noch "gute" Bilder finden.

Kann auch gut sein. Aber warum nur diese Bilder aus Lightroom?
Die externe habe ich inzwischen mehrfach neu beschrieben und gelöscht etc. ... da einzelne Bilder ohne Fehler raus zu kriegen ist unmöglich

Ich bin immer noch der Meinung das entweder Lightroom, die Umstellung von xp auf Windoof7, oder 32bit auf 64bit schuld ist

Oder es hat mit meinem alten Problem zu tun
https://www.dslr-forum.de/showthread.php?t=922734

Dann müsste aber Lightroom im heutigen Zustand empfindlicher auf Störungen reagieren. Die ich dann früher nicht gesehen habe, aber heute wahrnehme

 

[Unlimited]

Auf diesen Umstand wurde im Verlaufe des Threads bereits mehrfach hingewiesen - und bisher hat auch niemand einen Einwand erhoben.

Habs dann auch bemerkt...

Die Problematik mit korrupten Daten hatten scheinbar echt mehr Leute, als ich gedacht hätte.
Ich nehm seither meine ausgemusterten Festplatten als Dauersicherungslaufwerk.

 

[isibitz]

Mein Problem sind weniger korrupte Daten (dies merke ich in der Regel recht schnell und dafür gibt es das Backup; kommt allerdings sehr, sehr seltgen vor) als vielmehr das Erkennen von fehlenden Bilder/Daten.
Auf meinem Rechner sind Daten die bis zu 30 Jahre alt sind. Mein Backup reicht 3 Jahre zurück. Es kommt relativ selten vor, dass ich Bild von vor 10 Jahren suche. Was ist also wenn ich ein Bild vor 5 Jahren aus Versehen gelöscht habe oder irgendwie anderweitig korrupt wurde? Pech gehabt. Ist im Backup inzwischen überschrieben.
Händisch habe ich das Problem in Griff. Ich finde es nur schade, dass es in unserer EDV-Welt keine automatische Lösung gibt.

 

[Blur]

Auf meinem Rechner sind Daten die bis zu 30 Jahre alt sind.

Das ist pre C64
Wie haben es denn diese Daten auf den PC geschafft?

Händisch habe ich das Problem in Griff. Ich finde es nur schade, dass es in unserer EDV-Welt keine automatische Lösung gibt.

Mit dem System Restore und "alten Versionen" hat doch Windows schon gut was in der Richtung vorgelegt. Wenn man ausreichend Platz hat, klappt das damit.
MacOS hat die TimeMachine, die seit Lion auch in dieser Richtung unterwegs ist und kann direkt auf Datei-/Ordnerebene altes wiederbeleben.

Von Drittanbietern gibt es noch so etwas wie Acronis NonStop-Backup.

Stellt man denen ausreichen Speicherplatz zu Verfügung, machen den Backup schon automatisch.

Was würdest Du Dir noch wünschen?

 

[Gast_252254]

tritt / trat dieser Fehler beim Kopieren vorher noch nie auf? Ich kann mir das nicht wirklich vorstellen dass ausgerechnet beim Kopier/Verschiebevorgang von RAW-Daten sowas pasiert und sich der Fehler (sofern er tatsächlich im System vorhanden ist) sich sonst noch nicht geäußert hat, sei es nun direkt oder symptomatisch.

 

[das_teufelchen]

Ich konnte es jetzt weiter eingrenzen
Ich habe in einem Ordner damals im alten System ein Rar-Verzeichnis mit Bildern abgelegt um es upzuloaden und verteilen
Der Ordner den ich mit kopiert habe hatte 3 CRC Fehler. Den Ordner den ich damals hochgeladen habe und jetzt neu runtergeladen habe hat diesen Fehler nicht
Es kann also nicht am Wechsel zwischen den Systemen liegen sondern nur am Datentransfer