[catweezle]

Hallo!

Folgende Hard- und Software habe ich:
Dell Laptop XPS 1530
Betriebssystem Windows Vista Ultimate 32 bit

Habe vor ca. 3 Wochen eine Sicherung mit dem Vista-Tool "Sicherung von Dateien oder des ganzen Computers" (unter Systemsteuerung) gemacht, das ganze wurde auf einer externen Festplatte gespeichert.

Anschliessend gab es noch 3 weitere Sicherungen mit dem gleichen Tool auf der gleichen externen Festplatte.

Prompt ist meine Festplatte abgeschmiert und musste vom Dell Support ausgetauscht werden, die Daten sind natürlich weg. Nun habe ich versucht die Daten wieder herzustellen mit der Funktion unter der gleichen Rubrik, die da heisst: "Wiederherstellung von Dateien oder des ganzen Computers"

Ich bin so vorgegangen:
- "Erweiterte Wiederherstellung"
- "Dateien wiederherstellen" - "Erweiterte Wiederherstellung"
- "Dateien aus einer auf einem anderen Computer erstellten Sicherung"
- Unter "Festplatte, CD oder DVD" wähle ich meine externe Festplatte aus
- dann werden alle vier Sicherungen mit Datum angezeigt, es heisst aber unter "Sicherungsort": "Auf den Sicherungsort kann nicht zugegriffen werden", ich habe die aktuellste Sicherung ausgewählt und trotzdem "Weiter" gedrückt
- "Alles aus dieser Sicherung wiederherstellen"
- "Am Ursprungsort" - "Wiederherstellung starten"

Und dann heisst es: "Die Wiederherstellung wurde nicht erfolgreich abgeschlossen. Die Wiederherstellung war nicht erfolgreich. Fehlercode: [keiner wird angegeben] Die Sicherungsdatei wurde nicht gefunden. Überprüfen Sie die Hardwarekonfiguration, oder führen Sie eine Wiederherstellung von einer anderen Sicherung durch. (0x8100001A)"

Ich kopiere gerade alle Backups auf meinen Computer und versuche, die Daten von dort wieder herzustellen, mal sehen ob das klappt.

Hat irgend jemand sonst eine gute Idee? Thanx im voraus!

[Black-Luster]

Wie es scheint, ist das ein Bug (oder beabsichtigt?), dass wenn sich die Vista Installation als eine "andere" Indentifiziert, dass dies abbricht. Du müsstest jetzt meines wissens den Mühsamen weg gehen und jede einzelne ZIP Datei entpacken. Diesen Bug hätten die ruhig mit dem SP1 beheben können -.-
Ich sichere meine Dateien auch auf diese Art und weise, allerdings frage ich mich immer mehr, ob ich vllt doch nicht eine alternativlösung suchen soll...
Vielleicht mal dies in den Microsoft Supportforen anfragen? Vielleicht haben die ein workaround für dich...

[rubberduck]

Hallo,
Du verwendest aber schon die Vista-Install- Cd? Denn ohne dies geht es nicht wirklich gut.
Da hast beim Start der DVD ein Auswahlmenü mit welchem du die Wiederherstellung startest. Dabei wählst du dann das betr. Laufwerk aus und führst die Schritte aus.
Du musst all die Schritte, wenn nötig, als Admin ausführen!!!

MfG rubberduck

[Superpeppi]

Zitat (catweezle: 21.05.2008, 17:51)

es heisst aber unter "Sicherungsort": "Auf den Sicherungsort kann nicht zugegriffen werden", ich habe die aktuellste Sicherung ausgewählt und trotzdem "Weiter" gedrückt

Das deutet darauf hin das du auf die Sicherung keinen Lesezugriff hast.
Ändere mal die Sicherheitseinstellungen für die Sicherungsdateien auf Vollzugriff, das sollte eventuell schon helfen.

[catweezle]

@Superpeppi (bezgl. Lesezugriff): hatte ich bemerkt und schon geändert, hat jedoch am Problem nichts geändert

