Archiv Windows XP 25.916 Themen, 128.567 Beiträge

Verfolgung starten Optionen

Nochmal die Warnung vor dem Windows-Sicherungsprogramm

Tilo Nachdenklich / 20 Antworten / Baumansicht Nickles

Ich habe es gerade zweimal durchprobiert. Die C-Partition ist 3,9 GB groß (Datenmenge). Die erstellte Sicherungsdatei (.bkf) ist 3,87 GB groß...warum auch immer. Davon werden auf eine andere Festplatte nur 3,33 GB zurückgespielt. Es verschwinden bei der Prozedur keineswegs überflüssige Dateien, sondern z.B. im System32-Ordner jede Menge exe-Dateien, z.B. auch die ntoskrnl.exe.
Wenn die Festplatte abraucht, ist mit so einem Backupprogramm nichts anzufangen, das zurückgespielte "Backup" macht nicht mal eine Reparaturinstallation mit, denn die Windows-CD erkennt schlicht nicht das zurückgespielte Windows.
Das ist nicht die erste schlechte Erfahrung mit der Windows-Sicherung seit ServicePack2.

Interessanter Weise wird auch stets bei der Prozedur die Systemzeit gründlich verstellt.

out-freyn Tilo Nachdenklich „Nochmal die Warnung vor dem Windows-Sicherungsprogramm“
Optionen
das zurückgespielte "Backup" macht nicht mal eine Reparaturinstallation mit, denn die Windows-CD erkennt schlicht nicht das zurückgespielte Windows.

Wenn man schon statt eines Imaging-Programms das Windows-Backup benutzen will, wie wär's dann mit einer etwas weniger umständlichen Vorgehensweise? Auf die neue Festplatte (C) Windows installieren und dann von dieser Windows-Installation aus das Backup zurückspielen.
Borlander out-freyn „das zurückgespielte Backup macht nicht mal eine Reparaturinstallation mit, denn...“
Optionen
Auf die neue Festplatte (C) Windows installieren und dann von dieser Windows-Installation aus das Backupbild zurückspielen.
Das ist doch AFAIR auch der _einzige_ Weg der beim Windows-Backup vorgesehen ist?
Olaf19 out-freyn „das zurückgespielte Backup macht nicht mal eine Reparaturinstallation mit, denn...“
Optionen

Das würde ich im Prinzip zwar genau so machen, das erklärt aber IMHO keinesfalls, warum a) die Systemzeit verstellt wird und b) ein halbes Gigabyte flöten geht...

CU
Olaf

out-freyn Olaf19 „Das würde ich im Prinzip zwar genau so machen, das erklärt aber IMHO...“
Optionen

Systemdateien, die gerade in Gebrauch sind, können nicht mitgesichert werden u.a. gehören da auch diverse Logfiles und Caches dazu. Wichtige Systemdateien sollten auch nach dem Zurückspielen nicht fehlen, daher ist ja vor dem Zurückspielen erforderlich, dass das Betriebssystem vorhanden ist.
Selbstverständlich können wichtige Systemdateien nicht ausgetauscht werden, solange Windows aktiv ist.

Das mit der Systemzeit... keine Ahnung. Auf Tilos System scheinen merkwürdige Dinge an der Tagesordnung zu sein. :-)

Tilo Nachdenklich out-freyn „Systemdateien, die gerade in Gebrauch sind, können nicht mitgesichert werden...“
Optionen

Stimmt nicht, ich hatte Volumen-Schattenkopie gewählt und die Sicherungs-bkf-Datei hatte ja noch fast die volle Originalgröße. Der Fehler passierte beim Zurückschreiben und wurde nicht mal im Protokoll vermerkt.

Mag sein, dass ich was verkehrt verstanden hatte. Bisher konnte ich stets lesen die Sicherung (= NT-Backup) sei bei der Home-Edition abgespeckt, man müsse da zuerst Windows aufspielen. Im Umkehrschluss dachte ich, wenn ich jetzt WinXP Prof habe, entfiehle dieser Schritt. Ich wollte nur eine C-Partition auf ne andere Platte klonen...mein altes DriveImage5 machte nämlich zunächst Schwierigkeiten. Daher habe ich nicht die Variante gewählt, bei der die gesamte Festplatte gesichert wird, also nicht die Variante mit Wiederherstellungsdiskette.

GarfTermy Tilo Nachdenklich „Nochmal die Warnung vor dem Windows-Sicherungsprogramm“
Optionen

ntbackup ist auch nicht dazu da das gesamte system zu sichern. den anspruch hat das proggi auch gar nicht.

