Backup-Strategie & Defense-in-Depth für Linux-Server

Backup-Strategie & Defense-in-Depth für Linux-Server

Alle Firewalls, alle SSH-Härtung und alle Monitoring-Systeme der Welt helfen dir nicht, wenn ein Ransomware-Angriff deine Daten verschlüsselt und du kein funktionierendes Backup hast. Backups sind dein letztes Sicherheitsnetz — und gleichzeitig die Maßnahme, die am häufigsten vernachlässigt wird.

In diesem Artikel geht es um zwei Themen: Die 3-2-1-Backup-Regel mit praktischen Beispielen für restic und borgbackup, und das Defense-in-Depth-Konzept — wie alle Sicherheitsmaßnahmen als Schichten zusammenspielen. Das ist der Abschluss der sechsteiligen Sicherheitsserie.

DarkWolfCave.de

ℹ️ Hinweis: Die hier gezeigten Konfigurationen sind Empfehlungen aus meiner eigenen Praxis — keine Garantie für vollständige Sicherheit. Jedes Setup ist anders. Teste Änderungen immer zuerst in einer Testumgebung und passe sie an deine Infrastruktur an. Backup-Strategien und Tools gibt es viele — dieser Artikel zeigt einen bewährten Ansatz mit der 3-2-1-Regel.

Warum Backups das Wichtigste überhaupt sind

Ransomware ist 2026 die größte Bedrohung für Server-Betreiber. Moderne Varianten warten oft Wochen nach der Infektion, bevor sie zuschlagen — und suchen gezielt nach Backups, um diese zuerst zu verschlüsseln.

Einen kompromittierten Server kannst du neu aufsetzen. Verlorene Daten nicht. Eine durchdachte Backup-Strategie ist deshalb keine Option, sondern Pflicht.

⚠️ Wichtig: Ein Backup, das du nie getestet hast, ist kein Backup. Teste regelmäßig, ob du aus deinen Backups tatsächlich wiederherstellen kannst!

Die 3-2-1-Backup-Regel

Die 3-2-1-Regel ist der Goldstandard für Backup-Strategien und wird auch vom BSI IT-Grundschutz empfohlen (Baustein CON.3):

• 3 Kopien deiner Daten (Original + 2 Backups)
• 2 verschiedene Medientypen (z.B. lokale SSD + Cloud-Storage)
• 1 Kopie an einem externen Standort (Offsite)

	Kopie 1	Kopie 2	Kopie 3
Was	Original-Daten	Lokales Backup	Offsite-Backup
Wo	Server / NAS	Andere Festplatte	Cloud / Remote
Medium	SSD / HDD	SSD / HDD (getrennt)	Object Storage (S3/B2/MinIO)
Standort	Dein Serverraum	Dein Serverraum	Anderer Standort

restic vs. borgbackup: Der große Vergleich

Für verschlüsselte, deduplizierte Backups unter Linux sind restic und borgbackup die beiden besten Optionen. Beide sind Open Source, beide verschlüsseln und deduplizieren — aber sie haben unterschiedliche Stärken.

Feature	restic	borgbackup
Sprache	Go	Python/C
Verschlüsselung	AES-256 (immer aktiv)	AES-256 (optional)
Deduplizierung	Content-Defined Chunking	Content-Defined Chunking
Kompression	Zstandard (seit 0.14)	LZ4, Zstd, LZMA
Cloud-Backends	S3, B2, Azure, GCS, SFTP, REST	SSH/SFTP (nativ), rclone für Cloud
Geschwindigkeit	Schnell, parallelisiert	Sehr schnell bei großen Repos
Restore	Einfach, Mount möglich	Einfach, Mount möglich
Einrichtung	Sehr einfach	Etwas komplexer
Ideal für	Cloud-Backups, Multi-Backend	Lokale/SSH-Backups, große Daten

💡 Tipp: Du musst dich nicht für eines entscheiden. Für die 3-2-1-Regel kannst du borgbackup für lokale Backups und restic für Cloud-Backups nutzen — so hast du automatisch zwei verschiedene Tools und reduzierst das Risiko eines Software-Bugs.

restic einrichten: Cloud-Backup in 5 Minuten

# restic installieren
sudo apt install restic

# Repository auf Backblaze B2 initialisieren
export B2_ACCOUNT_ID="dein-account-id"
export B2_ACCOUNT_KEY="dein-account-key"
restic -r b2:mein-backup-bucket init

# Erstes Backup erstellen
restic -r b2:mein-backup-bucket backup /etc /home /opt \
  --exclude='*.tmp' \
  --exclude='*.cache' \
  --tag server-daily

