Willkommen bei WCM
Um alle Funktionen dieser Website nutzen zu können müssen Sie sich Einloggen oder Registrieren. Die Registrierung ist unverbindlich und dauert nur einen Moment.
Tipps & Tricks
Veröffentlicht am 27.11.2004 09:46:24
Um eine Linux-Maschine komplett zu sichern, kann man entsprechende Maßnahmen treffen. Doch neben dem traditionellen Backup mit tar gibt es auch mehrere innovative Methoden, Abbilder von Systemen mit Linux-Bordmitteln zu erstellen und auf andere Systeme „draufzugeben“. Hierzu dient das Tool „Device Dump“, kurz dd. Von der Kommandozeile startet man mit „dd“ und kann einfach Daten von einem File in ein anderes kopieren. Diese Funktion ist unter Unix ausreichend, um eine Rohkopie eines Dateisystems zu erstellen, die nachher wieder benutzt werden kann. Mit dd „if=/dev/hda5 of=/tmp/file“ zum Beispiel erstellt man eine komplette Kopie der Partition HDA5 (erste sekundäre Partition der primären Harddisk des ersten Controllers am IDE Bus). Besser aber in diesem Fall wäre, die Disk mit dd 1:1 zu duplizieren. Mit „dd if=/dev/hda of=/dev/hdb count=25M bs=1k“ kopiert man auch schon 25 GByte von der ersten auf die zweite IDE-Platte. 25 Millionen Blocks a 1 KByte sind die 25Gbyte, die kopiert werden. Mit diesem Befehl werden auch die Partitionstabelle und alle Partitionen mitkopiert.
Man kann unter Linux mit Files ebenso problemlos umgehen wie mit Partitionen oder Platten. Alle Befehle, vom Erstellen eines Dateisystems, Resizen und Mounten, sind mit einem File als „Device“ ebenso machbar wie mit /dev/hdX als Plattensystem.
Lediglich beim Mounten muss mit „-oloop“ angegeben werden, dass via Loopback Device gemountet werden soll. Durch diese Features kann man seine Rettungssysteme auch testen, anlegen und verwalten, bevor man sie auf große Platten einspielt. Wir erzeugen zur Probe ein File mit dd, um danach ein Filesystem anzulegen. Mit „dd if=/dev/zero of=./testfile bs=1M count=20“ erzeugen wir ein 20 MByte großes File voller Nuller — kopiert von /dev/zero. Danach legen wir mit mkfs.ext2 ein Dateisystem in dieser Datei an. Das Filesystem wird von Haus aus die maximale Größe belegen. Aufgrund des beschränkten Platzes wählen wir ext2; auch ext3 wäre möglich gewesen.
Um nun zu testen, ob wir auch resizen können, Schrumpfen wir das Filesystem von 20480 Blocks auf 10000 Blocks: „/sbin/resize2fs ../testfile 10000“. Danach ist das Dateisystem nur mehr halb so groß; die letzten 10M der Datei könnte man auch wegschneiden. Um in Files „herum zu schneiden“, dient auch dd als Werkzeug. Wir erzeugen eine neue Kopie, in der wir nur die ersten 10M kopieren: „dd if=testfile of=testfile10M bs=1M count=10“. Das erzeugte File prüfen wir noch auf Fehler („/sbin/e2fsck ../testfile10M“), wobei uns e2fsck ein fehlerfreies Dateisystem in einem File bescheinigt („testfile10M: clean, 11/3424 files, 450/10000 blocks“). Man kann somit Dateisysteme problemlos vergrößern, verkleinern, und auch die Devices, egal ob Partitionen oder Files, mitziehen. Wir können somit ein „frisch“ installiertes, kleines Linux sichern.
Zuerst installieren wir auf einer 5MB Partition einen kleinen Firewall-Server, oder auch einen Fileserver ohne Nutzdaten. Danach holen wir uns mit dd das ganze Filesystem in ein File, wobei wir es vorher Read-Only gemountet haben. Danach kann das File mit GZip komprimiert und abgelegt werden. Um es zu verwenden, muss es nur mehr mit dd auf eine frische Festplatte kopiert werden, wobei gegebenenfalls auch wieder dekomprimiert werden muss.
Um nun einen frischen Server einspielen zu können, bootet man diesen von Diskette oder CD. Danach wird die Platte partitioniert, wobei die Partitionen größer oder gleich groß wie das Image sein sollten. Danach wird mit dd das Image auf die Zielpartition eingespielt. Ist das Image auf der Zielmaschine angelangt, sollte man es zuerst Resizen und danach mit einem fsck prüfen. Eventuell möchte das resize-Programm zuerst eine Prüfung durchgeführt haben, dann lieber nochmal prüfen — unnötig Prüfen ist besser als einmal zu wenig und von vorne anfangen! Nach dem Einspielen des Images ist nur mehr ein Mounten als Root notwendig, um Lilo richtig starten zu können. Davor sollte man aber die /etc/lilo.conf entsprechend anpassen, falls die Devices anders gelagert sind als auf der Maschine, mit der das Image erstellt wurde. Lilo bietet hier die Option „-r“ an, um realtiv zu einem anderen Verzeichnis arbeiten zu können. Hat man das Zielsystem beispielsweise unter /mnt/target gemountet (wie z.B. bei Debian Boot-Floppies üblich) so kann mit „lilo -r /mnt/target“ direkt der Lilo mit der /etc/lilo.conf aus dem Zielsystem gestartet und der Bootsektor entsprechend geschrieben werden. Nach dem Lilo-Lauf sollte bereits ein Booten von der Platte möglich sein, da der Lilo den Bootsektor richtig schreibt, und das Kernelfile aus dem Image vom Bootsektor aus richtig referenziert. Voraussetzung dafür, ist das richtige Einstellen der Zielplatte im Zielsystem: Als Bootdevice im Bios und im IDE-System. Vergleicht man den Aufwand mit einer manuellen Installation, wird man dd nicht mehr missen wollen!
Peter-Paul Witta
« Texte automatisch kürzen · System-Imaging mit Linux
· WCM Umfrage »
Kommentar
|
reini123 Beiträge: 26 Registriert: 2007-03-06 |
#1949 Veröffentlicht am: 10.03.2007 16:22:05
Guter Artikel ;-) der vollständigkeit halber könnte man noch erwähnen ..... dd kann man jedoch für wesentlich mehr als für backups verwenden ;-) Beispiele wären etwa, Für zusammenführung gesplitteter Dateien zB. `for a in `ls test*`;do dd if=./"$a" >> test.out;done` oder für einen kurzen Blick ins BIOS per zB. `sudo dd if=/dev/mem bs=1k skip=768 count=256 2>/dev/null|strings -n8` und etliches ähnliches ..der Phantasie sind hier keine Grenzen gesetzt. Mfg Reini |