wenn man etwas ungeeignet einsetzt, muß man sich über das suboptimale ergebnis nicht wundern.


;-)

Tilo Nachdenklich GarfTermy „ntbackup ist auch nicht dazu da das gesamte system zu sichern. den anspruch hat...“
Optionen

NT-Backup soll durchaus auch ganze Festplatten sichern. Aber Partitionen allemal und Betriebssystempartitionen, na gerade die! Banales Datenbackup kann ich ja auch mit Synchronisationsprogrammen machen.

Das war schon unter Win98 so. Die Software hatte mal Seagate entwickelt - vor allem für Bandlaufwerke - und damals funzte sie.

Sovereign Sylvia Tilo Nachdenklich „Nochmal die Warnung vor dem Windows-Sicherungsprogramm“
Optionen

Hi Folks,
eure Ausführungen bestätigen einmal mehr meine Backup-Vorgehensweise: Ein zweites OS installieren, dieses starten und dann das erste OS im Naturalformat auf eine andere Partition, besser noch eine zweite HDD, kopieren und bei Bedarf selektiv oder komplett zurückkopieren (Die dabei anfallenden Zeiten kann man bequem nutzen, um sich was zum Essen zu machen oder ein Telephonat zu führen oder ein früheres Essen zu entsorgen etc.). Dabei ist es sogar von Vorteil, wenn das (oben) als Zweit-OS bezeichnete eigentlich das erste und auf C: ist, während das (oben) als Erst-OS bezeichnete sich z.B. auf D: befindet. Hat man das OS auf D: auf einer zweiten Platte gesichert und die erste raucht ab, kann es schon genügen, auf einer neuen Erst-HDD ein Minimal-OS auf C: zu installieren, dabei die gleiche Partitionsaufteilung wie auf der alten HDD vorzunehmen und später das Backup von der Zweit-HDD auf D: zurückzukopieren. Mit meinem Win2000 Pro habe ich das schon durchexerziert, und es hat auf Anhieb geklappt. Das OS auf C: kann man auszer zum Backup des anderen OS auch noch für Installations-Experimente benutzen.

HAND
Sylvia

Tilo Nachdenklich Sovereign Sylvia „Hi Folks, eure Ausführungen bestätigen einmal mehr meine...“
Optionen

In meinen PC sind Wechselrahmen installiert. Es lief ein System auf einer S-ATA-Platte, der Desktop ruhte jedoch. Die aktive C-Partition wurde per Volumen-Schattenkopie auf eine Partition einer zweiten S-ATA-Platte (im Bios nicht-startbar eingetragen) in die übliche bkf-Datei geschrieben und dann auf eine PATA-Platte per Sicherungsprogramm zurückgeschrieben (entpackt).
Diese PATA-Platte wurde dann allein im System belassen - und es wurde versucht sie mit allen Tricks zum Starten zu bekommen:
PartitionMagic-Notfalldisketten, fdisk /mbr, per Rettungskonsole bootcfg /rebuild und manuelle Manipulation der boot.ini usw., testdik, Neuinstallation => Reparaturinstallation. Es konnte nicht gelingen, weil jede Menge exe-Dateien im System32-Ordner fehlten.

Ich kenne das Problem auch schon von der Home-Edition her (da mit Vorinstallation eines neuen Windows); es besteht seit ServicePack2.

Olaf19 Sovereign Sylvia „Hi Folks, eure Ausführungen bestätigen einmal mehr meine...“
Optionen

Hi Sylvia,

das habe ich vor Jahren auch einmal so versucht, damit aber keine guten Erfahrungen gemacht. Im Prinzip hat es zwar funktioniert, aber das System lief instabil. Anscheinend reicht es nicht aus, alle Dateien und Ordner zu kopieren, es muss wohl auch eine gewisse "Struktur"(?) erhalten bleiben, d.h. manche Dateien gehören wohl an einen ganz bestimmten Platz auf der Partition (wiederum: ?), und das schaffen anscheinend nur bitgenau arbeitende Images.

Unter MacOS X macht deine Vorgehensweise übrigens keine Probleme!

CU
Olaf

Sovereign Sylvia Olaf19 „Hi Sylvia, das habe ich vor Jahren auch einmal so versucht, damit aber keine...“
Optionen

