Cloud & Hosting

Linux-Server sichern in 2026: Das 3-2-1-Setup, das sich wirklich wiederherstellen lässt

So sichern Sie einen Linux-Server in 2026 zuverlässig: verschlüsselte, deduplizierte restic-Snapshots off-site auf günstigem Object Storage, Datenbank- und Docker-Handling, systemd-Automatisierung, echte Speicherkosten für 2026 und ein Restore-Test, der beweist, dass es funktioniert.

Waqas Ahmed Waseer
Waqas Ahmed Waseer 13. Juli 2026 9 Min. Lesezeit
Linux-Server sichern in 2026: Das 3-2-1-Setup, das sich wirklich wiederherstellen lässt

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.

WerkzeugVerschlüsselungDedupOff-site-ZielAm besten für
resticIntegriert (AES)JaS3, B2, Azure, GCS, SFTPVPS → Object Storage
BorgBackupIntegriert (AES-256)JaSSH / Storage BoxServer mit einem SSH-Backup-Host
rsyncNein (SSH-Transport nutzen)NeinBeliebiges SSH/NAS-ZielEinfache Datei-Spiegel
TimeshiftNeinSnapshotsLokal / gleiche PlatteDesktop-artiges System-Rollback
Veeam / BaculaJaJaEnterprise-RepositoriesFlotten, 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.

OptionPreis (2026)EgressAnmerkungen
Backblaze B2$6.95 / TB / moKostenlos bis zum 3× des Gespeicherten, danach $0.01/GBErste 10 GB kostenlos; natives restic-Ziel
Hetzner Storage BoxEin paar Euro / Monat für 1 TBInklusiveBorgBackup + rsync über SSH
AWS S3~$23 / TB / mo$0.09/GBEgress 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

Waqas Ahmed Waseer

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.

Ähnliche Beiträge

Mehr in Cloud & Hosting

Alle ansehen

Diskussion · 0

Bleib fair. Kommentare sind öffentlich.

    Newsletter · Montagsausgabe

    Der Montagsbrief.

    Eine E-Mail jeden Montagmorgen. Die kommende Woche in KI, Startups, Hosting und Dev-Tools — ohne Schnickschnack, ohne gesponserten Köder.

    Kostenlos. Abmeldung mit einem Klick.