Desaster Recovery Probleme schaffen

Aus Xinux Wiki
Version vom 26. August 2026, 11:11 Uhr von Thomas.will (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „= Disaster Recovery: Sabotage-Katalog (Trainerseite) = Diese Seite beschreibt, wie die Fehlerbilder für das Kapitel Disaster Recovery: Rettung in der Not…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Disaster Recovery: Sabotage-Katalog (Trainerseite)

Diese Seite beschreibt, wie die Fehlerbilder für das Kapitel Disaster Recovery: Rettung in der Not erzeugt werden. Die Lösungswege stehen in der Teilnehmerseite.

⛔ Warnung: Alle Kommandos zerstören Daten. Ausschließlich auf den Kurs-VMs ausführen, niemals auf einem produktiven System.

Vorbereitung

Die Kursmaschinen laufen unter VirtualBox. Kommandos mit dem Präfix VBoxManage laufen auf dem Host, alle übrigen in der VM.

Firmware-Modus prüfen – muss BIOS sein, sonst greifen Szenario 1 und 2 nicht
VBoxManage showvminfo it201 | grep -i firmware

Zusatzplatten bereitstellen

Für den Katalog werden vier Zusatzplatten zu je 25 GB benötigt. Sind sie aus den vorherigen Kapiteln bereits vorhanden, entfällt dieser Abschnitt.

Platten anlegen
cd ~/VirtualBox\ VMs/it201
for d in b c d e; do
  VBoxManage createmedium disk --filename sd$d.vdi --size 25600 --format VDI
done
Controller prüfen und Platten anhängen
VBoxManage showvminfo it201 | grep -i "storage controller name"

for i in 1 2 3 4; do
  d=$(echo b c d e | cut -d" " -f$i)
  VBoxManage storageattach it201 --storagectl "SATA" --port $i \
    --device 0 --type hdd --medium sd$d.vdi
done
In der VM kontrollieren
lsblk -d -o NAME,SIZE

Plattenbelegung

  • /dev/sda – Systemplatte, bleibt unangetastet
  • /dev/sdb – Partitionstabelle (Szenario 11)
  • /dev/sdc – LVM Physical Volume (Szenario 10)
  • /dev/sdd – Reserve
  • /dev/sde – ext4-Testdateisystem (Szenario 9)

Snapshots

Snapshot vor jeder Übung anlegen – VM vorher herunterfahren
VBoxManage controlvm it201 acpipowerbutton
VBoxManage snapshot it201 take vor-dr --description "Disaster Recovery"
Vorhandene Snapshots anzeigen
VBoxManage snapshot it201 list
Zurücksetzen nach der Übung – die VM muss ausgeschaltet sein
VBoxManage controlvm it201 poweroff
VBoxManage snapshot it201 restore vor-dr
VBoxManage startvm it201 --type gui
Snapshot nach dem Kurs auflösen, sonst bleibt die Differenzkette bestehen
VBoxManage snapshot it201 delete vor-dr

ℹ️ Hinweis: Solange ein Snapshot existiert, laufen alle Schreibzugriffe in eine Differenzdatei. Vor dem RAID-Abschlusskapitel den Snapshot auflösen, sonst wird der Resync unnötig zäh.

ℹ️ Hinweis: Immutable Disks sind für diesen Zweck ungeeignet: Der Reset erfolgt beim Einschalten, der Schaden wäre nach dem Reboot bereits verschwunden.

Rückweg ohne Snapshot

In der VM ausführen, ermöglicht die Reparatur der Szenarien 1 bis 6 ohne Rollback. 

mkdir -p /root/dr-backup
dd if=/dev/sda of=/root/dr-backup/mbr.bin bs=512 count=1
dd if=/dev/sda of=/root/dr-backup/gap.bin bs=512 skip=1 count=2047
sfdisk -d /dev/sdb > /root/dr-backup/sdb.dump
cp /boot/grub/grub.cfg /root/dr-backup/
Zweiten Kernel installieren – Voraussetzung für Szenario 4
apt list --installed 'linux-image-*'

Ist nur ein Kernel vorhanden, wird Szenario 4 zur Rescue-Übung statt zur Menü-Übung. Für die Menü-Variante muss ein älterer Kernel im GRUB-Menü unter "Advanced options" stehen.

Ebene 1: Bootloader

Szenario 1: Bootsektor (Stage 1) zerstört

Nur die ersten 446 Byte nullen, die Partitionstabelle bleibt erhalten
dd if=/dev/zero of=/dev/sda bs=446 count=1
sync
  • Symptom: "FATAL: No bootable medium found", kein GRUB
  • Rückweg: dd if=/root/dr-backup/mbr.bin of=/dev/sda bs=446 count=1
  • Reparatur im Kurs: Rescue-System, chroot, grub-install /dev/sda

Szenario 2: Post-MBR-Gap (core.img) zerstört

Vorher prüfen, dass die erste Partition bei Sektor 2048 beginnt
fdisk -l /dev/sda | tail -5
Sektor 1 bis 2047 nullen
dd if=/dev/zero of=/dev/sda bs=512 seek=1 count=2047
sync
Kontrolle, dass der GRUB-String verschwunden ist
dd if=/dev/sda bs=512 skip=1 count=4 2>/dev/null | hexdump -C | head
  • Symptom: schwarzer Bildschirm oder wenige Zeichen Müll, kein Prompt
  • Rückweg: dd if=/root/dr-backup/gap.bin of=/dev/sda bs=512 seek=1

Szenario 3: grub.cfg fehlt

mv /boot/grub/grub.cfg /root/dr-backup/grub.cfg.weg
  • Symptom: grub> Vollshell mit Kommandozeile
  • Höchster Lernwert im Katalog, weil die Übergabe Bootloader → Kernel
 von Hand nachgespielt werden muss
  • Rückweg: Datei zurückkopieren

Szenario 3b: GRUB-Verzeichnis versteckt

Erzeugt im Gegensatz zu Szenario 2 einen sauberen Rescue-Prompt
mv /boot/grub /boot/grub.weg
  • Symptom: grub rescue>
  • Lernziel: ls, set root=, insmod normal,
 normal
  • Beide Varianten nacheinander zeigen: core.img kaputt gegen core.img heil,
 aber Konfiguration nicht auffindbar

Ebene 2: Kernel und initramfs

Szenario 4: Kernel gelöscht

mv /boot/vmlinuz-$(uname -r) /root/dr-backup/
  • Symptom: GRUB meldet "file not found" und fällt auf den Prompt zurück
  • Lernziel: der zweite Kerneleintrag unter "Advanced options" rettet die Lage

Szenario 5: initramfs gelöscht

Debian
mv /boot/initrd.img-$(uname -r) /root/dr-backup/
Rocky
mv /boot/initramfs-$(uname -r).img /root/dr-backup/
  • Symptom: Kernel startet, dann Panic
 "VFS: Unable to mount root fs on unknown-block(0,0)"
  • Lernziel: Unterschied update-initramfs gegen dracut

Szenario 6: falsche root-UUID

sed -i 's/root=UUID=[0-9a-f-]\{36\}/root=UUID=00000000-0000-0000-0000-000000000000/g' \
  /boot/grub/grub.cfg
  • Symptom: nach etwa 30 Sekunden BusyBox-Prompt (initramfs)
  • Lernziel: blkid im initramfs, Kernelparameter im GRUB-Menü mit
 e korrigieren, danach dauerhaft reparieren

Ebene 3: frühes Userspace

Szenario 7: Datenplatte hängt den Boot auf

echo "UUID=deadbeef-0000-0000-0000-000000000000 /daten ext4 defaults 0 2" \
  >> /etc/fstab
mkdir -p /daten
  • Symptom: 90 Sekunden Wartezeit, danach emergency.target mit Passwortabfrage
  • Lernziel: journalctl -xb, systemd-fstab-generator, Option
 nofail

Szenario 8: libc entfernt

Debian
rm /lib/x86_64-linux-gnu/libc.so.6
Rocky
rm /lib64/libc.so.6
  • Symptom: kein neuer Prozess startet mehr, bereits laufende Prozesse leben weiter
  • Vorführung: echo test als Bash-Builtin funktioniert noch,
 ls nicht mehr – der Aha-Punkt zu unlink gegen löschen
  • Snapshot zwingend, die VM ist danach nur noch per
 VBoxManage controlvm it201 poweroff zu beenden

Ebene 4: Dateisysteme und Speicher

Szenario 9: ext4-Superblock zerstört

Testdateisystem anlegen und füllen
mkfs.ext4 /dev/sde
mount /dev/sde /mnt
cp -r /etc /mnt/
umount /mnt
Primären Superblock bei Byte-Offset 1024 nullen
dd if=/dev/zero of=/dev/sde bs=1024 seek=1 count=1
sync
  • Symptom: mount scheitert mit "can't read superblock"
  • Hinweis: e2fsck greift oft von selbst auf einen Backup-Superblock
 zurück – das ist selbst ein Lernpunkt. Für den manuellen Weg
 mke2fs -n /dev/sde zeigen und fsck -b 32768 erzwingen

Szenario 10: LVM Physical Volume zerstört

Aufbau
pvcreate /dev/sdc
vgcreate vgtest /dev/sdc
lvcreate -L 5G -n lvtest vgtest
mkfs.ext4 /dev/vgtest/lvtest
UUID vorher notieren
pvs -o pv_name,pv_uuid
LVM-Label und Metadatenanfang überschreiben
dd if=/dev/zero of=/dev/sdc bs=512 count=4
sync
pvscan
  • Symptom: pvs und vgs zeigen die VG nicht mehr
  • Lernziel: LVM legt bei jeder Änderung automatisch ein Archiv unter
 /etc/lvm/archive an – Rettung über pvcreate --uuid ...
 --restorefile ... und vgcfgrestore

Szenario 11: Partitionstabelle gelöscht

dd if=/dev/zero of=/dev/sdb bs=512 count=1
partprobe /dev/sdb
  • Symptom: lsblk zeigt nur noch die nackte Platte ohne Partitionen
  • Zwei Lösungswege gegenüberstellen: testdisk als Rekonstruktion
 gegen sfdisk /dev/sdb < sdb.dump aus der Sicherung
  • Die Botschaft ist der Kontrast: das Spektakuläre gegen das Richtige

Szenario 12: belegter Platz ohne sichtbare Datei

dd if=/dev/zero of=/var/log/gross.log bs=1M count=4000 &
sleep 5
rm /var/log/gross.log
df -h /var
  • Symptom: df meldet den Platz als belegt, du findet nichts
  • Lernziel: lsof +L1, Prozess beenden statt Dateien suchen

Ebene 5: Rocky-spezifisch

Szenario 13: SELinux-Kontexte zerstört

setenforce 1
chcon -R -t var_t /etc/ssh
systemctl restart sshd
  • Symptom: sshd startet nicht, die Journal-Meldungen sind wenig aussagekräftig,
 die Ursache steht nur im Audit-Log
  • Lernziel: ausearch -m avc -ts recent, danach
 restorecon -Rv /etc/ssh
  • Realer Bezug: genau dieses Bild entsteht nach einem Restore mit
 tar ohne --selinux
  • Für den vollständigen Reset: touch /.autorelabel und Reboot

ℹ️ Hinweis: chcon wird hier bewusst als Sabotagewerkzeug eingesetzt. Für die reguläre Kontextvergabe gilt weiterhin semanage fcontext mit anschließendem restorecon.

Blind-Sabotage

Für die Prüfungsvariante würfelt ein Skript eines der Szenarien aus. Die Teilnehmer bekommen nur die defekte VM und eine Zeitvorgabe. 

#!/bin/bash
# /root/kaputt.sh - waehlt zufaellig ein Szenario
N=$((RANDOM % 6 + 1))
echo "$N" > /root/.szenario
case $N in
  1) dd if=/dev/zero of=/dev/sda bs=446 count=1 ;;
  2) mv /boot/grub /boot/.grub.weg ;;
  3) mv /boot/grub/grub.cfg /root/.weg-grub.cfg ;;
  4) mv /boot/vmlinuz-$(uname -r) /root/.weg-vmlinuz ;;
  5) mv /boot/initrd.img-$(uname -r) /root/.weg-initrd ;;
  6) sed -i 's/root=UUID=[0-9a-f-]\{36\}/root=UUID=00000000-0000-0000-0000-000000000000/g' \
       /boot/grub/grub.cfg ;;
esac
sync
systemctl reboot
Die Auflösung erfolgt gemeinsam anhand der Leitfrage
  • Woran war erkennbar, welche Ebene der Bootkette ausgefallen ist?
Abgerufen von „https://xinux.net/index.php?title=Desaster_Recovery_Probleme_schaffen&oldid=73065“