Hmpf. Da zieh ich mir fröhlich 700 MB Knoppix runter, brenn sie und wunder mich, was er beim Drive Imgae erstellen "Gerät ist vll" sagt. Ich war der Meinung, das Thema mit NTFS schreiben wäre inzwischen vom Tisch. Ein echo "tulpe" > schreib mal auf die NTFS-Partition sprach dann aber endlich Klartext.
So weit so schlecht. Captive Treiber soll man sich installieren, die essen aber auch gerne mal NTFS zum Frühstück. Somit nun also meine Frage, was mir aus der Lektüre noch nicht so ganz klar wurde: Zerschiessen sie nur die jeweilige Partition oder zermanschen die gleich mal benachbartes mit und somit die ganze Platte? Weil wenn es nur die Partition ist - berichtigt mich, wenn ich einen Denkfehler mache - wäre es eigentlich egal: Entweder ich bin noch beim Sichern, dann würde nur die Zielpartition kaputtgehen und ich schreibe einfach noch mal neu drauf. Beim Schreiben auf C, wäre C ja scheinbar wegen der Rückspielung eh kaputt und ich wiederhole den Versuch einfach so lange, bis es mal klappt.

Oder mache ich eh noch etwas grundlegend falsch und es geht viel einfacher?

Soweit ich weiß benutzt Captive doch die Microsoft-Binär-Treiber für NTFS? Dann sollte es da eigentlich nichts zu zerschießen geben…
Was du nicht willst, ist der "normale" NTFS-Schreib-Treiber aus dem Kernel.

edit: Es geht um Dateisysteme, es kann also nur die Partition "kaputt" gehen, die du grade in der Mangel hast.

Ah, danke. Na dann probiere ich es mal. In der Hoffnung, dass die Captive Treiber bei Knoppix 3.7 mit rumfliegen. Sonst muss ich vorher immer noch meinen Netzzugang einrichten. Das wäre dann langsam doch recht viel Auffwand, für eine vielleicht monatliche Sicherung. %)

Vollständig sicher nicht, da du die MS-Binaries aus nem Windows ziehen musst…

Wie sichert Knoppix das eigentlich? Mir kam gerade die Idee, dass ich vor dem Rückspielen einfach kurz C in FAT32 formatieren könnte, alles zurückspiele und dann unter Windows die Partition in NTFS zurückkonvertiere. Da fehlt mir ein wenig der durchblick, ob da auch noch Informationen aus dem MBR oder ählichen Dingen (gibts da noch mehr %) gespeichert werden, die dann rummosern, dass das auf NTFS zurückgespielt werden muss. Aber das ist sicherlich etwas, worauf hier zahlreiche Leute eine Antwort wissen, oder? [img]http://www.fb18.de/gfx/23.gif[/img]

Wie waers, wenn Du auf NTFS scheisst, und einfach die komplette Partition 1 zu 1 kopierst? Wenn Deine Sicherungspartition gross genug ist, vorausgesetzt…

dd if=/dev/hdaX of=/dev/hdbY

Hab ich schon mehrfach gemacht, auch mit NTFS, funktioniert wunderbar, braucht eventuell nur ein bisschen… ;)

Mo

Und ist wesentlich schneller als direkter NTFS-Zugriff, de rhats geschwindigkeitsmäßig nicht unbedingt so drauf

Ansonsten gibt es noch partimage, ist bei knoppix dabei und komprimiert dabei auch noch. Was ist denn der Grund für die Aktion, soll ein Windows von einer Platte auf eine neue gespielt werden? Dann ist Image die einzig Sinnvolle möglichkeit wenn das nachher noch booten soll. Es müssen ja nicht nur die Dateien und der Bootsektor kopiert werden, NTFS hat ja noch so ein paar Metadaten, Dateirechte zum Beispiel, die würden ein Kopieren mit Linux nicht so einfach überleben, selbst wenn das NTFS Schreiben läuft.

Partimage ist bei NTFS nicht verlaesslich. Ausprobiert. Verworfen (hat mich Stunden gekostet…)

Mo

Partimage ist bei NTFS nicht verlaesslich. Ausprobiert. Verworfen (hat mich Stunden gekostet…)