@Black-Luster (bezgl. zip-Files einzeln entpacken): Du entpackst also alle 873 zip-Files einzeln von Hand ...?! Oder hast Du da ein Tool, was Dich unterstützt?

[GunZen]

Moinsen und herzlich willkommen hier im Forum.

Vielleicht ist die neue Platte anders partitioniert? Dann verweigert Ultimate nämlich die Wiederherstellung...

GunZen

[Internetkopfgeldjäger]

Sieht wohl so aus,
als wären Microsoft Windows Vista Backups total sinnlos:
http://support.micro...om/kb/940263/de

Die machen *.bin Dateien, welche die Backups beschreiben
und legen die auf dem Laufwerk ab, was entsorgt wird,
also auf dem Laufwerk das gesichert wurde.
Das entsorgte Laufwerk enthielt in seinem Wurzelverzeichnis
(Windows-Sprech: Stammverzeichnis) *.bin Dateien.
(bin weist gewöhnlich auf Binärdateien hin, die für Menschen unlesbar sind)
Diese *.bin Dateien sollen dann beschreiben, wo und wie das Backup
wieder zurückzuholen ist.
Aber diese Steuerdateien, in für Menschen unlesbarem Binär Format,
sind ja entsorgt worden, auf der kaputten Festplatte.

Geht die gesicherte Festplatte kaputt, ist das Backup ebenfalls völlig wertlos!
Selbst wenn die Sicherung ansonsten unbeschädigt
und gut aufbewahrt ist.
Ich ziehe mit allertiefstem Respekt den Huth, für solch eine Microsoft Meisterleistung!
Da machen kaputte Festplatten doch gleich nochmal so viel Spaß!


@catweezle:
Mein allertiefstes Beileid zu Vista
und dem daraus resultierendem Datenverlust
trotz brav gemachter Backups!
Ich habe schon ganz dreckig, bei nicht dafür gedachten
Systemen, mit GNU tar kopiert und obwohl dieses GNU tar
chflags nicht sichern kann, bekommt man damit nicht solche
Probleme, wenn das Quellaufwerk, das gesichert wurde, kaputt ist.
Hier mal eine kleine Komandozeile für gtar
(das GNU tar, Linux Benutzer lassen einfach das "g" weg)

gtar clfp - -C / . | gtar xpvf - -C /mnt/_new

Dabei ist "/" das Wurzellaufwerk und der Mountpoint "/mnt/_new"
ist das Verzeichnis, in das logisch die physikalische Sicherungsplatte gemountet wurde.
Das muss mit jeder Partition einzeln gemacht werden.
Im Windows Sprech: "C" ist eine Partition, "/" muss durch den Mountpoint erstetzt werden,
wo die Windows Partition hingemountet wird.
Da nach dem Pipedingens "|" das gepackte tar Archiv gleich wieder ausgepackt wird,
kann man die Sicherungsplatte auch einfach anstelle der abgerauchten Platte
einbauen und wenn das Betriebssytem keinen Blödsinn macht, bootet es auch
gleich von der Sicherungsplatte. Könnte natürlich sein, das Vista da noch
so ein paar weiter "Wie schieße ich mir selbst ins Knie" Mechanismen eingebaut hat.
Natürlich muss die Backup-Festplatte mindestens so groß sein, wie die zu Sichernde
Festplatte, wenn man so eine 1:1 Backup-Kopie nutzen will, sie darf aber auch größer sein.
Sind Festplatten genau gleich groß, ließen sich auch mittels dd bitgenaue Backups erstellen,
oder mit g4u: http://www.feyrer.de/g4u/
Um solche Unix Lösungen für andere Systeme zu nutzen, muss z.B. das
Windows Problem in irgendein Unix System gemountet werden.
Kann man auch mit irgendeiner Live-CD oder Live-DVD machen,
z.B. mit Knoppix.
Für das bereits abgerauchte Vista dürfte aber jede Hilfe zu spät kommen.


Gruß, Internetkopfgeldjäger

[dblay]