Hi,
"manche Dateien gehören wohl an einen ganz bestimmten Platz auf der Partition": Meinst du damit die Dateien im Bootsector? Ansonsten kann ich mir nicht vorstellen, dass Windows-Dateien einen ganz bestimmten Platz auf der Partition haben müssen, damit das System stabil läuft. Das ist auch der Grund, warum mein Haupt-OS sich auf E: und nicht auf C: befindet; da muss ich mir keine Gedanken machen, ob beim Zurückkopieren alles an bit-getreuer Stelle innerhalb der Partition zu liegen kommt oder nicht.
Ich kann nur wiederholen: Installiert ein Minimal-OS auf C:, das Haupt-OS und alle Programme den Rest woanders und lasst C: in Ruhe !

HAND & HANW
Sylvia

Olaf19 Sovereign Sylvia „Hi, manche Dateien gehören wohl an einen ganz bestimmten Platz auf der...“
Optionen

Hi nochmal, ich kann's mir auch nicht wirklich vorstellen - entweder die Dateien sind vorhanden, oder eben nicht. Aber irgendwoher müssen die Imaging-Programme ja ihre Daseinsberechtigung haben, sonst könnte man ja einfach mit Hilfe von Bart's PE Builder oder von einer Zweitinstallation aus das Betriebssytem datei- und ordnerweise einfach per Drag and Drop rüberkopieren - und genau damit hatte ich vor einigen Jahren Schiffbruch erlitten.

Interessant ist dein Ansatz aber allemal!

CU
Olaf

Sovereign Sylvia Olaf19 „Hi nochmal, ich kann s mir auch nicht wirklich vorstellen - entweder die Dateien...“
Optionen

Hi Olaf,
vielleicht hat es etwas mit der Windows-Version zu tun. Der Thread wurde zwar unter Windows XP Pro gestartet, aber - falls das nicht richtig rübergekommen ist - ich benutze W2K, und darunter funktioniert das datei- und ordnerweise Drag'n'Drop-Kopieren (vielleicht ist das unter XP anders). Ich mache das so seit Jahren - ohne Probleme. Mehr Probleme hatte ich anfangs, als ich noch Ghost für Backups benutzte. Da passierte es manchmal, dass Ghost die Backup-Datei einfach nicht zurückschreiben wollte. Das war ja der Grund, warum ich auf die Natural-Backup-Methode umgestiegen bin.
Ich habe sogar mal folgendes gemacht und war selbst erstaunt, wie problemlos das funktionierte: Ich habe insgesamt vier OS auf ein und derselben HDD. Irgendwann mal kam ich nicht mehr umhin, Laufwerke gröszenmäszig erweitern zu müssen (ich habe 11 Laufwerke auf meiner primären HDD). Also habe ich das OS auf C: gestartet und die anderen 3 OS per Drag'nDrop auf eine zweite Platte kopiert (alle anderen Daten natürlich auch). Als nächstes habe ich bei der Prim-HDD sämtliche Laufwerke bis auf C: gelöscht und wieder neu angelegt, also wieder dieselbe Zahl der Laufwerke, aber mit anderer Gröszenverteilung. Danach habe ich alles wieder zurückkopiert und jedes der OS gestartet. Null Probleme: Jedes OS hat die neue Situation registriert, von sich aus die Registry (und weisz der Geier was sonst noch) aktualisiert und dann nur nach einem Neustart verlangt. Fertig.
Sollte so etwas mit XP nicht möglich sein?
Und wenn du sagst, dass mit der Drag'n'Drop-Methode Schiffbruch (was passierte da eigentlich?) erlitten hast, hast du die Methode auf C: angewandt bzw. das Laufwerk, das ntlr, boot.ini und andere Systemdateien enthält? Dann kann ich mir vorstellen, dass es Probleme gibt. Solche Erfahrung habe ich einmal in DOS-Zeiten gemacht, als die System-Dateien hauptsächlich aus IO.SYS und MSDOS.SYS bestanden; die kann man in der Tat nicht einfach auf das Ursprungslaufwerk zurückkopieren, die müssen tatsächlich an einer ganz bestimmten Stelle auf dem Laufwerk sein (aber da erzähle ich dir wohl nix neues).

HAND &HANW
Sylvia

Olaf19 Sovereign Sylvia „Hi Olaf, vielleicht hat es etwas mit der Windows-Version zu tun. Der Thread...“
Optionen

Hi nochmal,

eigentlich sollte es zwischen XP und 2000 diesbezüglich keinen (gravierenden) Unterschied geben, die Architektur dieser Systeme ist ja sehr ähnlich. Warum es mit der Methode "natural" nicht ganz befriedigend funktioniert hat, kann ich nicht sagen. Wenn tatsächlich NTloader oder boot.ini nicht an der richtigen Stelle gelegen hätten, wäre das System gar nicht erst gestartet - das scheidet also aus. Ich kann mich nur noch erinnern, dass sich das System beim Betreten der Benutzerkontenverwaltung sofort aufgehängt hat, sowie bei mindestens einer weiteren Gelegenheit (ist schon ziemlich lange her).