Danke für die Info

Mo schrieb:

Partimage ist bei NTFS nicht verlaesslich. Ausprobiert. Verworfen (hat mich Stunden gekostet…)

DU hast partimage bei NTFS probiert? Aber sicherlich nicht auf Deinem Rechner, da dies ja MSWin auf Deinem Rechner erwarten ließ, oder?

Moin, moin.

Wie waers, wenn Du auf NTFS scheisst, und einfach die komplette Partition 1 zu 1 kopierst?

Ganz schlechte Idee. Erst mal möchte ich für meine Systempartition natürlich auch gerne das stabilere, der beiden verfügbaren Dateisysteme und zum anderen kann ich zwar von FAT32 nach NTFS konvertieren, aber nicht umgekehrt.

Wenn Deine Sicherungspartition gross genug ist, vorausgesetzt…
dd if=/dev/hdaX of=/dev/hdbY
Hab ich schon mehrfach gemacht, auch mit NTFS, funktioniert wunderbar, braucht eventuell nur ein bisschen… ;)

Also dd erstellt ein Disc Image? Aber wenn du mit NTFS meinst, wo ist dann das Problem? Also du meinst auch mit NTFS lesen. DD wird ja die gleichen Treiber nutzen und auch immer noch nicht auf NTFS schreiben können?

Ansonsten gibt es noch partimage, ist bei knoppix dabei und komprimiert dabei auch noch.

Ja danke. Damit allein habe ich es bisher auch nur probiert.

Was ist denn der Grund für die Aktion, soll ein Windows von einer Platte auf eine neue gespielt werden?

Es soll ein Backup für den Fall sein, dass die Platte etwa mal hardwareseitig in die Brüche geht.

Dann ist Image die einzig Sinnvolle möglichkeit wenn das nachher noch booten soll

Ja, auf jeden Fall. Das ist auch der einzige Grund, wieso ich mir nicht einfach eine Windows Dateibackup Freeware nehme, wo es dann keine NTFS Probleme gibt. Aber vernünftige Disk Image Freeware gibt es da halt nicht. Und ich brauch auch etwas, dass meine USB-Platte erkennt. Das funktioniert so weit mit Knoppix halt alles sehr schick.

Es müssen ja nicht nur die Dateien und der Bootsektor kopiert werden, NTFS hat ja noch so ein paar Metadaten, Dateirechte zum Beispiel, die würden ein Kopieren mit Linux nicht so einfach überleben, selbst wenn das NTFS Schreiben läuft.

Das heißt, meine Idee, die NTFS Partition als Image auf ein FAT32 Laufwerk zu sichern, die NTFS als FAT32 zu formatieren, dann das Image dort aufzuspielen und zurück nach NTFS zu konvertieren, wird so nicht klappen? Das wäre für mich bis hierhin noch immer das sympathischste.

Was die Dateirechte anbelangt, so hatte ich schon vorher im Netz gelesen, dass man die Komprimierung komplett abschalten soll. Ich nutze ohnehin weder die NTFS Komprimierung, noch die NTFS Verschlüsselung. Von daher könnten meinetwegen die Daten dafür gerne nur einfach nicht da sein, wenn dadurch nichts kaputt geht.

