Advanced Backup Forum
backuptask325 hängt während Reservekopie, Validierungsfehler Forum
Letzte Änderung : 19.08.2013
backuptask325 hängt während Reservekopie, Validierungsfehler
Sehr geehrter Volker,
zu 1: Bei einer Laufwerkssicherung ist es die Anzahl der Sicherungsblöcke die nicht gelesen werden konnten bzw. der CRC nicht übereinstimmt.
zu 2: die Reservekopiefunktion muss wohl noch nachkorrigiert werden. Versuchen Sie eine Sicherung durchzuführen ohne eine Reservekopie anzulegen.
zu 3: Da die Aufgabe nicht vollständig ausgeführt wurde, wurde auch der Status nicht geändert und Email nicht verschickt.
zu 4: Fehler auf der Festplatte(Laufwerk für Reservekopie) können den Kopiervorgang erheblich verlangsamen. Dies könnte, je nach Umfang der Sektorenfehler, die Ursache sein, warum sich das Programm aufhängt.
Ich werde Ihren Sicherungsprozess rekonstruieren und es mal testen.
Freundliche Grüße
Evorim Support
zu 1: Bei einer Laufwerkssicherung ist es die Anzahl der Sicherungsblöcke die nicht gelesen werden konnten bzw. der CRC nicht übereinstimmt.
zu 2: die Reservekopiefunktion muss wohl noch nachkorrigiert werden. Versuchen Sie eine Sicherung durchzuführen ohne eine Reservekopie anzulegen.
zu 3: Da die Aufgabe nicht vollständig ausgeführt wurde, wurde auch der Status nicht geändert und Email nicht verschickt.
zu 4: Fehler auf der Festplatte(Laufwerk für Reservekopie) können den Kopiervorgang erheblich verlangsamen. Dies könnte, je nach Umfang der Sektorenfehler, die Ursache sein, warum sich das Programm aufhängt.
Ich werde Ihren Sicherungsprozess rekonstruieren und es mal testen.
Freundliche Grüße
Evorim Support
zu 1: d.h. das archiv ist kaputt? sollte per TCP aber alles fehlerfrei sein? werden denn nochmals die quell-daten gelesen? - und mit dem VSS-snapshot verglichen?
zu 2 und 4: werde reservekopie erstmal abschalten, das laufwerk testen (chkdsk, herstellertool, ..). klar, defekt kann der grund sein...
zu 3: naja, sicherung fertig, status erfolgreich nachvollziehbar irgendwie. aber da die folgenden operationen schief gelaufen sind.... immer noch? besonders validierung? für die zukunft wäre ein wiederholen der restschritte möglich? ohne die ganze sicherung zu wiederholen (falls validierung keine fehler liefert)
zu 2 und 4: werde reservekopie erstmal abschalten, das laufwerk testen (chkdsk, herstellertool, ..). klar, defekt kann der grund sein...
zu 3: naja, sicherung fertig, status erfolgreich nachvollziehbar irgendwie. aber da die folgenden operationen schief gelaufen sind.... immer noch? besonders validierung? für die zukunft wäre ein wiederholen der restschritte möglich? ohne die ganze sicherung zu wiederholen (falls validierung keine fehler liefert)
Sehr geehrter Volker,
zu 1: Es bedeutet nicht, dass das gesamte Archiv kaputt ist, sondern das ein paar Blöcke nicht zu 100 % wiederhergestellt werden können. In Ihrem Fall wären es 2 MB bis 2 GB an fehlerhaften Daten. Jedoch muss ich dazusagen, dass die Validationsroutine bewusst sehr pingelig angelegt wurde um jede kleinste Abweichung als Fehler zu melden. Bei der Validation werden die Daten nicht erneut eingelesen, sondern Anhand einer, bei der Sicherung erstellten, Prüfsumme (CRC32, MD5 oder SHA1) verglichen. Oftmals liegt der Fehler im Kompressionsalgorithmus z.B.: Speed-LZ, der eine etwas größere Datenmenge extrahiert als eingegeben. Bei der Wiederherstellung überspringt das Programm diese Extra-Datenmenge, sodass die Wiederherstellung im Nachhinein dennoch genau das gesicherte Abbild wiedergibt.
Versuchen Sie eine Sicherung mit Deflate (bekannt aus dem ZIP-Archiv). Dieser Kompressionsalgorithmus ist zwar langsamer aber deutlich robuster und unanfälliger gegen Fehler.
zu 4: Theoretisch wäre es auch möglich die restlichen Schritte eines unfertigen Sicherung ablaufen zu lassen. Das Problem ist jedoch der Aufwand und eine sehr hohe Fehleranfälligkeit, wenn ein Prozess mitten in einer Aufgabe begonnen wird. Dies könnte zu unvorhersehbaren abstürzen des Programms führen und mehr Ärger, als das simple Neustarten einer Sicheurung. Dieses Vorhaben habe ich bereits vor 3 Jahren versucht auszuführen, jedoch führte es letztlich zu mehr Problemen als Vorteilen.
Freundliche Grüße
Evorim Support
zu 1: Es bedeutet nicht, dass das gesamte Archiv kaputt ist, sondern das ein paar Blöcke nicht zu 100 % wiederhergestellt werden können. In Ihrem Fall wären es 2 MB bis 2 GB an fehlerhaften Daten. Jedoch muss ich dazusagen, dass die Validationsroutine bewusst sehr pingelig angelegt wurde um jede kleinste Abweichung als Fehler zu melden. Bei der Validation werden die Daten nicht erneut eingelesen, sondern Anhand einer, bei der Sicherung erstellten, Prüfsumme (CRC32, MD5 oder SHA1) verglichen. Oftmals liegt der Fehler im Kompressionsalgorithmus z.B.: Speed-LZ, der eine etwas größere Datenmenge extrahiert als eingegeben. Bei der Wiederherstellung überspringt das Programm diese Extra-Datenmenge, sodass die Wiederherstellung im Nachhinein dennoch genau das gesicherte Abbild wiedergibt.
Versuchen Sie eine Sicherung mit Deflate (bekannt aus dem ZIP-Archiv). Dieser Kompressionsalgorithmus ist zwar langsamer aber deutlich robuster und unanfälliger gegen Fehler.
zu 4: Theoretisch wäre es auch möglich die restlichen Schritte eines unfertigen Sicherung ablaufen zu lassen. Das Problem ist jedoch der Aufwand und eine sehr hohe Fehleranfälligkeit, wenn ein Prozess mitten in einer Aufgabe begonnen wird. Dies könnte zu unvorhersehbaren abstürzen des Programms führen und mehr Ärger, als das simple Neustarten einer Sicheurung. Dieses Vorhaben habe ich bereits vor 3 Jahren versucht auszuführen, jedoch führte es letztlich zu mehr Problemen als Vorteilen.
Freundliche Grüße
Evorim Support
Hallo,
Programmversion 3.38.13220. HDD mit Quelldaten getauscht, Filesystem auf Fehlerfreiheit überprüft. RAM fehlerfrei getestet. Reservekopie jetzt abgeschaltet, auf Deflate umgestellt. Erneut Fehler bei Validierung des Archivs auf dem NAS bei beiden Jobs - ca.1000 Fehler, was nun?
Ich überlege ein paar GB-große Dateien zwischen PC und NAS hin und her zu kopieren und CRCs zu vergleichen. Aber ich kann mir kaum vorstellen, dass oberhalb der CIFS-Übertragung Fehler rauskommen werden. Alternativ könnte ich mal lokal sichern, ob dort noch immer Fehler bei der Validierung auftreten...
Ich habe gerade mal die Logs der letzten 2 Wochen durchgesehen, mit Programmversion 3.37.13199 sind nie Fehler aufgetreten...
Programmversion 3.38.13220. HDD mit Quelldaten getauscht, Filesystem auf Fehlerfreiheit überprüft. RAM fehlerfrei getestet. Reservekopie jetzt abgeschaltet, auf Deflate umgestellt. Erneut Fehler bei Validierung des Archivs auf dem NAS bei beiden Jobs - ca.1000 Fehler, was nun?
Ich überlege ein paar GB-große Dateien zwischen PC und NAS hin und her zu kopieren und CRCs zu vergleichen. Aber ich kann mir kaum vorstellen, dass oberhalb der CIFS-Übertragung Fehler rauskommen werden. Alternativ könnte ich mal lokal sichern, ob dort noch immer Fehler bei der Validierung auftreten...
Ich habe gerade mal die Logs der letzten 2 Wochen durchgesehen, mit Programmversion 3.37.13199 sind nie Fehler aufgetreten...
Sehr geehrter Volker B,
die Validierungsroutine der beiden Versionen ist genau gleich. Ich habe da keine Veränderung durchgeführt.
Eine lokale Sicherung könnte aufschlussreich sein.
Verläuft die Sicherung vollständig, nachdem Sie die Reservekopie ausgeschaltet haben?
Freundliche Grüße
Evorim Support
die Validierungsroutine der beiden Versionen ist genau gleich. Ich habe da keine Veränderung durchgeführt.
Eine lokale Sicherung könnte aufschlussreich sein.
Verläuft die Sicherung vollständig, nachdem Sie die Reservekopie ausgeschaltet haben?
Freundliche Grüße
Evorim Support
Hallo,
also Änderungen oder nicht, es treten sowohl Deflate als auch Speed-LZ Fehler bei der Validierung auf. Fehler auf dem System kann ich wohl inzwischen ausschliessen. Auch bei einer lokalen Sicherung. Ich werde nochmals ABM reinstallieren, vielleicht ändert das was, aber ich bezweifle es.
Nochmals der Hinweis, bei ausführlichem Log wird in der Email ja auch jede gesicherte Datei genannt, dies führt dazu, dass die Email bei 1MB abgeschnitten wird und der wesentliche Teil - das Ende der Sicherung - nicht mehr sichtbar ist. Daher der Vorschlag im Email-Log die Anzahl der genannten Dateien auf z.B. 200 zu begrenzen, danach "..." , dann aber den Rest des Logs mitzusenden.
also Änderungen oder nicht, es treten sowohl Deflate als auch Speed-LZ Fehler bei der Validierung auf. Fehler auf dem System kann ich wohl inzwischen ausschliessen. Auch bei einer lokalen Sicherung. Ich werde nochmals ABM reinstallieren, vielleicht ändert das was, aber ich bezweifle es.
Nochmals der Hinweis, bei ausführlichem Log wird in der Email ja auch jede gesicherte Datei genannt, dies führt dazu, dass die Email bei 1MB abgeschnitten wird und der wesentliche Teil - das Ende der Sicherung - nicht mehr sichtbar ist. Daher der Vorschlag im Email-Log die Anzahl der genannten Dateien auf z.B. 200 zu begrenzen, danach "..." , dann aber den Rest des Logs mitzusenden.
Auch nach Reparatur-/Neuinstallation treten bei der Validierung weiterhin Fehler auf.
Sehr geehrter Volker B,
seltsamerweise treten bei mir nun auch Validierungsfehler auf, wenn ich die Sicherung auf einer Netzwerkfreigabe ablege. Auf einem internen Laufwerk nicht. Ich werde nach der Ursache forschen und das Problem lösen sobald ich es gefunden habe.
Freundliche Grüße
Evorim Support
seltsamerweise treten bei mir nun auch Validierungsfehler auf, wenn ich die Sicherung auf einer Netzwerkfreigabe ablege. Auf einem internen Laufwerk nicht. Ich werde nach der Ursache forschen und das Problem lösen sobald ich es gefunden habe.
Freundliche Grüße
Evorim Support