# Snapshots anzeigen
restic -r b2:mein-backup-bucket snapshots

# Alte Snapshots aufräumen (7 täglich, 4 wöchentlich, 6 monatlich)
restic -r b2:mein-backup-bucket forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

borgbackup einrichten: Lokales + SSH-Backup

# borgbackup installieren
sudo apt install borgbackup

# Lokales Repository initialisieren (verschlüsselt)
borg init --encryption=repokey /mnt/backup/borg-repo

# SSH-Repository auf Remote-Server initialisieren
borg init --encryption=repokey ssh://backup-user@backup-server/~/borg-repo

# Backup erstellen
borg create /mnt/backup/borg-repo::'{hostname}-{now:%Y-%m-%d}' \
  /etc /home /opt \
  --exclude '*.cache' \
  --exclude '*.tmp' \
  --compression zstd,3

# Alte Archive aufräumen
borg prune /mnt/backup/borg-repo \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6

# Repository-Integrität prüfen
borg check /mnt/backup/borg-repo

Backup-Automatisierung mit systemd Timer

Cron funktioniert, aber systemd Timer bieten bessere Logging-Integration und Fehlerbehandlung. Hier ein Beispiel für automatische restic-Backups:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic Backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /home /opt \
  --exclude-file=/etc/restic/excludes.txt \
  --tag auto-daily
ExecStartPost=/usr/bin/restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Restic Backup Timer

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

# Timer aktivieren und starten
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

# Status prüfen
systemctl list-timers | grep restic
journalctl -u restic-backup.service --since today

💡 Tipp: Persistent=true stellt sicher, dass ein verpasstes Backup (z.B. weil der Server um 03:00 aus war) beim nächsten Start nachgeholt wird. RandomizedDelaySec verteilt die Last, wenn du mehrere Server hast.

Restore testen — das Wichtigste überhaupt

Ein Backup ist nur so gut wie der letzte erfolgreiche Restore-Test. Baue dir ein automatisches Skript das mindestens monatlich prüft:

#!/bin/bash
# /usr/local/bin/backup-restore-test.sh
# Monatlicher Restore-Test

RESTORE_DIR=$(mktemp -d /tmp/restore-test-XXXXX)
LOGFILE="/var/log/backup-restore-test.log"

echo "$(date): Starting restore test..." >> "$LOGFILE"

# restic: Letzen Snapshot wiederherstellen
restic -r b2:mein-backup-bucket restore latest \
  --target "$RESTORE_DIR" \
  --include /etc/ssh/sshd_config 2>> "$LOGFILE"

# Prüfen ob die Datei existiert und nicht leer ist
if [ -s "$RESTORE_DIR/etc/ssh/sshd_config" ]; then
  echo "$(date): RESTORE TEST PASSED" >> "$LOGFILE"
else
  echo "$(date): RESTORE TEST FAILED!" >> "$LOGFILE"
  # Hier Alarm senden (Mail, Webhook, etc.)
fi

# Aufräumen
rm -rf "$RESTORE_DIR"

⚠️ Wichtig: Teste nicht nur, ob Dateien existieren — prüfe auch, ob sie lesbar und vollständig sind. Mindestens einmal im Quartal solltest du einen kompletten Server-Restore auf einer Test-VM durchführen.

Defense-in-Depth — Sicherheit in Schichten

Jetzt kommen wir zum großen Bild. Jede einzelne Sicherheitsmaßnahme, die wir in dieser Artikelserie besprochen haben — SSH-Härtung, Firewalls, OS-Hardening, Monitoring — kann für sich allein umgangen werden. Genau deshalb gibt es Defense-in-Depth.

Das Prinzip: Jede Schicht fängt ab, was die vorherige durchlässt

Defense-in-Depth kommt ursprünglich aus dem Militär und ist heute ein Kernkonzept der IT-Sicherheit. Die Idee: Statt auf eine einzige, perfekte Verteidigungslinie zu setzen, baust du mehrere unabhängige Schichten auf.

Schicht	Funktion	Maßnahmen	Artikel
Angreifer	↓ Angriff beginnt	—	—
1. Netzwerk	Pakete filtern	Firewall (ufw/nftables), Port-Filterung, VPN	Netzwerk-Sicherheit
2. Perimeter	Bots aufhalten	Endlessh (Tarpit), Fail2ban, GeoIP-Blocking	Endlessh SSH Tarpit
3. Authentifizierung	Zugang kontrollieren	SSH-Keys, 2FA, Certificate Authority	SSH-Server absichern
4. Betriebssystem	OS härten	Minimale Pakete, Updates, AppArmor/SELinux	Linux-Server härten
5. Erkennung	Einbrüche erkennen	IDS/IPS, Log-Monitoring, Alerting	Monitoring & IDS
6. Wiederherstellung	Daten retten	3-2-1 Backups, Incident Response Plan	Dieser Artikel