Alles egal. Ich habe heute morgen noch etwas rumprobiert und er kommt sogar nur beim Sichern einer NTFS Partition auf ein FAT32 Laufwerk mit dem wenig vertrauenswürdigen Hinweis, dass sich die Geschichte noch in einem sehr frühen Stadium befindet. Bei nem Browser oder Spiel okay. Aber bei Backups ist mir das dann doch nicht so ganz geheuer. Jetzt habe ich mir für 35 Euro Arconis True Image 8 gekauft. Da kann ich die Images auch im laufenden Betrieb im Hintergrund fahren. (womit ich die dann vielleicht auch häufiger als einmal im Jahr mache [img]http://www.fb18.de/gfx/22.gif[/img]). Außerdem wird das Programm bei Zeiten meine alte 80GB Platte mal schick auf eine neue, größere [strike]S[/strike]ATA Platte transferieren können. Sehr bequem alles.

Hm, mit Acronis TrueImage habe ich mir vor 1-2 Jahren etliche ext3- und NTFS-Partitionen komplett beim Wiederaufspielen komplett zerstört. Solltest Du vielleicht vorher testen [img]http://www.fb18.de/gfx/17.gif[/img]
Ansonsten hätte ich jetzt empfohlen, eine ältere DriveImage Version zu kaufen. Die gibts für ein paar € in PC-Zeitschriften oder im Software-Versand und lässz sich gut per Boot-CD verwenden (für WinXP-NTFS reicht DriveImage 5).

Hmm. Welche Version hast du denn benutzt? Ich habe mich nur über 6, 7 und 8 informiert und sehr gutes gelesen. Bestellt habe ich mir die 8. Negatives habe ich eher bei DriveImage und Ghost gelesen. Insbesondere bei DriveImage, dass man sich wieder mal Net installieren muss.

Wozu ein zusätzliches programm nun nötig war verstehe ich immernoch nicht, ein image einer jedweden Platte kann man wunderbar mit dd ziehen, mit captive-ntfs sogar auf ntfs wieder unterbringen und Platte->Platte-Transfers sind auch kein Problem

Wenn Deine Sicherungspartition gross genug ist, vorausgesetzt…
dd if=/dev/hdaX of=/dev/hdbY
Hab ich schon mehrfach gemacht, auch mit NTFS, funktioniert wunderbar, braucht eventuell nur ein bisschen… ;)

Also dd erstellt ein Disc Image? Aber wenn du mit NTFS meinst, wo ist dann das Problem? Also du meinst auch mit NTFS lesen. DD wird ja die gleichen Treiber nutzen und auch immer noch nicht auf NTFS schreiben können?

Das Problem war glaub ich, dass Björn annahm, dd würde einen Dateisystemtreiber brauchen. Dem ist aber beo obigen Beispiel nicht so.

Yip. Ich hatte das so verstanden, dass ich mir dann noch extra Treiber runterladen/installieren müsste und es damit nur um ein "experimentelles" schreiben erweitert würde. Na ja und das ganze dann von Windows aus im Hintergrund bei laufenden Betrieb machen zu können und die schicke Plattenportierungsfunktion (mir ist schon klar, dass es auch per Hand geht), finde ichs schon ganz schick. Auch wusste Partimage so weit ich das gesehen habe, nichts von inkrementelle Backups. TrueImage schmeisst zudem noch automatisch die Auslagerungsdatei raus. Das GB ist auch nicht zu verachten.

Okay, inkrementelle Backups werden das auch mit dd nicht, das ist immerhin ein Punkt

Ja und noch ein Punkt, dass es von Windows aus im Hintergrund läuft. Und vermutlich auch spürbar schneller. Jedenfalls war der Datendurchsatz mit ~22 MB pro Minute heute bei PartImage dann doch nicht so erquicknd. [img]http://www.fb18.de/gfx/15.gif[/img]

Aber nun redet mal Klartext: Mit dd ohne alles, hätte ich problemlos auf NTFS sichern und auch wieder zurückschreiben können und das alles von der Knoppix 3.7 CD aus. Ohne wenn und aber?

