Extrem wichtig und sinnvoll - die "default" Sicherung der DOM-0
Für unseren zukünftigen XEN Server hatte ich bei der Bestellung die 64 Bit Version opensuse 13.2 angeben. Und diese Version installieren die Supporter bei der Erst-Einrichtung auch auf der (den) Server-Festplatte(n).
Daß die anfänglich erfolgte Aufteilung der Partitionen der Festplatte noch nicht professionellen Virtualisierungs-Vorgaben entspricht, ist unsere Erfahrung. Es ist eben eine Default-Installation "from scratch", wie die Amerikaner sagen.
Und - ganz wichtig für die Zukunft - die Default-Installation funktioniert. Sie sollten dazu ganz am Anfang schon mal "spionieren" gehen, was die dort als funktionierendes opensuse 13.2 Minimal-System installiert haben.
.
Auf bittere Versäumnisse achten - die UUIDs der Platten
Natürlich mache auch ich Fehler, obwohl ich es aus bitterer Erfahrung seit mehreren Jahren wußte (hätte wissen müssen). Das betrifft diese Platten-UUIDs der Partitionen auf der Festplatte, auch auf gespiegelten Festplatten. Diese UUIDs sind bei einer Rücksicherung oder bei einem Umzug äußerst fatal, denn nichts geht mehr. Und das Austauschen solcher Rattenschwänze von langen Zahlenkolonnen ist selbst mit "Drag and Drop" sehr fehlerträchtg und dazu mühsam und zeitaufwendig.
In der Datei "/etc/default/grub" müssen !!
(1) ein vorhandener Eintrag aktiviert und
(2) ein neuer Eintrag hinzugefügt werden,
damit beim nächsten Abspeichern des Bootloades per YAST2 aus den eigentlichen boot Dateien diese UUIDs verschwinden.
- GRUB_DISABLE_LINUX_UUID=true
- GRUB_ENABLE_LINUX_LABEL=true
Komisch ist dabei nur, daß in der /boot/grub/grub.cfg die UUIDs jetzt weg sind und dafür in der /etc/fstab auf einmal welche auftauchen. Auch daran denkt man nicht gleich. Das muß man auch wieder korrigieren, indem man die fstab vorher sichert und nach jeder Änderung bzw. Sicherung nochmal überprüft.
.
Ergänzungen auf der opensuse Default-Installation
Ein paar kleine Arbeits-Tools habe ich mir schon geholt, aber nur den mc und htop und den joe. so zeigt "df -h" die Füllmenge der Partitionen an, es ist nicht viel.
.
Vorbereitung der Sicherung :
(1) Zuerst herausfinden, wie die 3 Plattenpartitionen "zur Zeit" heißen. Die temporären Namen werden zur Boot-Zeit zufällig erzeugt und sind jedesmal anders. Das ist eben so.
less fstab
# /etc/fstab - static file system information
/dev/md0 /media/md0 swap defaults 0 0 # /dev/md0
/dev/md1 /media/md1 ext4 noauto,user,dev,suid,exec 0 0 # /dev/md1
/dev/md2 /media/md2 ext4 noauto,user,dev,suid,exec 0 0 # /dev/md2
und damit lautet der erste Befehl zum Mounten der 2. Partition (/boot/) :
mount /dev/md1 /mnt
.
Die Sicherung
Das Kommando zur Sicherung der 2. (boot-)Partition (/boot/) ist demnach dieses :
tar cfvz /tmp/2017-01-07-suse13-1-boot-partition.tar.gz /mnt/
und als Nächstes lautet der Befehl zum Mounten der 3. (root-)Partition (/) :
mount /dev/md2 /mnt
und das zugehörige Kommando zur Sicherung ist :
tar cfvz /tmp/2017-01-07-suse13-1-root-partition.tar.gz /mnt/
fast fertig.
und nur mal zur Kontrolle - als Beispiel:
tar cfvz /tmp/2017-01-07-suse13-1-root-partition.tar.gz /mnt/ 46,86s user 2,17s system 46% cpu 1:44,42 total
Auf meinem lokalen NAS im Büro in Wiesbaden sehen die per "winscp" abgeholten beiden Archiv-Dateien danach so aus:
2017-01-07-suse13-1-boot-partition.tar.gz 22,6 MB (23.777.090 Bytes)
2017-01-07-suse13-1-root-partition.tar.gz 442 MB (464.409.149 Bytes)
und das ist wirklich nicht viel.
.
Mit diesen beiden Dateien kann ich jetzt ohne weitere Hilfe den Server immer wieder reparieren - dachte ich.
Ich kann natürlich - in das Original - rein schaun, um mir die wichtige statische Netzwerk Konfiguration anzuschaun und zu vergleichen.
Die Rücksicherung hatte wegen der unteschiedlichen UUIDs nicht funktioniert. Das hat das Konzept einen Denkfehler. Es muß ohne diese UUIDs gesichert werden.
.
Wichtig bei diesen Versuchen - KEIN "shutdown now" absetzen
Damit wird dieser MSI Mainboard basierende Server physikalisch ausgeschaltet - und geht damit per Fernseelsorge nicht mehr an. Es ist eben "nur" ein PC-Mainboard und kein spezielles Server-Mainboard.
.
Das alles reicht aber nicht, ein Musterserver muss her.
Für die XEN Installation, die auf allen unseren Server problemlos mit (bei uns) bis zu 10 Virtuellen Maschinen läuft, muß der Server anders aufgesetzt werden, am besten auf eine gleiche Hardware bei uns im Haus, die dann mit dem GRML Rescue-System auf den Zielserver übertragen wird.
Und dabei sind eine Menge Kleinigkeiten zu beachten. Insbesondere die UUIDs müssen auch korrigiert werden.
.