Außerdem erinnere ich mich an ein Gespräch mit einem IT-Admin aus meiner alten Firma, der oft stundenlang damit beschäftigt war, Daten zu "migrieren", was nichts weiter bedeutete, als sie von Laufwerk X nach Laufwerk Y zu schaufeln. Da habe ich ihn einmal gefragt, warum man nicht einfach per Drag and Drop den Gesamtinhalt des einen Laufwerks auf das andere schieben kann. Da meinte er nein, das ginge nicht, damit würden ja nur die Daten kopiert, nicht aber die "Benutzerrechtestruktur" o.Ä.). Wäre mal ein interessantes Thema für einen eigenständigen Thread, was es damit genau auf sich hat.

Nach deinen Ausführungen werde ich aber noch einen 2. Versuch mit dem dateiweise Kopieren von Ordnern und Dateien bei XP unternehmen!

THX
Olaf

Borlander Olaf19 „Hi nochmal, eigentlich sollte es zwischen XP und 2000 diesbezüglich keinen...“
Optionen
Wenn tatsächlich NTloader oder boot.ini nicht an der richtigen Stelle gelegen hätten
Das sollte zumindest bei NTFS als Dateisystem ausscheiden, dort ist die lage dieser Dateien AFAIK egal :-)

Was generell bei einer dateiweisen Kopieraktion als Störquelle zu erwarten ist, ist die Identifaktion der Datenträger über eine ID - zumindest beim kopieren von einer auf eine andere HDD gibt das damit ein Problem weil Windows dann seinen Systemdatenträger nicht mehr finden kann...

Gruß
bor
Olaf19 Borlander „ Das sollte zumindest bei NTFS als Dateisystem ausscheiden, dort ist die lage...“
Optionen

Du meinst wahrscheinlich die GUID der Festplatte? Nebenbei, das hat nichts mit dem dateiweisen Kopieren zu tun - das habe ich auch mit Acronis TrueImage schon erlebt, wenn ich das Image von meiner Maxtorplatte hergestellt und auf die Seagateplatte zurückgespielt habe.

CU
Olaf

Borlander Olaf19 „Du meinst wahrscheinlich die GUID der Festplatte? Nebenbei, das hat nichts mit...“
Optionen

Klar, das ist natürlich auch dann ein Problem. Wobei ein solches Tool natürlich zumindest theorietisch in der Lage wäre die DatenträgerID an zu passen ;-)

Gruß
bor

Tilo Nachdenklich Borlander „ Das sollte zumindest bei NTFS als Dateisystem ausscheiden, dort ist die lage...“
Optionen

Es geht um den Festplatten-GUID bei NTFS-Formatierung. Der GUID wird sowie so für den MBR generiert und hilft dabei Ärger zu machen (!), etwa eine Neu-Aktivierung zu verlangen, nur weil man ein paar alte Festplatten (alte Daten) im Wechselrahmen einschiebt. Erklärt auch warum die wackligen externen USB-Festplatten so beliebt sind, sie werden als Wechseldatenträger nicht von der Windows-Aktivierung belangt.
http://de.wikipedia.org/wiki/GUID

Dieser GUID wird auch für die Partitionierung in die Registry geschrieben, also ein Hexadezimalcode, eine Zahl in der der FestplattenGUID und die Partitionierung miteinander "verrechnet" sind. Wird das Image-Backup dann auf einer anderen Festplatte gestartet, bemerkt Windows beim Hochfahren den "Fehler" und startet nicht zu Ende. Wenn man den FestplattenGUID per Win98 Startdiskette mit dem Befehl fdisk /mbr löscht, macht Windows beim nächsten Hochfahren diese Registry-Einträge neu...und lässt sich dabei bis zu 5 Minuten Zeit. Solange erscheinen auf dem Desktop keine Symbole und eine Zeit lang erscheint der Rechner inaktiv. Wenn man Pech hat muss man auch mit der Reparaturkonsole die Boot.ini neu machen. Dass die Partition aktiv gesetzt werden muss dürfte sowie so klar sein. Zwar ist eine Imagepartition aktiv, wenn das Original aktiv war, aber wegen Laufwerkbuchstabenchaos versteckt man ja gerne Image-Partitionen; dabei verlieren sie ihren Aktiv-Status. Aktiv setzen geht z.B. mit PartitionMagic (Notfalldisketten...für große Festplatten Win98-Startdiskette einsetzen!) oder man lässt mal testdisk drüber laufen; testdisk setzt die erste Partition auf der Festplatte nebenbei aktiv.

