Öffnen einer Sicherung verlangt nach nicht vorhand. Partion

[WHSnewbee]

Ok, danke für Deine Unterstützung.

Hmm, wo sind wir denn da jetzt gelandet. Kann das an sehr langen Dateinamen liegen, die auf dem Client schon tief in der Struktur liegen ?

Ich werde mir Deinen Tipp ansehen und mir das Tool ansehen. Allerdings erst am 1.5. vorher komme ich nicht dazu.

DANKE !

Gruß Uwe

[Nobby1805]

Die Serversicherung hat damit Probleme .. aber die Clientsicherung ? War mir bisher nicht bewusst .. sollte auch nicht sein soweit ich bisher den Restorevorgang verstanden habe ...
es wird ja im Prinzip nur ein virtuelles Laufwerk aufgebaut und erst einmal nur mit den Strukturdaten des NTFS gefüllt, dabei gibt es dann Lesefehler (warum auch immer) und das Volume ist dann so inkonsistent dass es nicht gemounted werden kann

[Nobby1805]

kannst du bitte auf dem Client den Registrywert HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Home Server\MountBackup\TraceMask ändert ...

Der steht normalerweise auf 7 ... setze ihn bitte auf F ... das Logging nach MountBackup...log wird dann deutlich erweitert

Versuche noch einmal den Restore und poste danach das neue Log

s. auch hier: viewtopic.php?f=50&t=9772&p=147499#p147499

[WHSnewbee]

Ich habe den Eintrag in der Registry auf 1F gesetzt, also maximale Ausgabe an Informationen. Auf dem 4540s habe dann jeweils 2 eigene Sicherungspartionen ohne Probleme geöffnet (wie vorher auch) und danach mit dem 4540s 2 Partionen des 6013eg (LTP2-JAN) mit dem bekannten Problem.

Zu Deinem Analyseprogramm ... ich habe es heruntergeladen und auf dem Server "installiert". Welche Auswertungen möchtest Du haben ? Alles von alles Clients und vom Server ? Nur bestimmte Logs ?

Danke nochmals !

[Nobby1805]

Du siehst mich im Moment ratlos ...
Ich bin mir im Moment auch nicht sicher ob es sich wirklich um einen Lesefehler beim Zugriff auf die Sicherung handelt oder um ein Synch-Problem auf dem Clint wo der Restore läuft

Ausschnitt wen es klappt:

[28.04.2013 18:11:10 620] Parent 6528 sequence 410953
[28.04.2013 18:11:10 620] OPTION: -v <volume> 0 was specified
[28.04.2013 18:11:10 620] OPTION: -X <extend> 927799296 was specified
[28.04.2013 18:11:10 620] GetMountedVolumeLetter: uniqueId = \??\Volume{496453a4-b01d-11e2-84be-74e543f06058}\
[28.04.2013 18:11:10 620] MountedRestoreHelper::GetMountedVolumeLetter() - got volume at Z:\
[28.04.2013 18:11:23 620] File $RECYCLE.BIN found on volume Z:\

und hier klappt es nicht

[01.05.2013 21:23:15 2230] Parent 3840 sequence 32482886
[01.05.2013 21:23:15 2230] OPTION: -v <volume> 0 was specified
[01.05.2013 21:23:15 2230] OPTION: -X <extend> 1921167360 was specified
[01.05.2013 21:23:15 2230] GetMountedVolumeLetter: uniqueId = \??\Volume{f1aa30c1-b248-11e2-a366-74e543f06058}\
[01.05.2013 21:23:15 2230] MountedRestoreHelper::GetMountedVolumeLetter() - got volume at Z:\
[01.05.2013 21:23:16 2230] FindFirstFile failed for volume Z:\, trying GetDiskFreeSpace instead (in case the volume is empty)
[01.05.2013 21:23:17 2230] GetDiskFreeSpace failed on Z:\