Warum jede Schicht unabhängig funktionieren muss

Bei Defense-in-Depth gilt: Keine Schicht darf davon ausgehen, dass eine andere Schicht funktioniert. Jede Schicht muss so konfiguriert sein, als wäre sie die einzige Verteidigung.

Konkret bedeutet das:

• Die Firewall blockiert unerwünschten Traffic — aber SSH muss trotzdem gehärtet sein, falls die Firewall versagt
• SSH nutzt nur Keys und 2FA — aber AppArmor muss trotzdem laufen, falls jemand reinkommt
• Das IDS erkennt Anomalien — aber das Backup muss trotzdem funktionieren, falls der Angriff durchgeht
• Das Backup liegt verschlüsselt Offsite — aber der Incident Response Plan muss trotzdem stehen

💡 Tipp: Denke bei jeder Schicht: “Was passiert, wenn diese Schicht komplett versagt?” Wenn die Antwort “Totalverlust” ist, fehlt dir eine Schicht.

Defense-in-Depth nach BSI IT-Grundschutz

Das BSI IT-Grundschutz Kompendium strukturiert Sicherheit in drei Schutzstufen:

Stufe	BSI-Bezeichnung	Unsere Artikelserie
Basis	Grundlegende Absicherung	SSH-Keys, Firewall, Updates
Standard	Normale Absicherung	IDS, AppArmor, 3-2-1-Backups
Erhöht	Erhöhter Schutzbedarf	SSH-CA, Zero Trust, Incident Response

Jede Stufe baut auf der vorherigen auf. Du kannst nicht “erhöhten Schutzbedarf” umsetzen, wenn die Basis-Absicherung fehlt. Das ist Defense-in-Depth in der Praxis.

Wie Endlessh in das Gesamtbild passt

Endlessh ist ein perfektes Beispiel für eine einzelne Schicht im Defense-in-Depth-Modell. Für sich allein bietet es keine echte Sicherheit — Bots haben Timeouts und ziehen weiter. Aber als Teil des Gesamtsystems erfüllt es zwei wichtige Funktionen:

1. Verlangsamung: Bots verschwenden Zeit an deinem Tarpit statt andere Server zu scannen
2. Monitoring-Daten: Du siehst in Grafana live, wer auf deinen Server zugreift

Das ist Defense-in-Depth in der Praxis: Viele kleine Maßnahmen, die zusammen wirken.

Die komplette Sicherheits-Checkliste

Hier ist die Zusammenfassung aller Maßnahmen aus der Artikelserie:

✅ Netzwerk-Sicherheit    → Firewall, Port-Filterung, VPN, Zero Trust
✅ SSH-Härtung             → Keys, 2FA, gehärtete Algorithmen, SSH-CA
✅ OS-Hardening            → Minimale Pakete, AppArmor, automatische Updates
✅ Monitoring              → IDS/IPS, Log-Analyse, Alerting
✅ Perimeter               → Endlessh Tarpit, Fail2ban, GeoIP-Blocking
✅ Backup                  → 3-2-1-Regel, restic/borgbackup, Restore-Tests
✅ Incident Response       → Dokumentierter Plan, Verantwortlichkeiten, Übungen

Die komplette Artikelserie

Diese sechs Artikel bilden zusammen einen Leitfaden für Linux-Server-Sicherheit:

1. SSH-Server absichern — Die Eingangstür härten
2. Netzwerk-Sicherheit & Firewall — Den Perimeter schützen
3. Linux-Server härten — Die Angriffsfläche minimieren
4. Monitoring & Intrusion Detection — Angriffe erkennen
5. Endlessh SSH Tarpit — Bots aufhalten und beobachten
6. Backup & Defense-in-Depth (dieser Artikel) — Das Sicherheitsnetz und die Gesamtstrategie

Jeder Artikel behandelt eine oder mehrere Schichten im Defense-in-Depth-Modell. Fang mit den Basics an: SSH-Keys, Firewall, automatische Updates und ein verschlüsseltes Offsite-Backup. Dann arbeite dich Schicht für Schicht vor.

🔒 Merke: Regelmäßig testen, regelmäßig verbessern.