Thomas.will: 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…“

2026-08-26T11:11:28Z

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…“

Neue Seite

= 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
<code>VBoxManage</code> laufen auf dem Host, alle übrigen in der VM.

;Firmware-Modus prüfen – muss BIOS sein, sonst greifen Szenario 1 und 2 nicht
<syntaxhighlight lang="bash">
VBoxManage showvminfo it201 | grep -i firmware
</syntaxhighlight>

=== 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
<syntaxhighlight lang="bash">
cd ~/VirtualBox\ VMs/it201
for d in b c d e; do
VBoxManage createmedium disk --filename sd$d.vdi --size 25600 --format VDI
done
</syntaxhighlight>

;Controller prüfen und Platten anhängen
<syntaxhighlight lang="bash">
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
</syntaxhighlight>

;In der VM kontrollieren
<syntaxhighlight lang="bash">
lsblk -d -o NAME,SIZE
</syntaxhighlight>

=== Plattenbelegung ===

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

=== Snapshots ===

;Snapshot vor jeder Übung anlegen – VM vorher herunterfahren
<syntaxhighlight lang="bash">
VBoxManage controlvm it201 acpipowerbutton
VBoxManage snapshot it201 take vor-dr --description "Disaster Recovery"
</syntaxhighlight>

;Vorhandene Snapshots anzeigen
<syntaxhighlight lang="bash">
VBoxManage snapshot it201 list
</syntaxhighlight>

;Zurücksetzen nach der Übung – die VM muss ausgeschaltet sein
<syntaxhighlight lang="bash">
VBoxManage controlvm it201 poweroff
VBoxManage snapshot it201 restore vor-dr
VBoxManage startvm it201 --type gui
</syntaxhighlight>

;Snapshot nach dem Kurs auflösen, sonst bleibt die Differenzkette bestehen
<syntaxhighlight lang="bash">
VBoxManage snapshot it201 delete vor-dr
</syntaxhighlight>