Nicht von Linux aus auf eine NTFS-Partition aber entweder als eine Imagedatei auf jedes unter Linux erreichbare Dateisystem oder direkt auf eine andere Partition (ohne Dateisystem, sozusagen ein Raid-Mirror per Hand [img]http://www.fb18.de/gfx/24.gif[/img])

dd kopiert nicht Datei für Datei, sondern kopiert die gesammte Partition in eine Imagedatei. Du hättest also deine USB-Platte immernoch FAT formatieren müssen, und dann mit dd ein komplettes Image der NFTS-Partition dort rüber kopieren.

Nicht von Linux aus auf eine NTFS-Partition aber entweder als eine Imagedatei auf jedes unter Linux erreichbare Dateisystem oder direkt auf eine andere Partition (ohne Dateisystem, sozusagen ein Raid-Mirror per Hand

Das war ja wieder meine Frage, wie weit das heil bleibt, wenn ich das NTFS Image dann auf eine FAT32 Partition zurückspiele und die konvertiere. Obwohl ich mir zu dem Zeitpunkt auch noch keine Gedanken darüber gemacht hatte, wie ich das konvertiere, wenn der unter FAT32 dann vielleicht auch nicht mehr booten will. Also bis zu diesem Zeitpunkt scheinen mir die 35 Euro noch ganz gut investiert zu sein. [img]http://www.fb18.de/gfx/23.gif[/img]

dd kopiert nicht Datei für Datei, sondern kopiert die gesammte Partition in eine Imagedatei. Du hättest also deine USB-Platte immernoch FAT formatieren müssen, und dann mit dd ein komplettes Image der NFTS-Partition dort rüber kopieren.

Das wäre ja kein Ding gewesen. Aber mir gehts ja weniger um das Image, als um dann das erfolgreiche Rückspielen des Images. Bis zu dem Punkt war ich heute morgen ja schon gekommen.

Stell Dir folgendes vor Bjoern:

Du hast eine Postgresql Datenbank. Diese Datenbank moechtest Du in einer MySQL Datenbank backuppen. Du kannst entweder alle Tabellen auseinandernehmen, und in die MySQL einfuegen; und um das Backup zurueckzuspielen /wieder/ alles auseinanderfummeln und wieder in die Postgresql einfuegen, oder:

Du nimmst die Datei, auf die der postgresql-Server schreibt, und fuegst die als /ein Datenelement/ in die MySQL ein. Um zurueckzuspielen, muesstest Du also bloss die Datei da wieder rauswuehlen.

dd macht nun das entsprechende. Partitionen sind einfach nur grosse Dateien mit einer festen Groesse. /In/ diesen Dateien ist eine bestimmte (und im Falle von NTFS nicht vollstaendig verstandene) Struktur. Diese Struktur ist das Dateisystem. Wir koennen jetzt versuchen, diese Struktur auseinanderzubasteln, und auf diese Weise die Dateien rauszuholen; oder wir kuemmern uns nicht drum, und nehmen einfach alle Daten und die Struktur gleich mit. 1 zu 1. Wie bei einem CD-Image.

Allerdings faellt mir hier grade ein Problem auf: Wenn Du die Partition als Datei auf Dein FAT-System schreiben willst, dann musst Du das Groessenlimit auf FAT beachten, was AFAIK bei 2 Gigs liegt, und fuer Partitionen nicht wirklich viel ist :/

Mo

Tja. Hmm. Hätte ich einen Zweitrechner, hätte ich ees ja zum Spaß einfach mal ausprobiert. Schade, aber egal. FAT32 wurde übrigens gerade für über 2 GB auf den Tisch geworfen.

FAT32 wurde übrigens gerade für über 2 GB auf den Tisch geworfen.

Ja, für Partitionsgrössen über 2GiB. Dann gibts aber noch die maximale Dateigrösse von 4GiB…

Tja. Hmm. Hätte ich einen Zweitrechner

Haeh? Wozu brauchst Du den denn? Du kannst sogar testen, ob das Image in Ordnung ist, ohne es zurueckzuspielen…

dd if=/dev/hdaX of=/mnt/<windowsfat>/<imagedatei>
mount -t ntfs -o loop /mnt/<windowsfat>/imagedatei /mnt/test

Dann sollte unter /mnt/test das Dateisystem, dass Du gebackupped hast erscheinen.

Dafuer solltest Du das Knoppix allerdings mit nem 2.6er Kernel booten (wegen ntfs support), und zwar folgendermassen:

Beim Bootprompt einfach nicht Enter druecken, sondern "knoppix26" eintippen.

Mo

Edit: mount-Befehl korrigiert.

Apropos Acronis: Was mich bei dem Programm schon immer
gewundert hat, ist, ob und wie die sicherstellen, dass
die Dateien auf dem Dateisystem noch zueinander passen.
Wenn man z.B. während des Backups zwei Dateien ändert,
(und eine von der anderen abhängt) wobei eine davon schon
gesichert ist. Dann hat man doch im Backup von der einen
Datei die alte Version und von der anderen die neue.
Und nach dem Zurückspielen hat man ein kaputtes System.

Oder merkt das Programm beim Backup, dass sich was ändert?
Aber dann muss es doch eine Beschränkung dieses Gedächtnisses
geben (spätestens der RAM)? Und außerdem kann es doch zu
Endlosschleifen kommen (wenn man "Hase und Igel"-mäßig
immer eine Datei ändert, an der Acronis gerade nicht dran
ist)?

Ich dachte bisher immer, Backups sollten atomar verlaufen.

Ist Acronis gefährlich oder haben die sich was wahnsinnig
schlaues ausgedacht? Weiss da jemand mehr?

Naja, man kann mit dd das Image ja auch per blocksize und count auf mehrere 4 GB-Dateien splitten. Wär also mit nem kleinen Script kein Problem gewesen…

@Georg, also wenn ich so ein Backup Programm wäre, dann würde ich nach dem Schreiben noch mal das Image kontrollieren, ob das mit den jetzigen Dateien übereinstimmt. Dafür braucht er ja nur die FAT durchgucken. Wenn sich noch was geändert hat, schmeißt er einfach die Sachen hinterher. Noch mal prüfen… Irgendwann wird der User schon klein beigeben und nichts mehr auf dem Laufwerk manipulieren. [img]http://www.fb18.de/gfx/23.gif[/img]

@Georg, also wenn ich so ein Backup Programm wäre, dann würde ich nach dem Schreiben noch mal das Image kontrollieren, ob das mit den jetzigen Dateien übereinstimmt. Dafür braucht er ja nur die FAT durchgucken. Wenn sich noch was geändert hat, schmeißt er einfach die Sachen hinterher. Noch mal prüfen… Irgendwann wird der User schon klein beigeben und nichts mehr auf dem Laufwerk manipulieren. [img]http://www.fb18.de/gfx/23.gif[/img]

OK, unter der Annahme, dass die Lebenszeit des Anwenders
endlich ist, lassen sich Endlosschleifen damit erfolgreich
ausschlie"sen [img]http://www.fb18.de/gfx/10.gif[/img]

Aber was ist mit Log-Dateien, die ändern sich doch jedes Mal?
<EDIT>Oder gar Swap-Dateien? [img]http://www.fb18.de/gfx/3.gif[/img]</EDIT>

OK, unter der Annahme, dass die Lebenszeit des Anwenders
endlich ist, lassen sich Endlosschleifen damit erfolgreich
ausschlie"sen [img]http://www.fb18.de/gfx/10.gif[/img]

Läuft windows überhaupt solange durch, oder darf man dann backups nur ab einem bestimmten alter durchführen? ala "Achtung! Um diese Software benutzen zu dürfen müssen sie min. 90 Jahre alt sein, sonst können wir die korrekte Funktionweise der Software nicht gewährleisten."

dd if=/dev/hdaX of=/mnt/<windowsfat>/<imagedatei>
mount -t ntfs -o loop /mnt/<windowsfat>/imagedatei /mnt/test

Warum denn überhaupt erst eine FAT-Partition und eine Imagedatei anlegen ?
Wenn das Image ohnehin auf eine andere Platte soll, kann es doch auch direkt auf eine Partition geschrieben werden. Natürlich muß man dann als zusätzlichen Schritt die Partitionstabelle der Zielplatte anpassen. Dafür könnte man im Notfall evtl. sogar nur die Platten tauschen.

Und noch was zum Acronis TrueImage:
Ich glaube ich hatte damals die Version 6.0. Da ich sowas immer von Boot-CD starte, weiß ich nicht wie das mit der Daten-Konsistenz unter Windows aussieht. Die alte Version war aber im wesentlichen ein cdrecord, das per PTS-BootManager in ein PTS-Dos eingebunden war (inkl. aller damit verbundenen Bootprobleme). Wenn sich die Versionen nicht grundsätzlich unterscheiden glaube ich daher nicht, dass dabei auf konsistente Daten geachtet wird.

Lalala. Also das Programm funktioniert eigentlich wie am Schnürrchen. Gerade eben mein C-Laufwerk neu aufgespielt. Was jetzt aber etwas uncool ist (zum Thema, wie merkt das Programm eigentlich wenn Daten noch geöffnet sind), dass mein Miranda Profil fehlt. Den Miranda lief gerade… *gna* Na ja. Wenn man das weiß, ist es wirklich eine sehr feine Sache.