Interessant ist im ersten Fall die Pause von 13 Sekunden ... hier werden die Daten vom WHS gelesen und in das virtuelle Laufwerk geschrieben
Im Fehlerfall wird (warum auch immer) nicht gewartet ... und da ist natürlich noch nicht viel im virtuellen Laufwerk abgelegt worden

[WHSnewbee]

Hmmm, damit ist also nicht sicher, ob die sich nicht zu öffnen lassenden Sicherungen selbst in Ordnung sind.

Macht die Bereitstellung von weiteren Daten über Deine EXE vom Server noch Sinn ? Wenn ja, welche Informationen ?

DANKE !

[Nobby1805]

Darüber muss ich erst noch etwas nachdenken und deine und meine Logs nach bestimmten Kriterien analysieren
Evt. gibt es auch eien neue Version des Tools

Ich melde mich

[WHSnewbee]

ok, I watch the spot !

[Nobby1805]

Im Moment tendiere ich wieder zu der Annahme das das Problem auf dem WHS liegt .. aber nicht durch falsche Daten in der Sicherung ausgelöst wird sondern durch eine Übertragungsfehler

typische Sequenz beim "Lesen" eines Blockes vom WHS:

[01.05.2013 21:18:35 2304] Read offset 0 length 1000
[01.05.2013 21:18:35 2304] Asking for Cluster [0:1]
[01.05.2013 21:18:35 2304] Decrypted data: 4100 bytes
0000 5f 00 80 20 eb 52 90 4e:54 46 53 20 20 20 20 00 _.. .R.NTFS .

Ab Block 0 sollen 1000(Hex) Byte gelsen werden, also 4096 Byte = 1 Cluster der Clientsicherung
Decrypted sind es dann 4100 Byte weil die ersten 4 Byte ein Header sind, mit EB 52 90 beginnt der 1. Block der Partition (Volume Boot Record)

Wenn mehr als 8192 Byte gelesen werden sollen dann ergibt sich folgendes

[01.05.2013 21:19:50 1ff8] Read offset 0 length 4000
[01.05.2013 21:19:50 1ff8] Asking for Cluster [0:4]
[01.05.2013 21:19:50 1ff8] Decrypted data: 8192 bytes
0000 5f 00 80 20 eb 52 90 4e:54 46 53 20 20 20 20 00 _.. .R.NTFS .
[01.05.2013 21:19:50 1ff8] Decrypted data: 8192 bytes
0000 00 00 00 00 00 00 00 00:5f 02 80 20 46 49 4c 45 ........_.. FILE
[01.05.2013 21:19:50 1ff8] Decrypted data: 16 bytes
0000 00 00 00 00 00 00 00 00:00 00 00 00 00 00 08 00 ................

Hier sollen 16384 Byte gelesen werden ... im 1. Block werden 8192 Byte geliefert - 4 Byte Header, dann folgt ein weitere Block mit 8192 Byte - 4 Byte Header und dann folgt ein 3. Block mit 16 Byte - ? Byte Header womit dann in Summe die 16384 Byte erreicht werden.

Bei einem Fehler stellt man jetzt Folgendes fest

[01.05.2013 21:23:16 3a8] Read offset 14D9AF000 length 20000
[01.05.2013 21:23:16 3a8] Asking for Cluster [1366447:32]
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 5e af b3 d3 00 01 5f b0:b3 d3 00 80 20 00 08 01 ^....._..... ...
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 f6 17 f7 17 f8 17 f9 17:fa 17 fb 17 fc 17 fd 17 ................
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 ef 27 f0 27 f1 27 f2 27:f3 27 f4 27 f5 27 f6 27 .'.'.'.'.'.'.'.'
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 df 4f e0 4f e1 4f e2 4f:e3 4f e4 4f e5 4f e6 4f .O.O.O.O.O.O.O.O
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 cf 77 d0 77 d1 77 d2 77:d3 77 d4 77 d5 77 d6 77 .w.w.w.w.w.w.w.w
[01.05.2013 21:23:16 3a8] Decrypted data: 8192 bytes
0000 b6 b7 b7 b7 b8 b7 b9 b7:ba b7 bb b7 bc b7 bd b7 ................
[01.05.2013 21:23:16 3a8] Decrypted data: 204 bytes
0000 9d f7 9e f7 9f f7 a0 f7:a1 f7 a2 f7 a3 f7 a4 f7 ................
[01.05.2013 21:23:16 3a8] Error reading cluster 1366447 count 131072

