25 KiB
25 KiB
🍰 Der Kuchen muss wachsen können: Partitionierung & das 1MB-Gap
Subtitle: Warum dein System Platz zum Atmen braucht - und was passiert wenn nicht
Version: 1.0
Audience: Alle die Server aufsetzen - BEVOR es zu spät ist
"Ein Kuchen ohne Platz zum Aufgehen ist ein flacher Keks. Ein System ohne Raum zu wachsen ist eine Zeitbombe." 🍰💣
— Bugsy der Bug-Finder 🐛
📋 Inhaltsverzeichnis
- Die Geschichte vom 1MB Gap
- Warum Systeme Platz brauchen
- Partitionierung richtig gemacht
- Der Krümel-Anmelde-Workflow
- Fehler sind toll! (sagt Bugsy)
- Storage-Strategien
- Backup, Backup, BACKUP
- Checkliste vor dem ersten Start
🐛 Die Geschichte vom 1MB Gap
Wie wir es entdeckten
# Alles lief perfekt... oder?
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 20G 19G 0G 100% / # 💀 OH NEIN!
# Wir versuchten zu erweitern...
$ fdisk /dev/sda
WARNING: GPT PMBR size mismatch!
# Und dann sahen wir es:
$ gdisk -l /dev/sda
Warning! Disk size is smaller than the main header indicates!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Number Start (sector) End (sector) Size Code Name
1 2048 41943039 20.0 GiB 8300 Linux filesystem
# Aber die Disk war 40GB groß!
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk # ← 40GB verfügbar!
└─sda1 8:1 0 20G 0 part / # ← nur 20GB genutzt!
Das Problem:
Die Partition war hart codiert auf 20GB, obwohl die VM auf 40GB vergrößert wurde. Und wegen einem fehlenden 1MB Gap am Anfang konnten wir nichts mehr tun! 🤦
Bugsy's Reaktion
🐛
/🔍\
/_||_\
"Fehler sind toll! Sie zeigen uns wo wir
nicht aufgepasst haben. Dieser hier ist
ein Klassiker: Der 'No-Space-to-Breathe'-Bug.
Die Lösung? BACKUP, neu partitionieren,
und dieses Mal: MIT GAP!"
*schmunzelt*
🌱 Warum Systeme Platz brauchen
Das Krümel-Prinzip
Ein System ist wie ein Kuchen im Ofen:
Zu kleine Form:
├─ Kuchen quillt über den Rand 💀
├─ Brennt an
└─ Chaos in der Küche
Richtige Form mit Raum:
├─ Kuchen geht auf ✅
├─ Hat Platz zu wachsen
└─ Wird perfekt
Wo Systeme wachsen
/var/log/ # Logs wachsen IMMER
/var/cache/ # Cache sammelt sich an
/home/user/ # User speichern Daten
/tmp/ # Temporäre Dateien
/opt/applications/ # Software-Installationen
/var/lib/docker/ # Docker Images & Container
/var/lib/postgresql/ # Datenbanken
Real-World Beispiel:
# Tag 1: Fresh Install
$ df -h /var
/var 10G 2G 8G 20%
# Tag 30: Logs, Cache, Docker
$ df -h /var
/var 10G 9.5G 500M 95% # 😰
# Tag 45: Ohne Überwachung
$ df -h /var
/var 10G 10G 0 100% # 💀 SYSTEM KAPUTT
💾 Partitionierung richtig gemacht
Das 1MB-Gap Problem erklärt
Disk Layout OHNE Gap (FALSCH):
┌────────────────────────────────────────┐
│ Byte 0 │ Partition startet bei 0 │ ← KEINE FLEXIBILITÄT!
├───────────┴───────────────────────────┤
│ /dev/sda1 (20GB) │
└───────────────────────────────────────┘
└─ Fest codiert, kann nicht wachsen
Disk Layout MIT 1MB Gap (RICHTIG):
┌─────┬──────────────────────────────────┐
│ 1MB │ Partition startet bei 2048 │ ← RAUM FÜR GPT/MBR!
│ GAP │ (Sektor 2048 = 1MB) │
├─────┴──────────────────────────────────┤
│ /dev/sda1 (19.999GB) │
│ │
│ ← Kann später erweitert werden! ✅ │
└─────────────────────────────────────────┘
Warum 2048 Sektoren = 1MB?
1 Sektor = 512 Bytes (traditionell)
2048 Sektoren × 512 Bytes = 1,048,576 Bytes = 1 MiB
Moderne Disks (4K Native):
1 Sektor = 4096 Bytes
2048 Sektoren × 4096 Bytes = 8 MiB (noch besser!)
Die richtige Art zu partitionieren
Methode 1: fdisk (MBR/DOS)
# IMMER mit Gap starten!
$ fdisk /dev/sda
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-83886079, default 2048): [ENTER] # ← Nimm Default 2048!
^^^^^^^^
Last sector, +/-sectors or +/-size{K,M,G,T,P}: +20G
Command (m for help): w # Write changes
Methode 2: gdisk (GPT - EMPFOHLEN!)
# GPT ist moderner und besser
$ gdisk /dev/sda
Command (? for help): n
Partition number (1-128, default 1): [ENTER]
First sector (34-83886046, default = 2048): [ENTER] # ← Default = Gap!
Last sector or +size: +20G
Hex code or GUID (L to show codes, Enter = 8300): [ENTER] # Linux filesystem
Command (? for help): w # Write
Methode 3: parted (scriptbar)
# Perfekt für Automatisierung
parted /dev/sda mklabel gpt
parted /dev/sda mkpart primary ext4 1MiB 20GiB
^^^^^
Explizites 1MB Gap!
Layout-Strategien
Klein aber flexibel (20GB Disk)
/dev/sda1 512M /boot # Boot-Partition
/dev/sda2 18G / # Root (mit Raum zu wachsen)
/dev/sda3 1.5G swap # Swap
# Beispiel:
parted /dev/sda mklabel gpt
parted /dev/sda mkpart primary fat32 1MiB 513MiB
parted /dev/sda mkpart primary ext4 513MiB 18.5GiB
parted /dev/sda mkpart primary linux-swap 18.5GiB 20GiB
Standard Server (100GB+)
/dev/sda1 1G /boot # Boot
/dev/sda2 30G / # Root
/dev/sda3 Rest LVM # LVM für Flexibilität!
├─ vg0-var 20G /var
├─ vg0-home 20G /home
└─ vg0-data Rest /opt/data
Production Server mit LVM (BESTE Praxis)
# Physikalische Partitionen:
/dev/sda1 1G /boot # Boot (kein LVM)
/dev/sda2 Rest LVM PV # Alles andere in LVM
# Logical Volumes:
lvcreate -L 20G -n root vg0 # /
lvcreate -L 30G -n var vg0 # /var
lvcreate -L 20G -n home vg0 # /home
lvcreate -L 10G -n tmp vg0 # /tmp
lvcreate -L 50G -n data vg0 # /opt/data
# Vorteil: Volumes können später LIVE erweitert werden!
🍪 Der Krümel-Anmelde-Workflow
Phase 0: Planung (BEVOR du installierst!)
#!/bin/bash
# kruemel-planung.sh
echo "=== Krümel-Anmeldung: Systemplanung ==="
echo ""
echo "1. Was ist der Zweck des Systems?"
echo " [ ] Webserver"
echo " [ ] Database Server"
echo " [ ] Application Server"
echo " [ ] Development Machine"
echo " [ ] Container Host (Docker/k8s)"
echo ""
echo "2. Wie viel Speicher brauche ich?"
echo " Initial: _____ GB"
echo " Nach 1 Jahr: _____ GB (geschätzt)"
echo " Nach 3 Jahren: _____ GB (geschätzt)"
echo ""
echo "3. Welche Daten wachsen?"
echo " [ ] Logs (/var/log)"
echo " [ ] Datenbank (/var/lib/postgresql|mysql)"
echo " [ ] User Data (/home)"
echo " [ ] Docker Images (/var/lib/docker)"
echo " [ ] Application Files (/opt)"
echo ""
echo "4. Backup-Strategie?"
echo " [ ] Täglich"
echo " [ ] Stündlich"
echo " [ ] Real-time (Continuous Backup)"
echo " [ ] Snapshots (LVM/ZFS)"
echo ""
echo "5. Redundanz?"
echo " [ ] RAID 1 (Mirror)"
echo " [ ] RAID 5/6 (Parity)"
echo " [ ] Cloud Backup"
echo " [ ] Offsite Backup"
echo ""
Phase 1: Disk-Vorbereitung
#!/bin/bash
# kruemel-disk-prep.sh
DISK="/dev/sda"
echo "=== Krümel Disk Preparation ==="
# 1. Disk-Info sammeln
echo "Disk Size: $(lsblk -dno SIZE $DISK)"
echo "Disk Model: $(lsblk -dno MODEL $DISK)"
# 2. WARNUNG
echo ""
echo "⚠️ WARNUNG: Alle Daten auf $DISK werden gelöscht!"
echo "⚠️ BACKUP erstellt? [y/N]"
read -r BACKUP_DONE
if [ "$BACKUP_DONE" != "y" ]; then
echo "Abbruch. Erstelle erst ein Backup!"
exit 1
fi
# 3. Alte Partitionstabelle löschen
wipefs -a $DISK
# 4. GPT Label erstellen (mit 1MB Gap automatisch)
parted -s $DISK mklabel gpt
# 5. Partitionen erstellen
echo "Erstelle Partitionen mit 1MB Gap..."
# Boot Partition (1GB, startet bei 1MiB)
parted -s $DISK mkpart primary fat32 1MiB 1025MiB
parted -s $DISK set 1 boot on
# Root Partition (20GB)
parted -s $DISK mkpart primary ext4 1025MiB 21GiB
# LVM Partition (Rest)
parted -s $DISK mkpart primary ext4 21GiB 100%
# 6. Resultat anzeigen
echo ""
echo "Partitionierung abgeschlossen:"
parted -s $DISK print
gdisk -l $DISK
echo ""
echo "✅ 1MB Gap vorhanden: $(gdisk -l $DISK | grep 'First usable')"
Phase 2: LVM Setup (empfohlen!)
#!/bin/bash
# kruemel-lvm-setup.sh
DISK="/dev/sda"
VG_NAME="vg0"
echo "=== Krümel LVM Setup ==="
# 1. Physical Volume erstellen
pvcreate ${DISK}3
pvdisplay
# 2. Volume Group erstellen
vgcreate $VG_NAME ${DISK}3
vgdisplay
# 3. Logical Volumes erstellen (mit Reserve!)
echo "Erstelle Logical Volumes (lasse 20% frei für später)..."
TOTAL_SIZE=$(vgs --noheadings -o vg_size --units g $VG_NAME | tr -d 'g' | xargs)
USABLE_SIZE=$(echo "$TOTAL_SIZE * 0.8" | bc | cut -d'.' -f1)
echo "Total VG Size: ${TOTAL_SIZE}G"
echo "Usable (80%): ${USABLE_SIZE}G"
# Root
lvcreate -L 20G -n root $VG_NAME
# Var (Logs!)
lvcreate -L 30G -n var $VG_NAME
# Home
lvcreate -L 20G -n home $VG_NAME
# Data
lvcreate -L $(($USABLE_SIZE - 70))G -n data $VG_NAME
# 4. Filesysteme erstellen
mkfs.ext4 /dev/mapper/${VG_NAME}-root
mkfs.ext4 /dev/mapper/${VG_NAME}-var
mkfs.ext4 /dev/mapper/${VG_NAME}-home
mkfs.ext4 /dev/mapper/${VG_NAME}-data
# 5. Übersicht
echo ""
echo "✅ LVM Setup abgeschlossen:"
lvdisplay
Phase 3: Monitoring Setup
#!/bin/bash
# kruemel-monitoring.sh
echo "=== Krümel Disk Monitoring Setup ==="
# 1. Cron Job für Disk-Check
cat > /etc/cron.hourly/disk-check << 'EOF'
#!/bin/bash
# Warnung bei >80% Auslastung
df -h | awk '
NR>1 && $5+0 > 80 {
print "⚠️ WARNING: " $6 " ist " $5 " voll!" | "mail -s \"Disk Space Alert\" admin@example.com"
}'
EOF
chmod +x /etc/cron.hourly/disk-check
# 2. SMART Monitoring
apt-get install -y smartmontools
systemctl enable smartd
systemctl start smartd
# 3. LVM Monitoring (wenn vorhanden)
if command -v vgs &>/dev/null; then
cat > /etc/cron.daily/lvm-check << 'EOF'
#!/bin/bash
# Check LVM free space
vgs --noheadings -o vg_name,vg_free | while read VG FREE; do
FREE_GB=$(echo $FREE | sed 's/[^0-9.]//g')
if (( $(echo "$FREE_GB < 10" | bc -l) )); then
echo "⚠️ WARNING: Volume Group $VG hat nur ${FREE_GB}GB frei!" | \
mail -s "LVM Space Alert" admin@example.com
fi
done
EOF
chmod +x /etc/cron.daily/lvm-check
fi
echo "✅ Monitoring eingerichtet"
🐛 Fehler sind toll! (sagt Bugsy)
Bugsy's Philosophie
🐛
/😊\
/_||_\
"Jeder Fehler ist ein Lehrer.
Jeder Bug ist eine Chance.
Aber: Fehler ohne Backup?
Das ist kein Fehler,
das ist ein Unfall.
Also: Test, Break, Learn, BACKUP!"
Die 5 Phasen des Fehler-Umgangs
1. Finden (Discovery)
# Symptom: System ist langsam
$ df -h
/dev/sda1 20G 20G 0 100% / # 💀
# Bugsy: "Ah! Ein 'Full-Disk'-Bug!"
2. Verstehen (Analysis)
# Was frisst den Speicher?
$ du -sh /* | sort -h
1.5G /var
8.0G /usr
10G /opt/huge-application
# Bugsy: "Interessant! /opt ist der Täter."
# Können wir die Partition erweitern?
$ gdisk -l /dev/sda
Warning: No space to grow!
# Bugsy: "Aha! Der 'No-Gap'-Bug. Klassiker!"
3. Planen (Strategy)
# Bugsy's Schlachtplan:
echo "Plan A: Backup → Neue Disk → Restore mit mehr Platz"
echo "Plan B: Alte Daten archivieren und auslagern"
echo "Plan C: Cleanup + Monitoring (temporär)"
# IMMER mit Backup beginnen!
4. Lösen (Implementation)
# STEP 1: BACKUP!
$ rsync -avP /opt/ /mnt/backup/opt/
# STEP 2: Neue größere Disk anlegen (z.B. 100GB)
$ # ... (siehe Disk-Prep-Script oben)
# STEP 3: Restore
$ rsync -avP /mnt/backup/opt/ /opt/
# STEP 4: Alte Disk als Backup behalten (erstmal)
5. Dokumentieren (Documentation)
# /var/log/kruemel/fixes/2024-12-06-disk-full.md
cat > /var/log/kruemel/fixes/2024-12-06-disk-full.md << 'EOF'
# Fix: Disk Full bei /dev/sda1
## Problem
- /dev/sda1 zu 100% voll
- Kein 1MB Gap für Expansion
- /opt/huge-application frisst 10GB
## Root Cause
- Partitionierung ohne Gap
- Keine Monitoring-Alerts
- Unerwartetes Wachstum von /opt
## Lösung
1. Backup nach /mnt/backup/
2. Neue 100GB Disk mit LVM
3. Restore mit mehr Reserven
4. Monitoring aktiviert
## Prevention
- LVM für zukünftige Flexibilität
- Cron-Job für Disk-Check
- Alerts bei >80%
## Lessons Learned
- IMMER mit 1MB Gap partitionieren
- IMMER LVM nutzen (außer /boot)
- IMMER 20% Reserve lassen
- IMMER Monitoring von Tag 1
## Date: 2024-12-06
## Fixed by: Bugsy & Team
EOF
💿 Storage-Strategien
Single Disk (Basic)
# Für: Test-VMs, Development
Partition Layout:
/boot 1GB ext4
/ 20GB ext4 (oder /)
swap 2GB swap
/home Rest ext4
Pros:
✅ Einfach
✅ Schnell
Cons:
❌ Keine Redundanz
❌ Schwer zu erweitern
LVM (Recommended)
# Für: Production, Flexibilität
Partition Layout:
/boot 1GB ext4 (kein LVM)
LVM PV Rest → Volume Group
├─ root 20GB /
├─ var 30GB /var
├─ home 20GB /home
└─ data Rest /opt/data
Pros:
✅ Live-Resize möglich!
✅ Snapshots für Backups
✅ Flexibel
Cons:
❌ Etwas komplexer
❌ Minimal Overhead
# Resize Beispiel:
lvextend -L +10G /dev/vg0/var
resize2fs /dev/vg0/var
# Fertig! Kein Reboot nötig!
RAID (Redundancy)
# Für: Wichtige Daten, 24/7 Betrieb
# RAID 1 (Mirror) - 2+ Disks
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
└─ Pros: Eine Disk kann ausfallen
└─ Cons: Nur 50% Kapazität
# RAID 5 (Parity) - 3+ Disks
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sd{a,b,c}
└─ Pros: Bessere Kapazität, eine Disk Ausfall OK
└─ Cons: Rebuild ist langsam
# RAID 10 (Mirror+Stripe) - 4+ Disks
mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sd{a,b,c,d}
└─ Pros: Schnell + Redundant
└─ Cons: 50% Kapazität
⚠️ RAID IST KEIN BACKUP!
└─ RAID schützt vor Disk-Failure
└─ RAID schützt NICHT vor: rm -rf /, Ransomware, Brand, etc.
Cloud & CDN
# Für: Global, Skalierbar, 24/7
Local Server + Cloud Backup:
/opt/data → rsync → S3/Backblaze/Wasabi
↓
Versioned
Encrypted
Offsite
CDN (Content Delivery):
User → Cloudflare CDN → Origin Server
↑ ↑
(Cache) (Your Server)
Pros:
✅ Global verfügbar
✅ Automatisch redundant
✅ Skaliert automatisch
Cons:
❌ Kosten laufend
❌ Abhängigkeit von Provider
Redis/Database Redundancy
# Redis Master-Replica
Master: 192.168.1.10
Replica: 192.168.1.11
Sentinel: 192.168.1.12 # Automatic failover
# PostgreSQL Streaming Replication
Primary: db1.example.com
Standby: db2.example.com
└─ pg_basebackup + streaming replication
# MySQL/MariaDB Master-Slave
Master: mysql1.example.com
Slave: mysql2.example.com
└─ Asynchronous replication
💾 Backup, Backup, BACKUP!
Bugsy's 3-2-1 Regel
🐛
/📦\
/_||_\
"3 Kopien deiner Daten
2 verschiedene Medien
1 Offsite/Cloud
Ohne Backup ist alles nur ein
Entwurf, der auf Löschung wartet."
Backup-Strategien
Level 0: File-based Backup
#!/bin/bash
# Simple rsync backup
SOURCE="/opt/data"
DEST="/mnt/backup/$(date +%Y-%m-%d)"
mkdir -p $DEST
rsync -avP --delete $SOURCE/ $DEST/
# Retention: Letzte 7 Tage behalten
find /mnt/backup/ -maxdepth 1 -mtime +7 -type d -exec rm -rf {} \;
Level 1: LVM Snapshots
# Snapshot erstellen (fast instant!)
lvcreate -L 5G -s -n var-snap /dev/vg0/var
# Backup vom Snapshot (System läuft weiter!)
mount /dev/vg0/var-snap /mnt/snapshot
rsync -avP /mnt/snapshot/ /mnt/backup/
umount /mnt/snapshot
# Snapshot löschen
lvremove /dev/vg0/var-snap
Level 2: System Image
# Komplettes System-Image
dd if=/dev/sda of=/mnt/backup/system-$(date +%Y%m%d).img bs=4M status=progress
# Oder komprimiert (spart Platz):
dd if=/dev/sda bs=4M status=progress | gzip > /mnt/backup/system-$(date +%Y%m%d).img.gz
# Restore:
gunzip -c system-20241206.img.gz | dd of=/dev/sda bs=4M status=progress
Level 3: Offsite Backup
# S3-compatible Storage (z.B. Backblaze B2, Wasabi)
#!/bin/bash
# Installation
apt-get install -y s3cmd
s3cmd --configure # API Keys eingeben
# Backup
s3cmd sync /opt/data/ s3://my-bucket/backup-$(date +%Y%m%d)/
# Encryption (empfohlen!)
tar czf - /opt/data/ | \
gpg --encrypt --recipient admin@example.com | \
s3cmd put - s3://my-bucket/encrypted-backup-$(date +%Y%m%d).tar.gz.gpg
Level 4: Continuous Backup
# Restic - Modern backup tool
apt-get install -y restic
# Initialize repository
restic -r /mnt/backup/restic init
# Backup (inkrementell!)
restic -r /mnt/backup/restic backup /opt/data/
# List snapshots
restic -r /mnt/backup/restic snapshots
# Restore
restic -r /mnt/backup/restic restore latest --target /restore/
# Prune old backups (keep last 7 daily, 4 weekly)
restic -r /mnt/backup/restic forget --keep-daily 7 --keep-weekly 4 --prune
Backup-Cron-Job (Production)
#!/bin/bash
# /etc/cron.daily/kruemel-backup
BACKUP_ROOT="/mnt/backup"
DATE=$(date +%Y-%m-%d)
RETENTION_DAYS=30
# Logging
exec > >(tee -a /var/log/kruemel-backup.log)
exec 2>&1
echo "=== Krümel Backup: $DATE ==="
# 1. LVM Snapshot Backup
echo "[1/4] Creating LVM snapshots..."
lvcreate -L 5G -s -n root-snap /dev/vg0/root
lvcreate -L 10G -s -n var-snap /dev/vg0/var
lvcreate -L 5G -s -n home-snap /dev/vg0/home
# 2. Mount & Backup
echo "[2/4] Backing up from snapshots..."
mkdir -p /mnt/snap-{root,var,home}
mount /dev/vg0/root-snap /mnt/snap-root
mount /dev/vg0/var-snap /mnt/snap-var
mount /dev/vg0/home-snap /mnt/snap-home
rsync -avP /mnt/snap-root/ $BACKUP_ROOT/$DATE/root/
rsync -avP /mnt/snap-var/ $BACKUP_ROOT/$DATE/var/
rsync -avP /mnt/snap-home/ $BACKUP_ROOT/$DATE/home/
# 3. Cleanup snapshots
echo "[3/4] Cleaning up snapshots..."
umount /mnt/snap-{root,var,home}
lvremove -f /dev/vg0/root-snap
lvremove -f /dev/vg0/var-snap
lvremove -f /dev/vg0/home-snap
# 4. Offsite sync
echo "[4/4] Syncing to cloud..."
s3cmd sync $BACKUP_ROOT/$DATE/ s3://my-bucket/backups/$DATE/
# 5. Retention
echo "Applying retention policy ($RETENTION_DAYS days)..."
find $BACKUP_ROOT -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;
echo "✅ Backup completed: $DATE"
echo ""
# 6. Report
BACKUP_SIZE=$(du -sh $BACKUP_ROOT/$DATE | cut -f1)
echo "Backup Size: $BACKUP_SIZE"
echo "Location: $BACKUP_ROOT/$DATE"
echo "Cloud: s3://my-bucket/backups/$DATE/"
✅ Checkliste vor dem ersten Start
Pre-Installation Checklist
## 🍰 Krümel-Anmeldung: System-Setup Checklist
### Phase 1: Planung ✏️
- [ ] Zweck des Systems definiert
- [ ] Speicherbedarf geschätzt (jetzt + 3 Jahre)
- [ ] Wachsende Daten identifiziert
- [ ] Backup-Strategie gewählt
- [ ] Redundanz-Level entschieden
### Phase 2: Hardware 💿
- [ ] Disk-Größe ausgewählt (mind. 2x geschätzter Bedarf)
- [ ] RAID-Level entschieden (falls Redundanz)
- [ ] Backup-Storage vorhanden
- [ ] Network-Storage für Offsite (falls 24/7)
### Phase 3: Partitionierung 🔧
- [ ] GPT statt MBR (für >2TB + Flexibilität)
- [ ] 1MB Gap am Anfang (Sektor 2048)
- [ ] /boot Partition (1GB, kein LVM)
- [ ] LVM für Rest (empfohlen!)
- [ ] Swap Partition/File (falls RAM < 8GB)
- [ ] 20% Reserve in LVM gelassen
### Phase 4: Installation 🚀
- [ ] System installiert
- [ ] Updates durchgeführt
- [ ] SSH eingerichtet
- [ ] Firewall konfiguriert
- [ ] Monitoring-Tools installiert (htop, iotop, nethogs)
### Phase 5: Backup-Setup 💾
- [ ] Backup-Script erstellt
- [ ] Cron-Job eingerichtet
- [ ] Erstes Backup erfolgreich
- [ ] Restore getestet! (wichtig!)
- [ ] Offsite-Backup aktiv (falls benötigt)
### Phase 6: Monitoring 📊
- [ ] Disk-Space-Alerts (<80%)
- [ ] SMART-Monitoring aktiv
- [ ] LVM-Free-Space-Checks
- [ ] Log-Rotation konfiguriert
- [ ] Uptime-Monitoring (24/7 Systeme)
### Phase 7: Dokumentation 📝
- [ ] System-Doku erstellt
- Hardware-Specs
- Partition-Layout
- Backup-Strategie
- Recovery-Prozedur
- [ ] Notfall-Kontakte dokumentiert
- [ ] Root-Password sicher gespeichert
- [ ] SSH-Keys backed up
### Phase 8: Testing 🧪
- [ ] Reboot-Test
- [ ] Backup-Restore-Test
- [ ] Disk-Full-Szenario simuliert
- [ ] Failover getestet (falls RAID/HA)
- [ ] Recovery-Time gemessen
### Bugsy's Final Check 🐛
- [ ] "Kann das System wachsen?" → JA
- [ ] "Kann ich ein Backup einspielen?" → JA
- [ ] "Weiß ich was zu tun ist wenn etwas schief geht?" → JA
- [ ] "Habe ich keine Angst vor Fehlern?" → NEIN
└─ (Weil ich Backups habe!)
🎓 Real-World Szenarien
Szenario 1: Der volle Server
# Alarm: Disk voll!
$ df -h
/dev/mapper/vg0-var 30G 30G 0 100% /var
# Quick-Fix (temporär):
journalctl --vacuum-size=1G # Alte Logs löschen
apt-get clean # Package cache leeren
docker system prune -a # Docker aufräumen
# Permanent-Fix:
lvextend -L +20G /dev/vg0/var # Volume erweitern
resize2fs /dev/vg0/var # Filesystem vergrößern
# Prevention:
# Siehe Monitoring-Script oben
Szenario 2: Disk failure (mit RAID)
# RAID meldet: /dev/sda failed
$ cat /proc/mdstat
md0 : active raid1 sdb1[1] sda1[0](F) # (F) = Failed!
# Schritt 1: Kaputte Disk entfernen
mdadm --manage /dev/md0 --remove /dev/sda1
# Schritt 2: Neue Disk einbauen (physisch)
# Schritt 3: Neue Disk zum RAID hinzufügen
mdadm --manage /dev/md0 --add /dev/sdc1
# Schritt 4: Rebuild abwarten (kann Stunden dauern)
watch cat /proc/mdstat
# ✅ System lief während der ganzen Zeit weiter!
Szenario 3: Versehentlich gelöscht
# Ohoh: Wichtiges Verzeichnis gelöscht
$ rm -rf /opt/production-data/
# KEINE PANIK!
# Schritt 1: SOFORT STOPPEN
# Nichts mehr auf die Disk schreiben!
# Schritt 2: Letztes Backup prüfen
$ ls -la /mnt/backup/
2024-12-05/
2024-12-06/ # ← Heute früh!
# Schritt 3: Restore
$ rsync -avP /mnt/backup/2024-12-06/opt/production-data/ /opt/production-data/
# ✅ Daten zurück! Nur wenige Stunden Verlust.
# Lesson learned:
# - Häufigere Backups (stündlich statt täglich)
# - LVM Snapshots für instant recovery
Szenario 4: System bootet nicht mehr
# Nach Update: System bootet nicht
# Rescue-Mode:
# 1. Von Live-USB/CD booten
# 2. Chroot in System
mkdir /mnt/rescue
mount /dev/mapper/vg0-root /mnt/rescue
mount /dev/sda1 /mnt/rescue/boot
mount --bind /dev /mnt/rescue/dev
mount --bind /proc /mnt/rescue/proc
mount --bind /sys /mnt/rescue/sys
chroot /mnt/rescue
# 3. Fix anwenden (z.B. Kernel neu installieren)
apt-get install --reinstall linux-image-generic
# 4. Bootloader reparieren
update-grub
grub-install /dev/sda
# 5. Reboot
exit
umount -R /mnt/rescue
reboot
# Falls das nicht hilft:
# → Backup einspielen!
🎯 Bugsy's Abschlussworte
🐛
/💙\
/_||_\
/ || \
"Der Kuchen ist gebacken.
Der Krümel ist angemeldet.
Das System kann wachsen.
Die Backups sind da.
Jetzt kann der Wald wachsen.
Aber vergiss nie:
Fehler kommen. Das ist OK.
Ohne Backup? Das ist NICHT OK.
Also: Test, Break, Learn...
aber IMMER mit Backup!
Happy Hacking! 🌲"
— Bugsy, der Bug-Finder & Krümel-Beschützer
📚 Referenzen & Links
Intern (Crumbforest)
Tools
- fdisk - Partition editor
- gdisk - GPT fdisk
- LVM - Logical Volume Manager
- mdadm - RAID management
- restic - Modern backup tool
- s3cmd - S3 client
Learning
Version: 1.0
Letzte Änderung: 2024-12-06
Maintainer: Bugsy & Crumbforest Team
Feedback: GitHub Issues | Discord
🍰 Der Kuchen ist gebacken. Die Krümel sind angemeldet. Der Wald kann wachsen. 🐛💙