@ Internetkopfgeldjäger: Da hast du was falsch verstanden, die besagte *.bin-Datei (MediaID.bin) befindet sich auf dem Sicherungsdatenträger, und nicht auf dem Datenträger, der gesichert wird. (Das würde ansonsten ja auch wirklich keinen Sinn ergeben)

Dieser Beitrag wurde von dblay bearbeitet: 27. Mai 2008 - 14:52

[Internetkopfgeldjäger]

Zitat (dblay: 27.05.2008, 15:51)

@ Internetkopfgeldjäger: Da hast du was falsch verstanden, die besagte *.bin-Datei (MediaID.bin) befindet sich auf dem Sicherungsdatenträger, und nicht auf dem Datenträger, der gesichert wird. (Das würde ansonsten ja auch wirklich keinen Sinn ergeben)

Genau das schreibt aber Microsoft.
Das solch ein *.bin Unsinn für Backups keinen Sinn macht, ist mir schon klar.
Genau wegen diesem *.bin Unsinn dürfte catweezle sein Problem haben.
Mir graust's schon jetzt, da meine neue Hardware
(voraussichtlich irgend so ein T9300 Klappcomputer, wenn endlich lieferbar)
wohl auch mit diesem Vista Zeugs serienmäßig verseucht sein wird.


Gruß, Internetkopfgeldjäger

[dblay]

KB 940263 sagte:

1. Locate the root directory of the drive or the file share where the backup was originally stored.
2. Copy the Mediaid.bin file.

Ergo: Die MediaID.bin befindet sich auf dem Datenträger, der das Backup beinhaltet. (Ist bei mir z.B. auch so.) Sicherlich hätte sich Microsoft auch entscheiden können, die Daten z.B. in einer xml-Datei zu speichern, aber unabhängig davon kann die MediaID.bin eigentlich nicht verloren gehen.

Zum Thema: Solange catweezle nicht an den Backups irgendwas modifiziert hat, dürfte das Problem nicht an einer fehlenden MediaID.bin liegen.

Dieser Beitrag wurde von dblay bearbeitet: 28. Mai 2008 - 18:00

[Internetkopfgeldjäger]

Zitat (dblay: 27.05.2008, 17:34)

Ergo: Die MediaID.bin befindet sich auf dem Datenträger, der das Backup beinhaltet. (Ist bei mir z.B. auch so.) Sicherlich hätte sich Microsoft auch entscheiden können, die Daten z.B. in einer xml-Datei zu speichern, aber unabhängig davon kann die MediaID.bin eigentlich nicht verloren gehen.

Zum Thema: Solange catweezle nicht an den Backups irgendwas modifiziert hat, dürfte das Problem nicht an einer fehlenden MediaID.bin liegen.

Microsoft faselt leider wirr das Gegenteil von dem,
was Du ohne Quelle in Zitat-Tags hier postet.
Es wird wohl sicherer sein, auf lange bewährte Backuplösungen,
wie z.B. das GNU tar zu setzen,
falls kein dump & restore möglich ist.

Dieser Beitrag wurde von Internetkopfgeldjäger bearbeitet: 27. Mai 2008 - 17:54

[dblay]

Ah ... jetzt wird mir einiges klar. Ich hatte den KB-Artikel in der Englischen Version gelesen (aus welcher im Übrigen auch das Zitat stammt) - die maschinelle Übersetzung ins Deutsche verdreht den Sinn des zitierten Satzes jedoch komplett. (Deswegen lese ich die KB-Artikel auch immer auf Englisch )

PS. Sorry wegen der Quellenangabe, hatte ich vergessen, jetzt jedoch ergänzt.

[GunZen]

Moinsen,

also ich muss jetzt noch mal was dazu sagen:

Kann es sein, dass der Threadsteller auf seiner ersten originalen HDD beispielsweise zwei Partitionen drauf hatte (C: und D:) und die externe HDD dann E: war?

Jetzt hat er eine neue HDD eingebaut bekommen und hat nur noch eine Partition C: drauf, deswegen ist die externe HDD nun D: und somit funktioniert die Wiederherstellung nicht!