Es sollen 128 KByte gelesen werden ... es werden 6 Blöcke a 8192 Byte angezeigt und dann ein Block mit 204 Byte und dann kommt die Fehlermeldung weil deutlich weniger Daten geliefert worden sind als angefordert
Schon der Anfang des 2. Blockes sieht nicht sehr vertrauenserweckend aus weil dort anscheinend der Header fehlt ... fortgesetztes Datenmuster

Andere Stellen die mit error gekennzeichnet sind sehen genau so aus, aber nicht immer mit so großen Blöcken. Selbst 4096-Byte Blöcke werden manchmal deutlich kürzer geliefert

Aber eine Idee woran das liegt habe ich immer noch nicht

PS Uwe: dein umfangreiches Logging kann ich mir erst am Wochenende ansehen

[Nobby1805]

Auf der Suche nach der Erleuchtung

Falls du Lust hast könntest du jetzt mal Folgendes machen ..
Auf dem Client wie gehabt den Systemparameter auf 1F setzen
Auf dem WSH den Systemparameter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Home Server\Backup\TraceMask auf FF setzen
den Dienst Windows Home Server - Computersicherung (auf dem WHS) neu starten
Warten bis der Backup-Prozess die Startphase beendet hat (CPU-Verbrauch)
einen nicht funktionierenden Restore ausführen
5 Minuten warten
den Systemparameter auf dem WHS wieder zurücksetzen (auf 7 .. erzeugt sonst Unmengen von Logs falls eine Sicherung startet)
den Backup-Prozess wieder restarten

mir beide Logs schicken (auf dem WHS gibt es nur 1 Log pro Tag)

[Nobby1805]

Nach Analyse der Logs ...
bin ich jetzt der Meinung, dass die Sicherungsdaten auf dem WHS nicht defekt sind sondern ...
dass es sich hier um ein Kommunikationsproblem zwischen dem WHS und dem Client handelt

Leider habe ich bisher noch keine Idee was genau da passiert und was man dagegen tun kann

Das Problem tritt an unterschiedliche Stellen während des Restores auf .. in deinem letzten Log sogar direkt beim Zugriff auf den ersten Datenblock (Volume Header)


Die Vorbereitungsphase klappt problemlos ... dann ist 81 % erreicht
In deinem Log klappt das Lesen und Übertragen der Bootinformation zum Client noch einwandfrei und dann sollen die Cluster 0+1 gelesen werden ... aber statt 8192 Byte werden nur 6 Byte übertragen .. und das erzeugt den Fehler

Ich habe inzwischen schon besser verstanden was dort passiert und mein Tool erweitert

Ruf bitte das Tool auf dem WHS auf und wähle zuerst Client spezifisch, dann aus der erscheinenden Client Liste einen Client wählen bei dem das Restore nicht funktioniert und dann in der Dateiliste c.volume.dat und dann auf Scan klicken ... wenn das fertig ist c.volumecluster.4096.dat auswählen, rechts "Dumpfile anlegen" auswählen und noch einmal auf Scan klicken .-..das dauert dann einige Zeit ... zum Abschluss die Datei WHSBackup.txt in einen ZIP packen und mir schicken

[Nobby1805]

Leider enthielt die vorherige Toolversion ein paar bugs
Die neue Version 0.4.4879.28556 enthält jetzt die bekannten nicht mehr