{{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.

<syntaxhighlight lang="bash">
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/
</syntaxhighlight>

;Zweiten Kernel installieren – Voraussetzung für Szenario 4
<syntaxhighlight lang="bash">
apt list --installed 'linux-image-*'
</syntaxhighlight>

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
<syntaxhighlight lang="bash">
dd if=/dev/zero of=/dev/sda bs=446 count=1
sync
</syntaxhighlight>

* Symptom: "FATAL: No bootable medium found", kein GRUB
* Rückweg: <code>dd if=/root/dr-backup/mbr.bin of=/dev/sda bs=446 count=1</code>
* Reparatur im Kurs: Rescue-System, chroot, <code>grub-install /dev/sda</code>

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

;Vorher prüfen, dass die erste Partition bei Sektor 2048 beginnt
<syntaxhighlight lang="bash">
fdisk -l /dev/sda | tail -5
</syntaxhighlight>

;Sektor 1 bis 2047 nullen
<syntaxhighlight lang="bash">
dd if=/dev/zero of=/dev/sda bs=512 seek=1 count=2047
sync
</syntaxhighlight>

;Kontrolle, dass der GRUB-String verschwunden ist
<syntaxhighlight lang="bash">
dd if=/dev/sda bs=512 skip=1 count=4 2>/dev/null | hexdump -C | head
</syntaxhighlight>

* Symptom: schwarzer Bildschirm oder wenige Zeichen Müll, kein Prompt
* Rückweg: <code>dd if=/root/dr-backup/gap.bin of=/dev/sda bs=512 seek=1</code>

=== Szenario 3: grub.cfg fehlt ===

<syntaxhighlight lang="bash">
mv /boot/grub/grub.cfg /root/dr-backup/grub.cfg.weg
</syntaxhighlight>

* Symptom: <code>grub></code> 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
<syntaxhighlight lang="bash">
mv /boot/grub /boot/grub.weg
</syntaxhighlight>

* Symptom: <code>grub rescue></code>
* Lernziel: <code>ls</code>, <code>set root=</code>, <code>insmod normal</code>,
<code>normal</code>
* 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 ===

<syntaxhighlight lang="bash">
mv /boot/vmlinuz-$(uname -r) /root/dr-backup/
</syntaxhighlight>

* 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
<syntaxhighlight lang="bash">
mv /boot/initrd.img-$(uname -r) /root/dr-backup/
</syntaxhighlight>

;Rocky
<syntaxhighlight lang="bash">
mv /boot/initramfs-$(uname -r).img /root/dr-backup/
</syntaxhighlight>

* Symptom: Kernel startet, dann Panic
"VFS: Unable to mount root fs on unknown-block(0,0)"
* Lernziel: Unterschied <code>update-initramfs</code> gegen <code>dracut</code>

=== Szenario 6: falsche root-UUID ===

<syntaxhighlight lang="bash">
sed -i 's/root=UUID=[0-9a-f-]\{36\}/root=UUID=00000000-0000-0000-0000-000000000000/g' \
/boot/grub/grub.cfg
</syntaxhighlight>

* Symptom: nach etwa 30 Sekunden BusyBox-Prompt <code>(initramfs)</code>
* Lernziel: <code>blkid</code> im initramfs, Kernelparameter im GRUB-Menü mit
<code>e</code> korrigieren, danach dauerhaft reparieren

== Ebene 3: frühes Userspace ==

=== Szenario 7: Datenplatte hängt den Boot auf ===

<syntaxhighlight lang="bash">
echo "UUID=deadbeef-0000-0000-0000-000000000000 /daten ext4 defaults 0 2" \
>> /etc/fstab
mkdir -p /daten
</syntaxhighlight>

* Symptom: 90 Sekunden Wartezeit, danach emergency.target mit Passwortabfrage
* Lernziel: <code>journalctl -xb</code>, systemd-fstab-generator, Option
<code>nofail</code>

=== Szenario 8: libc entfernt ===

;Debian
<syntaxhighlight lang="bash">
rm /lib/x86_64-linux-gnu/libc.so.6
</syntaxhighlight>

;Rocky
<syntaxhighlight lang="bash">
rm /lib64/libc.so.6
</syntaxhighlight>

* Symptom: kein neuer Prozess startet mehr, bereits laufende Prozesse leben weiter
* Vorführung: <code>echo test</code> als Bash-Builtin funktioniert noch,
<code>ls</code> nicht mehr – der Aha-Punkt zu unlink gegen löschen
* Snapshot zwingend, die VM ist danach nur noch per
<code>VBoxManage controlvm it201 poweroff</code> zu beenden

== Ebene 4: Dateisysteme und Speicher ==

=== Szenario 9: ext4-Superblock zerstört ===

;Testdateisystem anlegen und füllen
<syntaxhighlight lang="bash">
mkfs.ext4 /dev/sde
mount /dev/sde /mnt
cp -r /etc /mnt/
umount /mnt
</syntaxhighlight>

;Primären Superblock bei Byte-Offset 1024 nullen
<syntaxhighlight lang="bash">
dd if=/dev/zero of=/dev/sde bs=1024 seek=1 count=1
sync
</syntaxhighlight>

* Symptom: <code>mount</code> scheitert mit "can't read superblock"
* Hinweis: <code>e2fsck</code> greift oft von selbst auf einen Backup-Superblock
zurück – das ist selbst ein Lernpunkt. Für den manuellen Weg
<code>mke2fs -n /dev/sde</code> zeigen und <code>fsck -b 32768</code> erzwingen

=== Szenario 10: LVM Physical Volume zerstört ===

;Aufbau
<syntaxhighlight lang="bash">
pvcreate /dev/sdc
vgcreate vgtest /dev/sdc
lvcreate -L 5G -n lvtest vgtest
mkfs.ext4 /dev/vgtest/lvtest
</syntaxhighlight>

;UUID vorher notieren
<syntaxhighlight lang="bash">
pvs -o pv_name,pv_uuid
</syntaxhighlight>

;LVM-Label und Metadatenanfang überschreiben
<syntaxhighlight lang="bash">
dd if=/dev/zero of=/dev/sdc bs=512 count=4
sync
pvscan
</syntaxhighlight>

* Symptom: <code>pvs</code> und <code>vgs</code> zeigen die VG nicht mehr
* Lernziel: LVM legt bei jeder Änderung automatisch ein Archiv unter
<code>/etc/lvm/archive</code> an – Rettung über <code>pvcreate --uuid ...
--restorefile ...</code> und <code>vgcfgrestore</code>

=== Szenario 11: Partitionstabelle gelöscht ===

<syntaxhighlight lang="bash">
dd if=/dev/zero of=/dev/sdb bs=512 count=1
partprobe /dev/sdb
</syntaxhighlight>

* Symptom: <code>lsblk</code> zeigt nur noch die nackte Platte ohne Partitionen
* Zwei Lösungswege gegenüberstellen: <code>testdisk</code> als Rekonstruktion
gegen <code>sfdisk /dev/sdb < sdb.dump</code> aus der Sicherung
* Die Botschaft ist der Kontrast: das Spektakuläre gegen das Richtige

=== Szenario 12: belegter Platz ohne sichtbare Datei ===

<syntaxhighlight lang="bash">
dd if=/dev/zero of=/var/log/gross.log bs=1M count=4000 &
sleep 5
rm /var/log/gross.log
df -h /var
</syntaxhighlight>

* Symptom: <code>df</code> meldet den Platz als belegt, <code>du</code> findet nichts
* Lernziel: <code>lsof +L1</code>, Prozess beenden statt Dateien suchen

== Ebene 5: Rocky-spezifisch ==

=== Szenario 13: SELinux-Kontexte zerstört ===

<syntaxhighlight lang="bash">
setenforce 1
chcon -R -t var_t /etc/ssh
systemctl restart sshd
</syntaxhighlight>

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

{{Hinweis|<code>chcon</code> wird hier bewusst als Sabotagewerkzeug
eingesetzt. Für die reguläre Kontextvergabe gilt weiterhin
<code>semanage fcontext</code> mit anschließendem <code>restorecon</code>.}}

== 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.

<syntaxhighlight lang="bash">
#!/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
</syntaxhighlight>

;Die Auflösung erfolgt gemeinsam anhand der Leitfrage
* Woran war erkennbar, welche Ebene der Bootkette ausgefallen ist?

Desaster Recovery Probleme schaffen - Versionsgeschichte

Thomas.will: 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…“