Der Artikel besagt, dass auf seiner externen Platte im Rootverzeichnis eine Mediaid.bin ist. Wenn also nun sein Backup umgezogen ist, beispielsweise nach D:, dann muss er die Mediaid.bin auch dorthin kopieren!

Ich lese die Artikel auch immer auf englisch, weil die deutsche Übersetzung mehr als eine Zumutung ist!!!

Und den Käse mit "die Mediaid.bin befindet sich auf der Systemplatte" oder sowas vergeßt mal ganz schnell! Ich habe auf einem unserer Werkstatt-Rechnersklaven bereits etliche Male mit der PC-Complete-Sicherung alles tutti kompletti zurückgeholt... und das einwandfrei! Irgendwas ist mit dem Backup oder der Partitionierung nicht in Ordnung, ganz sicher!

GunZen

[catweezle]

@alle fleissigen "Helfer":

- Tatsächlich hat mit der DELL-Techniker eine Partition auf meiner HD gekillt, vorher hatte ich dort das C: mit rund 230GB und ein kleines D: mit rund 5GB. Jetzt gibt es dort nur noch das C:. Wenn ich bei Datenträgerverwaltung schaue sind aber neben meinem C: mit jetzt 229GB auch noch eine Partition mit 47MB und eine mit 3GB auf meiner neuen HD. Möglicherweise versteckt sich dort die Partition, die ursprünglich mit D: bezeichnet war? Weil es vorher ja C: und D: gab muss meine externe Festplatte eigentlich eine F: gewesen sein. Ich habe sie daher auch in der Datenträgerverwaltung von E: in F: umbenannt und die Wiederherstellung nochmal laufen lassen ... leider funzt es immer noch nicht!

- Mööööglicherweise könnte es ja aber auch an einem Sektorenfehler der externen HD liegen? Wenn ich die externe HD manuell auf eine andere externe HD kopieren will gibt es mir bei zwei ZIP-Files Fehler an, beim Zugriff auf zwei jpg-Dateien in diesem ZIP-File klackert die externe Platte leise und der Zugriff wird verweigert: Sektorenfehler? Würde es helfen, diese Sektoren mittels Prüftool auszuschalten und dann nochmal Wiederherstellung zu probieren? Welches Prüftool soll ich nehmen? Ist eine Mevis-HD mit wahrscheinlich Samsung-Festplatte drin.

Greetz. Catweezle

Habe die HD mal mit dem Vista-Tool "Fehlerüberprüfung" überprüft, das findet sich unter:

Systemsteuerung
Verwaltung
Datenspeicher
Datenträgerverwaltung
rechte Maustaste auf Volume: Eigenschaften
Tools
Fehlerüberprüfung
Jetzt prüfen
Dateisysteme automatisch korrigieren + Fehlerhafte Sektoren suchen/wiederherstellen

Leider hat sich diese Prüfung mit der Meldung "11278 Indexeinträge verarbeitet" wahrscheinlich erhängt ... es kommt auch nach 15 Min. keine Rückmeldung.

[dblay]

Der LW-Buchstabe des externen Laufwerks ist völlig egal (u.a. dafür gibt es ja die MediaID.bin) - daran kann's also nicht liegen.

Bitte versuche doch nochmal, die chkdsk.exe auszuführen. Zuallererst solltest du deine externe Festplatte abmelden, damit keine Handles mehr auf das LW verweisen. Dann schließt du die Festplatte neu an, im Autostart-Dialog klickst du ggf. auf Abbrechen. Daraufhin startest du eine Eingabeaufforderung mit Admin-Rechten und gibst den Befehl chkdsk e: /f /r (wobei e: für den LW-Buchstaben der ext. Festplatte steht) ein.

Es kann durchaus sein, dass die Ausführung an einer Stelle länger "hängen" bleibt, im Zweifelsfall solltest du einfach eine Weile abwarten. Falls das alles nicht hilft, kannst du den Parameter /i ergänzen - dieser bewirkt, dass die Überprüfung der Indexeinträge übersprungen wird.