Der zuverlässige Weg, einen Linux-Server in 2026 zu sichern, ist die 3-2-1-Regel: Halten Sie drei Kopien Ihrer Daten vor, auf zwei Arten von Speicher, mit einer Kopie off-site, verschlüsselt und automatisiert, damit Sie nie daran denken müssen. Für einen einzelnen VPS ist der kürzeste Weg, der tatsächlich funktioniert, restic, das nächtliche, verschlüsselte, deduplizierte Snapshots auf günstigen Object Storage wie Backblaze B2 oder eine Hetzner Storage Box schickt, mit einem Datenbank-Dump, der zuvor läuft. Der Teil, den fast jeder überspringt und der einzige Teil, der an dem Tag zählt, an dem eine Platte ausfällt, ist das Testen der Wiederherstellung. Dieser Leitfaden geht die ganze Sache von Anfang bis Ende durch: ein Werkzeug wählen, Snapshots off-site verschicken, Datenbanken und Docker handhaben, das Ganze automatisieren und beweisen, dass es sich wiederherstellen lässt.
Was "einen Linux-Server sichern" tatsächlich bedeutet
Ein Backup ist kein Snapshot. Der tägliche VPS-Snapshot Ihres Hosts liegt beim selben Anbieter, oft im selben Rack, und verschwindet, wenn Ihr Konto gesperrt wird oder die Region einen schlechten Tag hat. Ein echtes Backup ist eine separate, off-site liegende Kopie, die Sie kontrollieren. Es gibt zwei Ebenen, die es zu schützen lohnt: Ihre Daten (Datenbanken, /home, App-Volumes, /etc-Konfigurationen) und optional ein vollständiges Systemabbild für die Bare-Metal-Wiederherstellung. Für die meisten Einzelserver-Setups brauchen Sie kein vollständiges Festplatten-Image – ein neu aufgesetzter VPS mit darauf wiederhergestellten Daten ist schneller und günstiger. Was Sie niemals verlieren dürfen, sind die Daten, und genau darauf zielt das folgende Setup ab. Das Leitprinzip quer durch jeden glaubwürdigen Leitfaden für 2026 ist dasselbe: die 3-2-1-Regel – drei Kopien, zwei Speichermedien, eine off-site. Alles andere ist Umsetzungsdetail.
Die 3-2-1-Regel, angewendet auf einen einzelnen VPS
Auf einer einzelnen Maschine lässt sich die Regel sauber abbilden. Kopie 1 sind Ihre Live-Daten auf der Serverfestplatte. Kopie 2 ist ein lokaler Snapshot auf einem zweiten Volume oder der Block-Storage-Snapshot Ihres Anbieters – sofort wiederherstellbar, nutzlos, wenn das Konto stirbt. Kopie 3 ist eine verschlüsselte off-site liegende Kopie auf Object Storage oder einer Storage Box in einem anderen Unternehmen und Land. Diese dritte Kopie ist diejenige, die einen Ransomware-Angriff, ein versehentliches rm -rf oder das Schließen Ihres Kontos durch einen Anbieter ohne Vorwarnung überlebt. Verschlüsseln Sie sie, bevor sie die Maschine verlässt, damit der Speicheranbieter niemals Klartext sieht, und automatisieren Sie sie, damit sie läuft, ob Sie daran denken oder nicht. Wenn Sie nach der Lektüre nur eine Sache umsetzen, richten Sie Kopie 3 ein. Zwei lokale Kopien ohne Off-site-Kopie sind die häufigste Art, wie Leute – zu spät – feststellen, dass sie überhaupt kein Backup hatten.
Welches Linux-Backup-Werkzeug sollten Sie verwenden?
Das Feld verengt sich auf eine Handvoll Werkzeuge, und die richtige Wahl hängt davon ab, ob Sie einfaches Dateimirroring oder verschlüsselte, deduplizierte, Cloud-native Snapshots wollen. Für einen VPS, dessen Off-site-Ziel Object Storage ist, ist restic die pragmatische Standardwahl: Es verschlüsselt und dedupliziert von Haus aus und spricht ohne zusätzliche Werkzeuge mit S3, Backblaze B2, Azure, Google Cloud und SFTP. BorgBackup ist sein engster Rivale, mit exzellenter Kompression und Deduplizierung, benötigt aber ein Borg-fähiges Ziel (SSH oder eine Storage Box) statt reinem S3.
| Werkzeug | Verschlüsselung | Dedup | Off-site-Ziel | Am besten für |
|---|---|---|---|---|
| restic | Integriert (AES) | Ja | S3, B2, Azure, GCS, SFTP | VPS → Object Storage |
| BorgBackup | Integriert (AES-256) | Ja | SSH / Storage Box | Server mit einem SSH-Backup-Host |
| rsync | Nein (SSH-Transport nutzen) | Nein | Beliebiges SSH/NAS-Ziel | Einfache Datei-Spiegel |
| Timeshift | Nein | Snapshots | Lokal / gleiche Platte | Desktop-artiges System-Rollback |
| Veeam / Bacula | Ja | Ja | Enterprise-Repositories | Flotten, Bare-Metal, Compliance |
rsync ist nach wie vor perfekt für einen schnellen Spiegel auf ein NAS, hat aber für sich genommen keine Verschlüsselung und keine Historie – der Fehler von gestern überschreibt die gute Kopie von heute. Für einen einzelnen Server, der in die Cloud gesichert wird, gewinnt restic mit den wenigsten beweglichen Teilen.
Das schnellste zuverlässige Setup: restic auf off-site Object Storage
Hier ist die gesamte Off-site-Ebene für einen Ubuntu- oder Debian-VPS. Erstellen Sie einen Backblaze-B2-Bucket mit einem Application Key, dann installieren und initialisieren Sie ein verschlüsseltes restic-Repository:
sudo apt install restic # or: dnf install restic
export RESTIC_REPOSITORY="s3:s3.us-west-004.backblazeb2.com/your-bucket"
export AWS_ACCESS_KEY_ID="<b2-keyID>"
export AWS_SECRET_ACCESS_KEY="<b2-applicationKey>"
export RESTIC_PASSWORD="<a-long-random-passphrase>" # store this OFF the server
restic init
Dann sichert ein einziger Befehl Ihre wichtigen Pfade, verschlüsselt und dedupliziert, bevor irgendetwas die Maschine verlässt:
restic backup /etc /home /var/www /srv --exclude /var/www/cache
Führen Sie ihn zweimal aus, und der zweite Durchlauf ist in Sekunden fertig – restic lädt nur geänderte Chunks hoch. Speichern Sie RESTIC_PASSWORD irgendwo abseits des Servers (ein Passwortmanager); ohne es ist das Repository per Design nicht wiederherstellbar, was genau die Eigenschaft ist, die es in der Cloud eines anderen sicher macht. Das ist das Muster, zu dem wir auf unserer eigenen Infrastruktur greifen: Wir betreiben TechRiseUps über WaseerHost, und ein verschlüsseltes Off-site-Repository wie dieses ist das Sicherheitsnetz hinter jeder Maschine.
Vergessen Sie Datenbanken und Docker-Volumes nicht
Hier scheitern die meisten dateibasierten Backups still und leise. Das Verzeichnis mit den Daten einer laufenden Datenbank zu kopieren, während darauf geschrieben wird, erzeugt eine beschädigte, nicht wiederherstellbare Datei. Dumpen Sie die Datenbank zuerst in eine flache Datei, dann lassen Sie restic den Dump aufnehmen. Für Postgres führen Sie pg_dump aus (oder pg_dumpall für jede Datenbank und die Rollen); für MySQL oder MariaDB mysqldump --single-transaction. Ein einzeiliger Pre-Backup-Schritt erledigt das:
pg_dumpall -U postgres | gzip > /srv/backups/db-$(date +%F).sql.gz
Docker fügt dieselbe Falle hinzu: Der wichtige Zustand liegt in benannten Volumes, nicht im Container. Dumpen Sie entweder die Datenbank innerhalb des Containers auf dieselbe Weise, oder halten Sie den Stack kurz mit docker compose down an, sichern Sie das Volume-Verzeichnis und fahren Sie ihn wieder hoch. Wenn Sie eine zustandsbehaftete App selbst hosten, geht unser Leitfaden zum Selbst-Hosten von Supabase durch, welche Postgres- und Storage-Pfade tatsächlich Schutz benötigen. Die Regel ist einfach: Sichern Sie eine konsistente Kopie, niemals eine laufende.
Automatisieren Sie es: ein nächtlicher systemd-Timer
Ein Backup, das Sie von Hand ausführen, ist ein Backup, das Sie vergessen werden. Verpacken Sie die Dump-plus-restic-Sequenz in ein kleines Skript und steuern Sie es mit einem systemd-Timer (sauberer als cron, mit Logs in journalctl). Erstellen Sie /etc/systemd/system/backup.service, der auf Ihr Skript zeigt, dann einen Timer:
# /etc/systemd/system/backup.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
[Install]
WantedBy=timers.target
Aktivieren Sie ihn mit systemctl enable --now backup.timer. Fügen Sie eine Aufbewahrung hinzu, damit das Repository nicht ewig wächst – die forget/prune-Policy von restic behält eine sinnvolle Staffelung und löscht den Rest:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Persistent=true ist wichtig: Wenn der Server um 03:30 aus war, läuft der Job beim nächsten Boot, statt ihn stillschweigend zu überspringen. Kombinieren Sie das mit einem abgeriegelten Server – unser Leitfaden zur sicheren ersten Stunde eines VPS behandelt die Firewall und das SSH-Hardening, die verhindern, dass der Backup-Host selbst zur Sicherheitslücke wird.
Was Off-site-Backups in 2026 tatsächlich kosten
Off-site-Backup ist eine der günstigsten Versicherungspolicen der Tech-Welt. Object Storage wird pro Gigabyte abgerechnet, und ein typischer VPS hält nach Deduplizierung und Kompression nur ein paar Dutzend Gigabyte echter Daten.
| Option | Preis (2026) | Egress | Anmerkungen |
|---|---|---|---|
| Backblaze B2 | $6.95 / TB / mo | Kostenlos bis zum 3× des Gespeicherten, danach $0.01/GB | Erste 10 GB kostenlos; natives restic-Ziel |
| Hetzner Storage Box | Ein paar Euro / Monat für 1 TB | Inklusive | BorgBackup + rsync über SSH |
| AWS S3 | ~$23 / TB / mo | $0.09/GB | Egress summiert sich beim Restore schnell |
Für einen Server mit 30 GB deduplizierten Snapshots kostet Backblaze B2 deutlich unter einem Dollar pro Monat, und weil B2 kostenlosen Egress bis zum Dreifachen Ihrer gespeicherten Größe gewährt, kostet ein vollständiger Restore meist nichts. Das ist die Zahl, die man gegen die Alternative abwägen sollte: eine verlorene Datenbank aus dem Gedächtnis wiederaufzubauen. Wenn Sie Ihren gesamten Stack kostentechnisch feinjustieren, treibt dieselbe "Behalte den Egress im Auge"-Logik unsere Aufschlüsselung der Cloud-Egress-Gebühren an.
Testen Sie die Wiederherstellung – der Schritt, den jeder überspringt
Ein ungetestetes Backup ist eine Hoffnung, kein Backup. Die einzige Möglichkeit, zu wissen, dass Ihr Setup funktioniert, ist die Wiederherstellung, bevor Sie sie brauchen. Mit restic prüfen Sie die Integrität des Repositories und stellen dann einen Snapshot in ein Scratch-Verzeichnis wieder her:
restic check # verify repository integrity
restic snapshots # list what you have
restic restore latest --target /tmp/restore-test
Vergleichen Sie die wiederhergestellten Dateien mit den Originalen, bestätigen Sie, dass ein Datenbank-Dump tatsächlich in eine Wegwerf-Datenbank importiert, und löschen Sie dann die Scratch-Kopie. Machen Sie das an dem Tag, an dem Sie es einrichten, und erneut jedes Mal, wenn Sie ändern, was Sie sichern. Sie können auch restic mount /mnt/restic verwenden, um Snapshots wie ein normales Dateisystem zu durchsuchen und eine einzelne Datei zurückzuholen. Tragen Sie einen Restore-Test jedes Quartal in den Kalender ein. Der Fehlerfall, der Unternehmen erledigt, ist nicht "wir hatten keine Backups"; es ist "wir hatten Backups, und keines davon ließ sich wiederherstellen."
Häufig gestellte Fragen
Was ist das beste Backup-Werkzeug für Linux?
Für einen einzelnen Server, der in die Cloud gesichert wird, ist restic in 2026 der beste Standard: Es verschlüsselt und dedupliziert automatisch und schreibt direkt nach S3, Backblaze B2 oder SFTP. BorgBackup ist eine ebenso starke Wahl, wenn Ihr Ziel ein SSH-Host oder eine Hetzner Storage Box ist. Verwenden Sie rsync nur für einfache Spiegel, bei denen Sie keine Verschlüsselung oder Historie benötigen.
Wie sichere ich einen ganzen Ubuntu-Server?
Sichern Sie Ihre Daten (in Dateien gedumpte Datenbanken plus /etc, /home und App-Verzeichnisse) mit restic oder Borg in ein Off-site-Repository und automatisieren Sie das mit einem systemd-Timer. Ein vollständiges Bare-Metal-Image lohnt sich für einen VPS selten – das Betriebssystem neu aufzusetzen und die Daten darauf wiederherzustellen ist schneller. Wenn Sie doch ein vollständiges Image wollen, decken Werkzeuge wie Timeshift oder ein Anbieter-Snapshot die Systemebene ab.
Wie sichere ich einen Linux-Server auf ein NAS?
Richten Sie dieselben Werkzeuge auf das NAS statt auf die Cloud. rsync über SSH spiegelt Dateien auf einen exportierten Share; restic und Borg können über SFTP für verschlüsselte, versionierte Backups auf das NAS schreiben. Behandeln Sie das NAS als Kopie 2 (lokal) und behalten Sie trotzdem eine verschlüsselte Off-site-Kopie 3, denn ein Brand, ein Diebstahl oder ein Ransomware-Angriff nimmt das NAS und den Server zusammen.
Wie sichere ich einen ganzen Server für die Bare-Metal-Wiederherstellung?
Für die vollständige Systemwiederherstellung brauchen Sie ein Systemabbild, nicht nur Dateien. Clonezilla erstellt ein bootfähiges Disk-Image, und Veeam Agent for Linux oder Bacula übernehmen anwendungskonsistente Bare-Metal-Backups für Flotten. Für einen einzelnen VPS ist der pragmatische Weg, den Serveraufbau zu skripten (oder Coolify oder Ansible zu verwenden), sodass der Neuaufbau eine Fünf-Minuten-Angelegenheit ist, und dann Ihr Datenbackup darauf wiederherzustellen.
Sources
- Backblaze — B2 Cloud Storage pricing: $6.95/TB/month, kostenloser Egress bis zum 3× des Gespeicherten, danach $0.01/GB.
- Hetzner — Storage Box: 1 TB+ Boxen mit Unterstützung für BorgBackup und rsync über SSH.
- restic documentation: Verschlüsselung, Deduplizierung, unterstützte Backends und Snapshot-Handhabung.
- restic — Removing snapshots (forget/prune): Flags für die Aufbewahrungs-Policy.
- LinuxTeck — Best Linux Server Backup Solutions 2026: die 3-2-1-Regel und Werkzeugvergleich.
Waqas Ahmed Waseer
Waqas Ahmed Waseer ist Entwickler und Automation-Builder mit über 8 Jahren Erfahrung im Aufbau von Produktivsystemen, die von mehr als 100.000 Menschen genutzt werden. Er baut individuelle Multi-Tenant-SaaS, KI-Automatisierung (n8n, LLM-Workflows, WhatsApp-Bots) und Hosting-Infrastruktur (WHM/cPanel, CloudLinux) — und ist der Macher von WaSphere, FlowMaticX und der Hosting-Marke WaseerHost. Über 100 Projekte für KMU, Agenturen und finanzierte Start-ups umgesetzt.