WHSBackup.zip

0.4.4879.28556

(27.74 KiB) 179-mal heruntergeladen

dadurch verändert sich jetzt auch die Vorgehensweise ein klein wenig ...

Ruf bitte das Tool auf dem WHS auf und wähle zuerst Client spezifisch, dann aus der erscheinenden Client Liste einen Client wählen bei dem das Restore nicht funktioniert und dann in der Dateiliste c.volume.dat und dann auf Scan klicken ... wenn das fertig ist c.volumecluster.4096.dat auswählen und noch einmal auf Scan klicken .-..das dauert dann einige Zeit ... zum Abschluss die Datei WHSBackup.txt in einen ZIP packen und mir schicken

[Nobby1805]

und wieder eine neue Version ...

diese Version prüft jetzt, ob alle Datenblöcke zu einer Sicherung lesbar sind ... dafür bitte einen Haken bei "Test Data" ... aber keinen bei "Dumpfile anlegen" sonst wie oben beschrieben

[WHSnewbee]

Nach langer Zeit als Zusammenfassung die wahrscheinliche Lösung des Problems:

- wie man sehen kann ist der Rechner aus 09/2009, also fast 4 Jahre alt, da haben einige im Forum schon von Problemen mit den Platten im H340 berichtet
- Sicherungen ließen sich erstellen
- ab Januar 2013 nur nicht mehr öffnen, bzw. einige wenige waren zu öffnen
- Norbert hat mich mit Tipps und Tools versorgt (DANKE dafür !)
- die Analyse war sehr sehr langwierig und hat teilweise ungewöhnlich langen Analysezeiten geführt
- im Mailverkehr mit Norbert kam von ihm einmal die Frage auf, ob die Platten noch alle in Ordnung seien und dort vielleicht des Rätsels Lösung liegt ?
- ich hatte mit den mir zur Verfügung stehenden Tools gab es keine Grund daran zu zweifeln !
- ich habe dann mit HDtune angefangen weitere Tests durchzuführen, wieder fielen die langen Laufzeiten auf
- sonstige Schreib- und Lesevorgänge waren auf den Platten eigentlich nicht schlecht
- Ende Juni musste ich durch meinen Urlaub "aussetzen" und habe den Rechner komplett runtergefahren
- nach der Rückkehr und dem Neustart erhielt ich in der Konsole eine Reihe von Meldungen, die eindeutig auf Probleme mit der Sicherungs-DB und (!) mit einer der 4 Platten hinwies
- das Reparieren der Sicherungs-DB per Konsole brachte nichts, der Dienst war auch nicht zu starten
- Danach ging nach dem Lesen anderer Einträge hier im Forum ganz einfach:
- ich habe mit dann einen neue Platte besorgt
- die alte sauber entfernt
- die Sicherungs-DB gelöscht
- Rechner durchstarten, alle Dienste waren wieder da
- Sichern von 2 Clients
- Testen des Öffnens der neuen Sicherungen klappte ohne Probleme, auch wechselseitig ohne Probleme

Gut, ich habe die alten Sicherungen verloren. Damit konnte ich jetzt leben. Hauptsache ich kann wieder arbeiten und der WHS1 macht was er soll.

"Ich hasse Vermutungen", aber ... ich vermute, dass der Ursprung des Problems klar die defekte Platte war. Die Zugriffszeiten bei dem Öffnen waren wohl so schlecht, dass letztlich der Prozess des Öffnens abgebrochen wurde. Norberts Annahme in einer der Mails. Auch wenn die Platte bis Ende Juni keinen Anlass zu Sorgen gab.

Irgendwie etwas dubios. Vielleicht hilft es anderen noch weiter.

Danke nochmals an Norbert für Deinen Service !!

Gruß Uwe

[Nobby1805]

Danke für die Rückmeldung ... gut das es wieder funktioniert