Große Probleme gibt es regelmäßig wenn man gleich bei der neuen Festplatte eine größere C-Partition einrichten will und ein Image-Tool einsetzt, dass in Partitionen anderer Größe zurückspielen kann. (Naturgemäß gibt es die geringsten Probleme bei exakt gleicher Partitionsgröße und einer Festplatte ähnlicher Größe...Geometrie.)
Das Problem ist ein "ungewöhnlicher Fehler mit INT13H", wenn
1) die entsprechenede Option - soweit vorhanden - im Bios nicht aktiviert wird. WinXP stört es nicht, aber Festplatten-DOS-Tools machen Fehler,
2) man die Größe einer Windows-Partition von kleiner 7,8 GB auf größer 7,8 GB verändert. Solche Größenänderungen sollte man nach dem Rückspielen mit PartitionMagic8 (Version 8!) vornehmen, nicht mit dem Image-Tool.

p.s.: Acronis umschifft obige Probleme (regelt selber die Dinge, laut c't), wenn man eine Festplatte als GANZES klont. Aber bei Einzelpartitionen muss man Bescheid wissen. Ich habe gehört, es gäbe eine Option zum Klonen des MBR (nutze selber nicht Acronis)...eigentlich sollte dann der GUID dabei sein und es sollte funzen. Ich möchte aber nicht die Probleme erleben, wenn die Festplatte eine andere Geometrie hat und der MBR geklont wurde. Oder wenn man - nach vergeblichen Startmühen - schon weiter hinten Datenpartitionen liegen hat und noch mal die C-Partition klont; diesmal dann mit MBR. Naja, mit viel Glück rettet testdisk die Situation.

Sovereign Sylvia Tilo Nachdenklich „Es geht um den Festplatten-GUID bei NTFS-Formatierung. Der GUID wird sowie so...“
Optionen

Hi Tilo,
sehr interessant, war mir so detailiert noch nicht bekannt, wenngleich ich eine ungefähre Ahnung zumindest den MBR betreffend hatte. Die ganzen von dir angesprochenen Fehler treten bei mir nicht auf, weil ich, wie schon gesagt, die Partition mit dem MBR in Ruhe lasse und auch W2K (also nicht Win98) benutze. Bei mir ist nur C: die Primary Partition, alle anderen Drives sind auf der Extended Partition. Natürlich muss beim Zurückkopieren nach meiner Methode die Laufwerks-Treue eingehalten werden, sonst funktioniert auch meine Methode nicht.
Jetzt sag mir noch mal: Was ist das Tool "testdisk" ? Kommt das mit XP mit, oder kann man sich das irgendwo als Freeware herunterladen?

HAND
Sylvia

Tilo Nachdenklich Sovereign Sylvia „Hi Tilo, sehr interessant, war mir so detailiert noch nicht bekannt, wenngleich...“
Optionen

Testdisk dürfte bei Linux-Distributionen dabei sein und es ist traditionell auf Knoppix-CDs dabei (meine Knoppix-CD ist uralt...ich sage das mal ungeprüft); dort lautet der Befehl auf einer Konsole sudo testdisk. Auf den Rettungs-CDs der Zeitschrift c't ist es in einer Windows-Version dabei, es sind Barts PE-Builder CDs. Du findest per Nickles-Suche jede Menge Infos zu testdisk, es ist eines der notwendigsten und genialsten Tools zur Datenrettung...wenn man nicht den MBR mit ped.exe (googeln!) gesichert hatte oder die Sicherung nicht mehr aktuell ist, dann darf man sie nämlich nicht benutzen.

Zitat:
"...die Partition mit dem MBR in Ruhe lasse".
Der MBR befindet sich in der ominösen Spur Null der Festplatte, vor den Partitionen. Manche Leute unterscheiden auch zwischen MBR (eigentlich der Bootcode) und Partitionstabelle, während oft gesagt wird die Partitionstabelle stecke im MBR.

Der c't-Artikel zur GUID-Problematik
(Eigentlich hätte Microsoft sowas ins Handbüchlein zu WinXP reinschreiben sollen!!!)

Witzig auch, dass es das Problem nicht gibt, wenn WinXP auf FAT32 installiert wird (was ich natürlich trotzdem nicht empfehle). Aber Windows auf FAT32 merkt sich auch keine Laufwerksbuchstaben. Es hat natürlich mit der erwünschten Fähigkeit zu tun, sich Laufwerksbuchstaben zu merken...also nicht nur mit dem Aktivierungs-Terror.