Automatisierte 3-2-1-Backups auf Netcup einrichten: SCP-Snapshots, atomare DB-Dumps & verschlüsseltes Restic
Hardware-RAID10-NVMe-Arrays in den Netcup-Rechenzentren Nürnberg, Wien und Amsterdam schützen Ihren Server zwar zuverlässig vor dem physischen Ausfall einzelner SSDs, bieten jedoch keinerlei Schutz gegen ein versehentliches DROP TABLE, fehlerhafte Migrationsskripte, rm -rf oder kompromittierte Zugangsdaten. Hinzu kommt: Die im Netcup Server Control Panel (SCP) integrierten Snapshots nutzen Copy-on-Write-(CoW)-Allokationen auf demselben zugrunde liegenden Storage-Pool – sie belegen also freien Speicherplatz Ihres eigenen VM-Kontingents und ersetzen kein externes Disaster-Recovery-Backup. Dieses Runbook implementiert eine praxiserprobte 3-2-1-Backup-Architektur, die konsistente SCP-Snapshots via qemu-guest-agent für schnelle Rollbacks vor System-Upgrades mit automatisierten, atomaren Datenbank-Dumps und täglich über systemd-Timer ausgeführten, AES-256-verschlüsselten Restic-Offsite-Backups kombiniert.
qemu-guest-agent fsfreeze-Hooks, PostgreSQL 16 pg_dump -Fc, MariaDB 11 mariadb-dump --single-transaction und der Copy-on-Write-qcow2-Snapshot-Mechanik im Netcup SCP. VORAUSSETZUNGEN // ANFORDERUNGEN
CHECKLISTE- ✓ Ein Netcup VPS (z. B. VPS 500 G12.5 oder VPS 1000 G12.5) oder Root Server (z. B. RS 1000 G12.5) mit Ubuntu 24.04 LTS oder Debian 12
- ✓ Zugang zum Netcup Server Control Panel (SCP)
- ✓ Ein externer S3-kompatibler Bucket (Backblaze B2, Cloudflare R2, AWS S3) oder eine SFTP Storage Box für verschlüsselte Offsite-Restic-Repositories
Wichtige Erkenntnisse (Key Takeaways)
KURZFAZIT-
01 Verstehen Sie die Copy-on-Write-(CoW)-Mechanik im Netcup SCP: SCP-Snapshots benötigen freien, nicht zugewiesenen Speicherplatz innerhalb Ihrer Disk-Slice und liegen auf demselben Host-Storage-Pool – nutzen Sie sie für kurzfristige Rollbacks vor Upgrades (
< 72 Stunden), nicht als Langzeitarchiv. -
02 Installieren und aktivieren Sie
qemu-guest-agent, damit Online-SCP-Snapshots perfsfreezedie Dateisystempuffer des Kernels vor dem Snapshot sauber auf die Platte schreiben. -
03 Sichern Sie niemals laufende
/var/lib/postgresql/data- oder/var/lib/mysql-Verzeichnisse direkt auf Dateiebene; führen Sie stattdessen in einem Pre-Backup-Hook zunächstpg_dump -Fcbzw.mariadb-dump --single-transactionaus. -
04 Nutzen Sie Restic (
AES-256-CTR+Poly1305-AESClient-seitige Verschlüsselung und inhaltsbasierte Chunk-Deduplizierung), um tägliche Backups auf ein unabhängiges Offsite-S3- oder SFTP-Ziel zu übertragen. -
05 Ersetzen Sie fehleranfällige Cronjobs durch ein gehärtetes
systemd-.service- und.timer-Paar mit niedriger I/O-Priorität (IOSchedulingClass=idle) und automatischer Integritätsprüfung (restic check --read-data-subset=5%).
📑 Inhaltsverzeichnis (5 Abschnitte) ▼
- 01 Schritt 1: Netcup SCP Copy-on-Write (CoW) Snapshots & qemu-guest-agent-Quiescing beherrschen
- 02 Schritt 2: Restic installieren & ein AES-256-verschlüsseltes Offsite-Repository initialisieren
- 03 Schritt 3: Skript für atomare Pre-Backup-Datenbank-Dumps & Restic-Orchestrierung erstellen
- 04 Schritt 4: Tägliche Ausführung mit systemd-Timern & niedriger CPU/IO-Priorität automatisieren
- 05 Schritt 5: Live-Restore-Drill durchführen (Dateien, Volumes & PostgreSQL-Datenbank)
Schritt 1: Netcup SCP Copy-on-Write (CoW) Snapshots & qemu-guest-agent-Quiescing beherrschen
Im Netcup Server Control Panel (SCP) können Sie unter dem Reiter Snapshots entweder einen Online-Snapshot (während die VM weiterläuft) oder einen Offline-Snapshot (der die VM sauber herunterfährt, das Block-Image sichert und die VM wieder startet) auslösen.
Technisch besteht ein wesentlicher Unterschied zwischen einem bloß absturzkonsistenten (crash-consistent) und einem dateisystemkonsistenten (filesystem-consistent) Online-Snapshot: Ist qemu-guest-agent im Gastsystem aktiv, sendet der Netcup-KVM-Hypervisor vor dem Anlegen der Snapshot-Zeiger über den VirtIO-Seriell-Kanal (/dev/virtio-ports/org.qemu.guest_agent.0) das Signal guest-fsfreeze-freeze. Der Linux-Kernel leert daraufhin über den FIFREEZE-ioctl sämtliche schmutzigen Page-Cache-Puffer auf die virtuelle Disk und blockiert für wenige Millisekunden neue Schreibsystemaufrufe, bis der Snapshot atomar erstellt und per guest-fsfreeze-thaw wieder freigegeben wurde.
Da das KVM-Storage von Netcup mit Copy-on-Write-(CoW)-Block-Tracking arbeitet, friert ein Snapshot die aktuellen Basisblöcke schreibgeschützt ein und schreibt alle nachfolgenden Festplattenänderungen in ein Delta-Layer innerhalb Ihres zugewiesenen Speicherkontingents. Ist Ihre 256 GB große Root-Server-Festplatte bereits zu 90 % belegt (230 GB genutzt), verweigert das SCP die Snapshot-Erstellung – oder schlimmer noch: Eine hohe Schreiblast bei aktivem Snapshot schöpft die verbleibenden 26 GB CoW-Reserve binnen kurzer Zeit vollständig aus.
| Backup-Attribut | Netcup SCP Snapshot (Online / Offline) | Verschlüsseltes Offsite-Restic-Repository |
|---|---|---|
| Speicherort | Derselbe Netcup-Hypervisor-Storage-Pool (Lokales CoW) | Unabhängige Offsite-Cloud (S3, B2, R2, SFTP Storage Box) |
| Einfluss auf Disk-Quota | Verbraucht freien Speicherplatz innerhalb Ihrer VM-Zuweisung | Null dauerhaft belegter lokaler Speicherplatz |
| Primärer Einsatzzweck | Sofortiges 60-Sekunden-Rollback vor apt full-upgrade oder Kernel-Update | Tägliches automatisiertes Disaster Recovery (30–180+ Tage Aufbewahrung) |
| Granularer Datei-/Tabellen-Restore | Nein (Stellt komplettes Block-Image wieder her oder exportiert Raw-Image) | Ja (restic restore --include /opt/stacks/prod-web/.env) |
| Schutz bei Ransomware / Root-Kompromittierung | Angreifer mit SCP-Zugang kann Snapshots löschen | Unveränderlicher S3 Object Lock (COMPLIANCE / GOVERNANCE) möglich |
# 1. qemu-guest-agent installieren und aktivieren, damit das SCP bei Online-Snapshots fsfreeze ausführen kann
sudo apt update && sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
sudo systemctl status qemu-guest-agent --no-pager
# 2. Dateisystem-Belegung prüfen und ungenutzte Blöcke per fstrim freigeben, um CoW-Snapshots kompakt zu halten
df -h /
sudo fstrim -av Befehlserklärung: Stellt sicher, dass qemu-guest-agent für dateisystemkonsistente Online-SCP-Snapshots aktiv ist, und führt fstrim -av aus, damit gelöschte Blöcke vor dem Snapshot an das Thin-Provisioning-Storage zurückgegeben werden.
Active: active (running)
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 252G 41G 201G 17% /
/: 198.4 GiB (213031256064 bytes) trimmed on /dev/vda1 Lassen Sie einen SCP Copy-on-Write-Snapshot auf einem schreibintensiven Datenbankserver niemals wochenlang bestehen. Da jeder geänderte 4-KiB-Block vom eingefrorenen Snapshot-Zustand abweicht, wächst das CoW-Delta kontinuierlich an. Sobald Ihr OS-Upgrade oder Ihre Migration erfolgreich getestet ist, löschen Sie den temporären SCP-Snapshot und nutzen Sie Restic für die langfristige Historie.
Schritt 2: Restic installieren & ein AES-256-verschlüsseltes Offsite-Repository initialisieren
Restic ist ein statisch kompiliertes Go-Backup-Werkzeug, das nach dem Grundsatz „Cryptography First“ entwickelt wurde: Jede Datei wird über Rabin-Fingerprints in inhaltsdefinierte Chunks (zwischen 512 KiB und 8 MiB) zerlegt, mit Zstandard (zstd) komprimiert und noch auf Ihrem Netcup-Server mittels AES-256-CTR sowie Poly1305-AES authentifiziert verschlüsselt, bevor auch nur ein einziges Byte Ihre Netzwerkschnittstelle verlässt.
Durch das Content-Defined Chunking (CDC) über ein gleitendes 64-Byte-Rabin-Polynomfenster erkennt Restic verschobene Datenblöcke selbst dann wieder, wenn in einer mehrere Gigabyte großen Datenbank-Dump-Datei am Dateianfang neue Zeilen eingefügt wurden. Es werden ausschließlich die tatsächlich veränderten Daten-Chunks über das Netzwerk zum S3- oder SFTP-Speicher übertragen. Installieren Sie Restic, führen Sie restic self-update aus und legen Sie /etc/restic/backup.env inklusive GOGC=20 zur Begrenzung des Go-Heap-Speicherbedarfs mit strikten 0400-Rechten an.
# 1. Restic installieren und auf das neueste offizielle Binary aktualisieren
sudo apt update && sudo apt install -y restic bzip2 postgresql-client
sudo restic self-update
# 2. Root-exklusives Konfigurations- und Dump-Verzeichnis anlegen
sudo mkdir -p /etc/restic /var/backups/db-dumps
sudo chmod 0700 /etc/restic /var/backups/db-dumps
# 3. Kryptografisch starkes 48-Byte-Repository-Passwort generieren
openssl rand -base64 48 | sudo tee /etc/restic/repo.pw > /dev/null
sudo chmod 0400 /etc/restic/repo.pw
# 4. Offsite-S3- (oder SFTP-) Zugangsdaten und Go-Speicherlimit konfigurieren
sudo tee /etc/restic/backup.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/netcup-prod-backups/rs1000-nue"
export RESTIC_PASSWORD_FILE="/etc/restic/repo.pw"
export AWS_ACCESS_KEY_ID="YOUR_S3_KEY_ID"
export AWS_SECRET_ACCESS_KEY="YOUR_S3_APPLICATION_KEY"
export RESTIC_COMPRESSION="auto"
export GOGC=20
EOF
sudo chmod 0400 /etc/restic/backup.env
# 5. Verschlüsseltes Offsite-Restic-Repository initialisieren
sudo bash -c 'source /etc/restic/backup.env && restic init' Befehlserklärung: Installiert Restic, aktualisiert das Binary auf die neueste Version, generiert eine dedizierte Schlüsseldatei /etc/restic/repo.pw, konfiguriert die S3-Zugangsdaten in /etc/restic/backup.env und initialisiert das entfernte verschlüsselte Repository.
created restic repository 9c4e18f2a0 at s3:https://s3.eu-central-003.backblazeb2.com/netcup-prod-backups/rs1000-nue SICHERHEITSHINWEIS: Kopieren Sie den Inhalt von /etc/restic/repo.pw (sudo cat /etc/restic/repo.pw) sofort in Ihren externen Passwort-Tresor (Bitwarden / 1Password / KeePassXC). Wenn Ihr Netcup-Server komplett ausfällt und repo.pw ausschließlich auf dem Server selbst lag, sind Ihre Offsite-Backups mathematisch nicht wiederherstellbar.
Schritt 3: Skript für atomare Pre-Backup-Datenbank-Dumps & Restic-Orchestrierung erstellen
Das direkte Sichern roher Datenbank-Binärdateien (/var/lib/docker/volumes/.../pgdata), während PostgreSQL oder MariaDB aktiv WAL-/Redo-Logs schreiben, erzeugt inkonsistente Backups („Torn Pages“), die beim Restore mit korrupten B-Tree-Indizes fehlschlagen. Erstellen Sie stattdessen ein zentrales Backup-Skript (/usr/local/sbin/netcup-restic-backup), das zunächst transaktionskonsistente logische Abzüge unter /var/backups/db-dumps mittels pg_dump -Fc erzeugt und anschließend restic backup über /etc, /opt/stacks und /var/backups/db-dumps ausführt.
Da pg_dump mit MVCC-Snapshot-Isolation arbeitet, sieht der Export exakt den konsistenten Datenbankzustand zum Startzeitpunkt des Dumps, ohne laufende Schreibtransaktionen Ihrer Webanwendung zu sperren. Wir schreiben den Dump zunächst in eine temporäre Datei (.pgdump.tmp) und benennen diese erst nach erfolgreichem Abschluss atomar per mv um, damit ein abgebrochener Dump niemals den vorherigen intakten Stand überschreibt.
sudo tee /usr/local/sbin/netcup-restic-backup > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
# Überlappende Backup-Läufe per Kernel-File-Lock (flock) verhindern
LOCKFILE="/var/run/netcup-restic-backup.lock"
exec 9>"${LOCKFILE}"
if ! flock -n 9; then
echo "Another backup process is currently running. Exiting."
exit 1
fi
source /etc/restic/backup.env
DUMP_DIR="/var/backups/db-dumps"
mkdir -p "${DUMP_DIR}"
chmod 0700 "${DUMP_DIR}"
echo "==> [1/4] Dumping running Docker PostgreSQL & MariaDB databases atomically..."
# Alle laufenden Postgres-Container konsistent im Custom-Format sichern
for PG_CONTAINER in $(docker ps --filter "ancestor=postgres:16.4-alpine3.20" --format "{{.Names}}"); do
echo " -> Dumping PostgreSQL container: ${PG_CONTAINER}"
PG_USER=$(docker inspect "${PG_CONTAINER}" --format '{{range .Config.Env}}{{println .}}{{end}}' | awk -F= '/^POSTGRES_USER=/ {print $2}')
PG_DB=$(docker inspect "${PG_CONTAINER}" --format '{{range .Config.Env}}{{println .}}{{end}}' | awk -F= '/^POSTGRES_DB=/ {print $2}')
docker exec "${PG_CONTAINER}" pg_dump -U "${PG_USER:-postgres}" -d "${PG_DB:-postgres}" -Fc --Z=1 \
> "${DUMP_DIR}/${PG_CONTAINER}_${PG_DB}.pgdump.tmp"
mv "${DUMP_DIR}/${PG_CONTAINER}_${PG_DB}.pgdump.tmp" "${DUMP_DIR}/${PG_CONTAINER}_${PG_DB}.pgdump"
done
echo "==> [2/4] Executing encrypted Restic backup to off-site repository..."
restic backup \
/etc \
/opt/stacks \
/var/backups/db-dumps \
/home \
/root \
--tag "automated-daily" \
--exclude="/var/lib/docker/overlay2" \
--exclude="**/node_modules" \
--exclude="**/.cache" \
--exclude="**/*.log" \
--one-file-system
echo "==> [3/4] Applying GFS retention policy (7 daily, 4 weekly, 6 monthly)..."
restic forget \
--tag "automated-daily" \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--prune
echo "==> [4/4] Verifying repository structure and 5% random data pack subset..."
restic check --read-data-subset=5%
echo "==> Backup & verification completed successfully at $(date -u +"%Y-%m-%dT%H:%M:%SZ")"
EOF
sudo chmod 0700 /usr/local/sbin/netcup-restic-backup Befehlserklärung: Setzt einen exklusiven Kernel-File-Lock (flock), sichert laufende PostgreSQL-Container im Custom-Format (-Fc), führt das deduplizierte restic backup aus, wendet die GFS-Aufbewahrungsrichtlinie (7d/4w/6m) an und überprüft bei jedem Lauf 5 % der entfernten Datenpakete auf Integrität.
Schritt 4: Tägliche Ausführung mit systemd-Timern & niedriger CPU/IO-Priorität automatisieren
Im Gegensatz zu klassischen /etc/crontab-Einträgen erlaubt uns eine systemd-Service-Unit, Restic mit niedrigster CPU-Priorität (Nice=19) und im Idle-Block-I/O-Modus (IOSchedulingClass=idle) auszuführen. Dadurch beeinträchtigen Verschlüsselung und Zstd-Komprimierung zu keinem Zeitpunkt die Antwortzeiten Ihrer produktiven PostgreSQL-Datenbank oder Webanwendung.
Zusätzlich sorgt RandomizedDelaySec=1800 in der .timer-Unit dafür, dass bei einer Flotte aus mehreren Netcup-Servern nicht alle Knoten exakt um 03:15:00 Uhr gleichzeitig ihren S3-Bucket oder Ihre SFTP-Storage-Box belasten. Mit Persistent=true holt systemd einen verpassten Backup-Lauf nach einer nächtlichen Wartung sofort nach dem Booten automatisch nach.
# /etc/systemd/system/restic-backup.service
[Unit]
Description=Encrypted Off-Site Restic Backup & DB Dump for Netcup Server
After=network-online.target docker.service
Wants=network-online.target
[Service]
Type=oneshot
User=root
Nice=19
IOSchedulingClass=idle
IOSchedulingPriority=7
ExecStart=/usr/local/sbin/netcup-restic-backup
StandardOutput=journal
StandardError=journal Befehlserklärung: Führt /usr/local/sbin/netcup-restic-backup mit Idle-I/O-Priorität (IOSchedulingClass=idle) und niedriger CPU-Priorität (Nice=19) aus, damit der Live-Traffic während nächtlicher Backups keinerlei Latenzspitzen erfährt.
sudo tee /etc/systemd/system/restic-backup.timer > /dev/null <<'EOF'
[Unit]
Description=Run Netcup Restic Backup Daily at 03:15 AM with Randomized Jitter
[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=1800
Persistent=true
[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
# Sofortigen Testlauf starten und systemd-Journal-Ausgabe prüfen
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -n 40 --no-pager
sudo systemctl list-timers restic-backup.timer Befehlserklärung: Plant das Backup täglich um 03:15 Uhr mit bis zu 30 Minuten zufälliger Verzögerung (RandomizedDelaySec=1800), startet sofort das erste Vollbackup und prüft den nächsten geplanten Ausführungszeitpunkt.
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2026-11-05 03:28:14 CET 6h left Wed 2026-11-04 20:45:10 CET 12s ago restic-backup.timer restic-backup.service Schritt 5: Live-Restore-Drill durchführen (Dateien, Volumes & PostgreSQL-Datenbank)
Ein Backup-System, dessen Wiederherstellung noch nie unter realen Bedingungen geprobt wurde, bietet im Ernstfall nur trügerische Sicherheit. Führen Sie einmal pro Quartal einen 10-minütigen Restore-Drill durch, um zu verifizieren, dass Sie Snapshots auflisten, gezielt Konfigurationsdateien in ein Staging-Verzeichnis (/tmp/restore-drill) extrahieren und das .pgdump-Archiv per pg_restore validieren können.
Prüfen Sie beim Restore-Drill insbesondere, dass sowohl das Repository-Passwort aus Ihrem Passwort-Manager als auch das Einspielen des PostgreSQL-Dumps in einen frischen Test-Container fehlerfrei funktionieren. Mit pg_restore --list lesen Sie den kompletten Katalog aller gesicherten Tabellen, Sequenzen und Indizes direkt aus dem wiederhergestellten Dump aus.
# 1. Alle verschlüsselten Snapshots im entfernten Repository auflisten
sudo bash -c 'source /etc/restic/backup.env && restic snapshots'
# 2. /opt/stacks und /var/backups/db-dumps aus dem neuesten Snapshot nach /tmp/restore-drill extrahieren
sudo mkdir -p /tmp/restore-drill
sudo bash -c 'source /etc/restic/backup.env && restic restore latest --target /tmp/restore-drill --include /opt/stacks --include /var/backups/db-dumps'
# 3. Integrität des wiederhergestellten PostgreSQL-Custom-Dumps prüfen (Inhaltsverzeichnis)
pg_restore --list /tmp/restore-drill/var/backups/db-dumps/*.pgdump | head -n 20
# 4. Temporäres Restore-Drill-Verzeichnis wieder entfernen
sudo rm -rf /tmp/restore-drill Befehlserklärung: Fragt das entfernte Repository nach Snapshot-IDs ab, stellt selektiv /opt/stacks und /var/backups/db-dumps unter /tmp/restore-drill wieder her und prüft das Inhaltsverzeichnis des PostgreSQL-Archivs über pg_restore --list.
ID Time Host Tags Paths
------------------------------------------------------------------------------------
a81f39c2 2026-11-04 20:45:02 netcup-rs1 automated-daily /etc, /opt/stacks, /var/backups/db-dumps
; Archive created at 2026-11-04 20:45:00 UTC
; dbname: prod_app
; TOC Entries: 48 Häufige Fehlerbehebung
DIAGNOSE-GUIDE [SYMPTOM] Fatal: unable to create lock in backend: repository is already locked by PID ...
Ursache: Ein vorheriger restic backup- oder restic prune-Lauf wurde durch einen Server-Reboot oder einen Netzwerkabbruch unterbrochen, sodass ein veraltetes Lock-Objekt im S3/SFTP-Repository zurückgeblieben ist.
Lösung: Stellen Sie sicher, dass aktuell kein Backup-Prozess läuft (ps aux | grep restic), und entfernen Sie das verwaiste Lock anschließend mit sudo bash -c "source /etc/restic/backup.env && restic unlock".
[SYMPTOM] Erstellung eines Netcup SCP Snapshots schlägt fehl mit Not enough free disk space on storage
Ursache: Netcup Copy-on-Write-Snapshots benötigen ausreichend freie, nicht zugewiesene Blöcke innerhalb Ihrer virtuellen Festplatten-Slice, um abweichende Schreibvorgänge zu speichern.
Lösung: Löschen Sie ältere SCP-Snapshots im SCP, bereinigen Sie ungenutzte Docker-Daten (docker system prune -af --volumes) bzw. Logs (journalctl --vacuum-size=200M) und führen Sie im Linux-Gast zwingend sudo fstrim -av aus.
[SYMPTOM] Restic-Backup belegt auf einem kleineren Netcup VPS 500 G12.5 oder VPS 1000 G12.5 über 1,5 GB RAM
Ursache: Beim Scannen von Millionen kleiner Dateien tauscht der Go-Garbage-Collector (GOGC=100) standardmäßig höheren Speicherverbrauch gegen geringere CPU-Last.
Lösung: Fügen Sie export GOGC=20 und export GOMAXPROCS=2 in /etc/restic/backup.env hinzu. Dadurch gibt die Go-Laufzeitumgebung Speicher deutlich aggressiver frei und senkt den Spitzen-RAM-Verbrauch von Restic um 60–70 %.
[SYMPTOM] Wiederhergestellte PostgreSQL-Datenbank meldet role does not exist oder Berechtigungsfehler
Ursache: pg_restore versucht standardmäßig, die ursprünglichen Rollen-Eigentümer wiederherzustellen, was in einem neu erstellten Container mit abweichendem Benutzernamen fehlschlägt.
Lösung: Übergeben Sie --no-owner --no-privileges --clean --if-exists an pg_restore: docker exec -i prod_web_postgres pg_restore -U prod_user -d prod_app --clean --if-exists --no-owner < backup.pgdump.
Häufig gestellte Fragen (FAQ)
GEPRÜFTE ANTWORTENKann ich ein vollständiges Netcup SCP Snapshot-Image auf mein lokales NAS oder meine Workstation herunterladen?
Ja. Wenn Sie im Netcup Server Control Panel (SCP) einen Offline-Snapshot erstellen, bietet Netcup die Option Export Snapshot an, über die Sie das rohe Disk-Image per HTTPS herunterladen können. Alternativ können Sie das Netcup Rescue System booten und das Block-Device komprimiert per SSH streamen (ssh root@server "dd if=/dev/vda bs=16M | zstd -T0" > netcup-disk.img.zst).
Welches ist das günstigste und schnellste Offsite-Speicherziel für Restic-Backups von Netcup Nürnberg oder Wien aus?
Für europäische Netcup-Server (NUE, VIE, AMS) bieten Backblaze B2 EU Central (Amsterdam), Cloudflare R2 (EU-Jurisdiktion) oder eine Hetzner Storage Box (SFTP/Restic) in Falkenstein/Helsinki Latenzen unter 15 ms bei sehr geringen monatlichen Speicherkosten pro TB (auf R2 zudem komplett ohne Egress-Gebühren).
Wie kann ich ein Restic-Backup-Repository als durchsuchbares Linux-Verzeichnis einbinden (mounten)?
Installieren Sie fuse3 (sudo apt install -y fuse3), legen Sie einen Mountpoint an (sudo mkdir -p /mnt/restic) und führen Sie sudo bash -c "source /etc/restic/backup.env && restic mount /mnt/restic" aus. Danach können Sie per cd /mnt/restic/snapshots/latest jede beliebige historische Datei mit normalen Linux-Befehlen wie ls oder cp durchsuchen und herauskopieren.
Warum haben wir /var/lib/docker/overlay2 vom Restic-Backup ausgeschlossen?
/var/lib/docker/overlay2 enthält lediglich schreibgeschützte Container-Image-Layer, die jederzeit neu aus Docker Hub oder GHCR geladen werden können. Deren Sicherung würde unnötig viele Gigabyte an Bandbreite und Speicherplatz verbrauchen. Sichern Sie stattdessen immer /opt/stacks, benannte Daten-Volumes sowie die atomaren Datenbank-Dumps unter /var/backups/db-dumps.
QUELLEN // GEPRÜFTE TECHNISCHE DOKUMENTATION
- [1] Restic Offizielle Dokumentation — Neues Repository vorbereiten & sichern (https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html)
- [2] PostgreSQL 16 Dokumentation — Backup und Restore (pg_dump & pg_restore) (https://www.postgresql.org/docs/16/backup-dump.html)
- [3] QEMU Guest Agent Protokoll & Filesystem-Freeze-Referenz (https://www.qemu.org/docs/master/interop/qemu-ga.html)