Mit Images spielen
Ein Image erstellen geht ziemlich schnell. Zum Beispiel mit dd:
dd if=PARTITION of=DATEI
Überlegen sollte man hier, ob man nicht noch mit bs die Blockgröße festlegt, da dadurch das Erstellen unter Umständen beschleunigt werden kann. Kopiert wird solange, bis die Partition nichts mehr hergibt. Mit der option conv=noerror bewegt man dd dazu, bei einem Fehler weiter zu machen. Wobei man bei so etwas lieber auf dd_rescue zurückgreift.
Man kann auch selbst ein Leeres erzeugen
dd if=/dev/zero of=DATEI bs=BLOCKGROESSE count=ANZAHLDERBLOCKS
und dann ein Dateisystem anlegen
mke2fs -j DATEI
Ein Nachteil ist, dass das alles mehr Platz wegnimmt als nötig. Hier könnte man auf die Fähigkeit der meisten Dateisysteme zurückgreifen, eine sogenannte Sparse-Datei anzulegen. Diese Datei nimmt dann nur soviel Platz in Anspruch, wie auch wirklich belegt ist.
dd if=/dev/zero of=sparsefile count=0 bs=1G seek=1
Hier wird eine 1GB-Datei angelegt, die zwar mit dieser Größe auch angezeigt wird, allerdings auf der Platte nur ein paar Bytes belegt.
Der Nachteil einer Sparse-Datei ist, dass diese ziemlich Fragmentieren kann und das diese unter Umständen die Datensicherung durcheinander bringt, falls die Datensicherung nicht in der Lage ist, mit Sparse-Dateien umzugehen. Bei Tar, Rsync und anderen gibt es dafür übrigens extra eine Option, damit diese damit umgehen können.
Diese Dateien kann man natürlich auch praktischerweise ganz normal ins System einhängen
mount -o loop DATEI VERZEICHNIS
und damit dann normal arbeiten.
Wenn man so ein Image komprimieren will - am Besten mit bzip2 oder rzip - komprimiert man unter Umständen unbenutzte Daten im Dateisystem mit. Diese sollte man am Besten ausnullen. Datei also wieder einhängen, ins Verzeichnis wechseln und eine große Datei mit Nullen erzeugen
mount -o DATEI VERZEICHNIS
cd VERZEICHNIS
dd if=/dev/zero of=NULLDATEI
Sobald das Image voll ist, meckert das System. Dann einfach
rm NULLDATEI
cd ..
umount VERZEICHNIS
machen und die Datei komprimieren.
Aber vielleicht will man auch nur, dass das Image nach dem Ausnullen weniger Platz wegnimmt im Dateisystem. Leider kenne ich nur die Möglichkeit, die Datei umzukopieren und beim Kopieren zu sagen, die Null-Bereiche wieder als Sparse zu behandeln
cp --sparse=always DATEI DATEINEU
rm DATEI
mv DATEINEU DATEI
Eine Möglichkeit bei einer Datei nachträglich Nullen in Sparse-Bereiche umwandeln zu lassen, wäre natürlich praktischer.
Am 4. Juni 2008 um 16:24 Uhr
Hallo,
also ich mache Images noch schneller und einfacher. Ganz einfach
cat imagedatei > /dev/sda1
oder
cat /dev/sda1 > imagedatei
um eine Imagedatei von bzw. auf die 1. Partition von /dev/sda zu spielen.
Das ist für mich die schnellst mögliche Variante. Wenn man die Imagedateien noch komprimiert, dann kann man sie sogar relativ schnell übers Netzwerk transportieren.
Z. B.
gzip -cd imagedatei.gz > /dev/sda1
Optimiert kann die Imagedatei noch werden, indem man die Festplatte vor der Imageerstellung noch mit einer riesigen (so groß wie möglichen) Datei mit lauter Null-Byte Zeichen füllt. Z. B.
cat /dev/zero > /gemountetes_Image/test.null
Nachdem diese Datei geschrieben ist, kann man sie wieder löschen. Dann kann wird das Image nach dem Komprimieren nochmal kleiner.
Viel Spaß beim Testen.
Grüße
Thomas
Am 4. Juni 2008 um 16:42 Uhr
Klar, cat geht heutzutage auch. Ist allerdings nicht besonders flexibel für Images.
Ob cat wirklich schneller ist, bezweifel ich, da es Zeichen und nicht Block orientiert ist. Zu dem kann ich mit dd die Blockgröße tunen, was auf mancher Hardware Wunder bewirkt.
Am 5. Juni 2008 um 07:26 Uhr
Für mich ist aber auch die Flexibilität wichtig, da ich die Windowsimages auf relativ verschiedener Hardware wieder einspielen muß. Da habe ich nicht Lust und Zeit das für jede Hardware speziell zu tunen.
Zudem ist für mich die Fehleranfälligkeit bei dd höher (wie schnell hat man if und of mal vertauscht) - da ist cat übersichtlicher.
Oder wo siehst du die größere Flexibilität bei dd? Um den MBR schnell zu sichern und wieder einzuspielen ist es ganz sicher genial…
Am 5. Juni 2008 um 12:29 Uhr
Tunen muss man nicht viel. Ich nehme meistens von Anfang an eine große Blockgröße zum Kopieren. Besonders bei älteren Rechnern bringt das immer was. Man muss nicht tunen. Geht auch so. Aber man kann, verglichen mit cat.
if und of vertauschen? Fällt mir schwer, da die Parameter von den englischen Begriffen abgeleitet sind und ich auf der Kommandozeile sowieso in englisch denke.
Zum Thema Flexibilität will ich jetzt eigentlich nicht die Handbuch-Seiten durchkauen. Cat ist wie gesagt zeichenorientiert und ursprünglich für Text gedacht. Als ich angefangen habe, bin ich noch ab und zu über Systeme mit cat gestolpert, die konnten gar nicht richtig mit Binärdaten umgehen. Deswegen habe ich mir dd erst gar nicht angewöhnt.
DD habe ich mittlerweile für alle Schandtaten in Bezug auf Images benutzt. Ich kann einzelnen Partitionen aus Images herauskopieren, neu zusammen bauen etc. Die Fähigkeit Sparse-Dateien anzulegen benutzte ich auch öfters. DD kann mir anzeigen, wie viele Blöcke schon kopiert wurden. Das kann cat nicht. Cat kann nur etwas aus einer Datei auf die Standardausgabe schieben. Und wenn man will, die Zeilen entsprechend markieren. Das ist für meine Bedürfnisse in Bezug auf Images ziemlich wenig. Da ich mit dd auch auf die Standardausgabe ausgeben kann, bleibt für cat nur noch der Pluspunkt, dass man drei Zeichen weniger tippen muss:
echo “cat /dev/sda1 > imagedatei” | wc -c
27
echo “dd if=/dev/sda1 of=imagedatei” | wc -c
30
Und das fällt bei meinen zehn Finger nicht ins Gewicht.