3-2-1 Backup-Strategie für Server: Anleitung mit restic und echten Tests (2026)

Die 3-2-1 Backup-Strategie ist die einfachste Regel, die in der Datensicherung wirklich etwas taugt: Halte drei Kopien deiner Daten, auf zwei verschiedenen Speicherarten, und eine davon außer Haus. Mehr steckt nicht dahinter. Für einen Linux-Server heißt das in der Praxis: die Live-Daten auf dem Server, ein lokales Backup daneben, und ein zweites Backup an einem ganz anderen Ort, idealerweise bei einem anderen Anbieter.

Die Regel klingt so selbstverständlich, dass man sie gern abnickt und weitergeht. Genau deshalb haben wir sie am 7. Oktober 2026 auf unserem eigenen Server nicht nur erklärt, sondern nachgeprüft: mit restic eine echte Sicherung gebaut, sie über das Internet nach Helsinki geschoben, einen Verschlüsselungstrojaner simuliert und alles wiederhergestellt. Und wir haben gezählt, welche unserer eigenen Daten die Regel tatsächlich erfüllen. Drei Befunde vorweg:

1. Eine rsync --delete-Spiegelung ist kein Backup. In unserem Test hat sie 20 von 20 verschlüsselten Dateien brav auf das Ziel kopiert und die guten Fassungen dabei überschrieben. Ein Snapshot-Backup mit restic hat dieselbe Attacke unbeschadet überstanden.

2. Unser bestes Backup erfüllt 3-2-1 auf dem Papier, aber die externe Kopie kann vom Hauptserver aus gelöscht werden. Ein Angreifer mit root-Rechten erwischt also alle drei Kopien.

3. Der Quellcode genau dieses Blogs lag zum Zeitpunkt des Tests in keinem einzigen Backup. Nicht in Git, nicht extern, nirgends. Wir hätten es ohne diesen Artikel nicht gemerkt.

Was ist die 3-2-1 Backup-Strategie?

Die Regel wird meist dem Fotografen Peter Krogh zugeschrieben, der sie Mitte der 2000er-Jahre für die Sicherung digitaler Bildarchive formuliert hat. Sie hat sich durchgesetzt, weil sie sich in einem Satz merken lässt und trotzdem die drei häufigsten Ursachen für Datenverlust abdeckt:

Wichtig ist das Wort Kopie. Das Original zählt mit. Wer also „drei Kopien” hört und drei Backups macht, hat vier, und das schadet nicht. Wer dagegen nur ein Backup hat, hat zwei Kopien und ist damit eine Panne vom Verlust entfernt: Stirbt der Server, ist das Backup die letzte verbliebene Fassung, und genau dann stellt sich manchmal heraus, dass es seit Wochen nicht mehr gelaufen ist.

Warum drei und nicht zwei?

Zwei Kopien klingen nach Redundanz, sind aber in der Praxis fragil. Das Backup wird in der Regel genau dann gebraucht, wenn das Original kaputt ist. In diesem Moment gibt es nur noch eine Kopie, und jeder Fehler beim Wiederherstellen (falsches Passwort, beschädigte Datei, versehentlich überschrieben) ist endgültig. Die dritte Kopie ist die Versicherung für den Moment, in dem die zweite gebraucht wird.

Was heißt „zwei Medien” bei einem Server?

Der Ursprung der Regel stammt aus einer Welt mit Festplatten, DVDs und Bändern. Auf einem gemieteten Server denkt man besser in getrennten Systemen als in Datenträgern. Zwei Ordner auf derselben Festplatte sind ein Medium. Ein Backup auf einer zweiten Platte im selben Server ist schon besser, teilt aber Netzteil, Betriebssystem und root-Zugang. Für einen Server bedeutet „zwei Medien” sinnvollerweise: eine Kopie auf dem Server (oder seinem Snapshot-System) und eine in einem anderen Speichersystem, zum Beispiel einer Storage Box, einem S3-kompatiblen Objektspeicher oder einem zweiten Server.

Was heißt „extern”?

Extern heißt: Ein Ereignis, das den Server trifft, darf die externe Kopie nicht mittreffen. Ein anderes Rechenzentrum desselben Anbieters schützt vor Brand und Stromausfall. Ein anderer Anbieter schützt zusätzlich vor einem gesperrten Kundenkonto, einer Insolvenz oder einem Abrechnungsfehler. Und ein Ziel, das der Server selbst nicht löschen kann, schützt vor dem Angreifer, der root auf dem Server hat. Zu diesem letzten Punkt kommen wir gleich, denn genau da hatte unser eigenes Setup eine Lücke.

Deutsche Erklärung von Synology, inklusive der Erweiterung 3-2-1-1-0. Das Video stammt von einem NAS-Hersteller und zeigt naturgemäß dessen Produkte, die Prinzipien gelten aber für jeden Server.

Die 3-2-1 Backup-Strategie auf einem Linux-Server: ein konkreter Aufbau

So sieht ein schlichter, bezahlbarer Aufbau für einen einzelnen Linux-Server aus, etwa einen VPS oder einen Dedicated Server:

Die lokale Kopie ist für den Alltag da: versehentlich gelöschte Datei, kaputtes Update, „wie sah die Konfiguration gestern aus?”. Sie ist schnell, kostet nichts und ist in Sekunden zurückgeholt. Die externe Kopie ist für den Katastrophenfall: Server weg, Account weg, Angreifer drin.

Warum gleich zwei Repositories und nicht ein Backup, das man dann kopiert? Weil eine Kopie eines Backups auch alle seine Fehler mitkopiert. Zwei unabhängige Sicherungsläufe in zwei getrennte Repositories sind robuster: Ist eines beschädigt, ist es das andere nicht automatisch auch.

Warum wir restic nehmen

Für Server-Backups gibt es drei Werkzeuge, die man ernsthaft in Betracht ziehen sollte: restic, BorgBackup und Kopia. Alle drei machen Snapshots mit Deduplizierung und Verschlüsselung. Wir nutzen restic, weil es ein einzelnes Programm ohne Abhängigkeiten ist, weil es direkt nach SFTP, S3, Backblaze B2 und viele weitere Ziele sichern kann und weil das Repository-Format offen dokumentiert ist.

restic installierst du auf Ubuntu und Debian aus den Paketquellen:

sudo apt install restic
restic version
# restic 0.16.4 compiled with go1.22.2 on linux/amd64

Das ist die Version, die wir auf Ubuntu 24.04 aus dem Paket bekommen haben. Neuere Versionen gibt es als Binary direkt bei GitHub, und restic self-update funktioniert nur beim offiziellen Binary, nicht beim Distributionspaket.

Schritt für Schritt: die 3-2-1 Backup-Strategie mit restic umsetzen

Schritt 1: Passwort festlegen und sicher ablegen

restic verschlüsselt jedes Repository mit einem Passwort. Ohne dieses Passwort ist das Backup wertlos, es gibt keine Hintertür. In unserem Test lieferte ein falsches Passwort genau diese eine Zeile:

Fatal: wrong password or no key found

Leg das Passwort deshalb in eine Datei, die nur root lesen kann, und bewahre eine zweite Kopie außerhalb des Servers auf, etwa in einem Passwortmanager. Das ist der Teil der 3-2-1-Regel, den fast alle vergessen: Das Backup ist extern, der Schlüssel dazu aber nur auf dem Server, der gerade abgebrannt ist.

sudo install -m 600 /dev/null /root/.restic-pass
openssl rand -base64 32 | sudo tee /root/.restic-pass > /dev/null

Schritt 2: Lokales und externes Repository anlegen

export RESTIC_PASSWORD_FILE=/root/.restic-pass

# Kopie 2: lokal (besser auf einem eigenen Volume)
restic init -r /srv/backup/restic

# Kopie 3: extern per SFTP, z. B. Storage Box oder zweiter Server
restic init -r sftp:backup@backup.example.com:/restic/meinserver

Für SFTP nutzt restic deinen SSH-Zugang. Am saubersten ist ein eigener SSH-Schlüssel nur für das Backup, mit einem eigenen Benutzer auf dem Ziel. Warum das wichtig ist, zeigt der Abschnitt zur Löschbarkeit weiter unten.

Schritt 3: Das erste Backup

restic -r /srv/backup/restic backup /etc /srv /home /var/backups/db
restic -r sftp:backup@backup.example.com:/restic/meinserver backup /etc /srv /home /var/backups/db

Unsere Messung mit dem Quellcode und den Bildern dieses Blogs (756 Dateien, 44,2 MiB), restic 0.16.4, gesichert vom Server in Nürnberg:

Die Zeile mit den 110 KiB ist der Kern von restic: Wir haben den ganzen Ordner an einen anderen Ort kopiert, eine Zeile geändert und gesichert. restic hat die Inhalte wiedererkannt und nur das gespeichert, was wirklich neu war. Deshalb kann man täglich sichern, ohne dass das Repository explodiert.

Schritt 4: Datenbanken richtig sichern

Eine laufende Datenbank darf man nicht einfach als Dateien kopieren, sonst landet ein halb geschriebener Zustand im Backup. Erst einen Dump erzeugen, dann den Dump sichern:

# PostgreSQL
sudo -u postgres pg_dumpall | gzip > /var/backups/db/postgres-$(date +%F).sql.gz

# MySQL / MariaDB
mysqldump --all-databases --single-transaction | gzip > /var/backups/db/mysql-$(date +%F).sql.gz

# SQLite (konsistent auch bei laufendem Schreiber)
sqlite3 /srv/app/data.db ".backup '/var/backups/db/app-$(date +%F).db'"

restic kann einen Dump auch direkt aus einer Pipe lesen, dann landet er gar nicht erst unverschlüsselt auf der Platte:

sudo -u postgres pg_dumpall | restic -r /srv/backup/restic backup --stdin --stdin-filename postgres.sql

Schritt 5: Automatisch laufen lassen

restic hat keinen eigenen Zeitplaner. Du startest es per Cronjob oder besser per systemd-Timer, weil du dort Logs im Journal und eine saubere Fehlermeldung bekommst. Ein schlichtes Skript:

#!/bin/bash
# /usr/local/bin/backup.sh
set -euo pipefail
export RESTIC_PASSWORD_FILE=/root/.restic-pass
PFADE="/etc /srv /home /var/backups/db"

sudo -u postgres pg_dumpall | gzip > /var/backups/db/postgres.sql.gz

for REPO in /srv/backup/restic sftp:backup@backup.example.com:/restic/meinserver; do
  restic -r "$REPO" backup $PFADE --exclude-caches --tag taeglich
  restic -r "$REPO" forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
done

Und der Eintrag in der Crontab, mit Sperre gegen Überlappung (die Begründung steht in unserem Cronjob-Artikel):

30 3 * * * flock -n /run/backup.lock /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Schritt 6: Aufbewahrung festlegen

forget entscheidet, welche Snapshots bleiben, --prune löscht danach die Daten, die kein Snapshot mehr braucht. Eine vernünftige Grundeinstellung für Server:

Die Aufbewahrung ist eine Sicherheitsentscheidung, keine reine Platzfrage. Dazu gleich mehr im Ransomware-Test.

Spiegel ist kein Backup: unser Ransomware-Test

Die häufigste Fehlannahme in der Datensicherung lautet: „Ich synchronisiere jede Nacht per rsync auf einen zweiten Server, also habe ich ein Backup.” Wir haben genau das nachgestellt. Zwanzig Testdateien, mit rsync -a --delete auf ein Ziel gespiegelt. Dann haben wir alle zwanzig Dateien im Original verschlüsselt, so wie es ein Verschlüsselungstrojaner tun würde, und den nächsten nächtlichen Lauf simuliert.

Das Ergebnis am Ziel, erste Bytes der ersten Datei:

00000000: 5361 6c74 6564 5f5f        Salted__

Salted__ ist der Kopf einer mit OpenSSL verschlüsselten Datei. Der Spiegel hat seine Aufgabe perfekt erfüllt und alle 20 verschlüsselten Dateien übernommen. Die guten Fassungen sind überschrieben. Ein Spiegel schützt vor einer toten Festplatte, aber nicht vor allem, was auf der Festplatte passiert: Löschen, Überschreiben, Verschlüsseln, ein kaputtes Update.

Dieselbe Attacke gegen restic: Wir haben in einer Kopie 50 von 198 Artikeldateien verschlüsselt und gesichert. restic meldete sachlich:

Files:           0 new,    50 changed,   148 unmodified
Added to the repository: 1.427 MiB (1.408 MiB stored)

Ein neuer Snapshot mit den verschlüsselten Dateien, aber die älteren Snapshots blieben unangetastet. Wiederherstellen heißt hier einfach: den Snapshot von vor dem Angriff wählen.

restic -r /srv/backup/restic snapshots
restic -r /srv/backup/restic restore 98401217 --target /srv/restore

Genau deshalb ist die Aufbewahrung eine Sicherheitsfrage. Mit --keep-last 2 und täglichem Lauf ist der letzte saubere Stand nach zwei Tagen weg. Ein Angriff, der eine Woche lang unbemerkt bleibt, hat bei einer Aufbewahrung von sieben Tagen alle guten Snapshots überlebt. Wie lange Angriffe tatsächlich unbemerkt bleiben, haben wir in Ein Server, fünf Tage gekapert beschrieben. Unsere Faustregel: Aufbewahrung mindestens doppelt so lang wie die Zeit, in der du einen Vorfall realistisch bemerkst.

Die Lücke, die kaum jemand prüft: Kann der Server sein eigenes Backup löschen?

Jetzt der Teil, der uns selbst überrascht hat. Unser wichtigstes Backup auf diesem Server ist ein nächtlicher Lauf, der die Konfiguration und die Daten unserer KI-Agenten verschlüsselt und an drei Orte schreibt. Auf dem Papier ist das vorbildlich 3-2-1, sogar mit eingebautem Restore-Test bei jedem Lauf:

Zwei Dinge fielen beim Nachprüfen auf. Erstens: Der vierte Speicherort, den wir gedanklich als „extern” verbucht hatten, läuft auf genau dem Server, den er absichern soll. Die Domain löst auf dieselbe IP-Adresse auf. Das ist keine externe Kopie, das ist ein zweiter Ordner mit Weboberfläche.

Zweitens, und wichtiger: Die Kopie nach Helsinki wird per scp mit dem root-Schlüssel des Hauptservers hochgeladen, und dasselbe Skript räumt dort alte Stände per ssh … rm auf. Wir haben nachgemessen, ob der Hauptserver auf dem Backup-Ziel löschen darf:

ssh root@backup-ziel 'touch /root/test/x && rm /root/test/x && echo DELETE-POSSIBLE'
# DELETE-POSSIBLE

Damit fällt die Regel in sich zusammen, sobald jemand root auf dem Hauptserver hat. Ein Angreifer mit diesen Rechten sieht im Backup-Skript, wohin gesichert wird, und hat den passenden Schlüssel gleich mit. Ein Befehl, und die „externe” Kopie ist ebenso weg wie das Original.

So machst du es besser:

1. Eigener Benutzer auf dem Ziel, nicht root. Mit eigenem Schlüssel, der nur für das Backup existiert.
2. Append-only. Der Server darf neue Snapshots schreiben, aber keine alten löschen. Mit restic geht das über den rest-server mit der Option --append-only, mit Borg über borg serve --append-only in der authorized_keys. Aufräumen (forget --prune) läuft dann vom Backup-Ziel aus oder von einem dritten Rechner, nicht vom Server, der gesichert wird.
3. Objektspeicher mit Object Lock (S3-kompatibel): Objekte sind für eine festgelegte Zeit unveränderlich, selbst für den Kontoinhaber.
4. Pull statt Push: Der Backup-Server holt sich die Daten, der Produktionsserver hat überhaupt keinen Zugang zum Backup-Ziel.

Genau das ist die Erweiterung, die heute meist unter dem Namen 3-2-1-1-0 läuft: eine Kopie zusätzlich unveränderlich oder offline (die zweite 1), und null Fehler beim Restore-Test (die 0).

Die Grundregel noch einmal ruhig auf Deutsch erklärt, von DAVISION. Das Video ist von 2021, an der Regel hat sich seitdem nichts geändert.

Was wir auf unserem eigenen Server gefunden haben

Wir haben nicht nur das Agenten-Backup geprüft, sondern gezählt, welche Daten auf dem Server überhaupt gesichert werden. Das Bild ist durchwachsen, und es ist vermutlich typisch für jeden Server, der über Monate gewachsen ist:

Drei Lehren daraus:

Ein Backup, das von einem Dienst abhängt, stirbt mit dem Dienst. Das selbst gehostete Tool hat stündlich vorbildlich eigene Dumps geschrieben. Dann wurde der Dienst am 2. Oktober gestoppt, und mit ihm die Sicherung. 149 Dumps mit 317 MB liegen auf derselben Platte, und niemand hat bemerkt, dass keine neuen dazukommen. Datenbank-Dumps gehören in einen Lauf, der unabhängig von der Anwendung ist.

„Liegt doch im Repository” stimmt nur, wenn es ein Repository gibt. Der Blog-Quellcode ist kein Git-Repository. Wir hatten ihn gedanklich als „steht ja irgendwo” abgehakt. Er lag aber nur an einem Ort, und das ist exakt null Backups.

Lokale Kopien sind das 2, nicht das 1. Die meisten unserer Sicherungen sind tadellos gebaut, mit Integritätsprüfung und Rotation, aber sie liegen auf derselben Platte wie die Daten. Gegen ein gelöschtes Verzeichnis helfen sie, gegen einen verlorenen Server nicht.

Wir haben beim Test nichts an der laufenden Sicherung geändert. Das Umbauen auf Append-only und das Einbinden der fehlenden Daten ist eine bewusste Entscheidung und kein Nebenbei-Fix während eines Artikels.

RAID, Snapshots, Cloud-Sync: Was zählt als Kopie?

Viele Dinge sehen aus wie ein Backup und sind keins. Eine kurze Einordnung:

Unser Server selbst hat übrigens kein RAID, und das ist bei einem Cloud-Server in Ordnung: Die virtuelle Platte wird vom Anbieter redundant gespeichert. Das ersetzt ebenfalls kein Backup, aus demselben Grund wie RAID.

Restore testen: ein Backup ohne Restore-Test ist ein Gerücht

Die 0 in 3-2-1-1-0 steht für „null Fehler beim Wiederherstellen”. Das ist der Schritt, der in der Praxis am häufigsten fehlt, weil er sich nicht nach Arbeit anfühlt, solange alles funktioniert. Drei Stufen, von schnell bis gründlich:

# 1. Strukturprüfung (Sekunden)
restic -r REPO check

# 2. Alle Daten tatsächlich lesen und Prüfsummen vergleichen
restic -r REPO check --read-data
# oder bei großen Repos nur einen Teil pro Lauf:
restic -r REPO check --read-data-subset=1/10

# 3. Echte Wiederherstellung und Vergleich
restic -r REPO restore latest --target /tmp/restore-test
diff -r /srv /tmp/restore-test/srv && echo "Restore identisch"

Bei uns: 44 MiB aus Helsinki in 3,5 Sekunden zurück, diff -r ohne Unterschied, check --read-data in 29 Sekunden ohne Fehler. Für ein großes Repository dauert das länger, deshalb ist --read-data-subset praktisch: Jede Nacht ein Zehntel lesen, und nach zehn Tagen ist alles einmal geprüft.

Die wichtigste Prüfung ist aber keine technische: Kannst du den Restore auf einem leeren Rechner durchführen, ohne den alten Server? Dazu brauchst du das Repository-Passwort, den Zugang zum Backup-Ziel und eine Notiz, welche Pfade wohin gehören. Lieg eins davon nur auf dem Server, ist dein Backup im Ernstfall verschlossen. Ein guter Testlauf alle paar Monate: neuer kleiner VPS, restic installieren, aus dem externen Repo wiederherstellen, Dienst starten. Dauert eine Stunde und zeigt jede Lücke.

Was kostet eine 3-2-1 Backup-Strategie?

Weniger, als die meisten denken. Für einen typischen kleinen Server mit 50 bis 200 GB Daten:

Konkrete Preise ändern sich laufend, prüfe sie deshalb direkt beim Anbieter. Wichtiger als der Preis ist die Wahl: Liegt die externe Kopie beim selben Anbieter wie der Server, schützt sie vor Hardwareausfall und Brand, nicht aber vor einem gesperrten Kundenkonto. Wer sicher gehen will, nimmt für die externe Kopie einen zweiten Anbieter.

Durch die Deduplizierung wächst ein restic-Repository bei typischen Serverdaten (Konfiguration, Code, Datenbank-Dumps) täglich nur um die tatsächlichen Änderungen. Unser Beispiel: Eine geänderte Zeile kostete 32 KiB Speicherplatz.

3-2-1 für kleine Unternehmen, Homelab und Nextcloud

Die Regel ist dieselbe, nur die Bausteine ändern sich:

Kleines Unternehmen mit einem Server und Arbeitsplatz-PCs: Server nach dem Muster oben. Arbeitsplätze sichern idealerweise ebenfalls mit restic oder dem Backup-Werkzeug des Betriebssystems auf den Server oder ein NAS (Kopie 2), und von dort wandert es extern (Kopie 3). Wichtig: Ein Mitarbeiter-PC mit Schreibrechten auf das Backup-Ziel ist ein Einfallstor für Ransomware. Auch hier gilt append-only.

Homelab mit Proxmox: Die VMs werden per Proxmox Backup Server oder vzdump gesichert (lokal), restic oder Borg schiebt die Sicherungen zusätzlich extern. Hintergründe zur Virtualisierung stehen in Proxmox vs. ESXi.

Nextcloud: Datenordner, Datenbank-Dump und config.php gehören zusammen. Ohne Datenbank-Dump sind die Dateien zwar da, Freigaben, Kalender und Kontakte aber nicht. Welcher Anbieter für Nextcloud selbst sinnvoll ist, steht im Nextcloud-Hosting-Vergleich.

Docker-Server: Gesichert werden die Volumes und die Compose-Dateien, nicht die Images. Die lassen sich jederzeit neu ziehen. Datenbanken in Containern brauchen auch hier einen Dump, etwa per docker exec db pg_dumpall. Mehr zur Struktur in Was ist Docker.

Checkliste: Erfüllt dein Server die 3-2-1-Regel wirklich?

1. Gibt es mindestens zwei Backups zusätzlich zum Original?
2. Liegt mindestens eins in einem anderen Speichersystem, nicht nur in einem anderen Ordner?
3. Liegt mindestens eins bei einem anderen Anbieter oder an einem anderen Ort?
4. Kann der Server sein externes Backup löschen? Wenn ja: append-only, Object Lock oder Pull.
5. Sind Datenbanken als Dump gesichert, und läuft der Dump unabhängig von der Anwendung?
6. Liegen Passwort und Zugangsdaten zum Backup auch außerhalb des Servers?
7. Reicht die Aufbewahrung länger zurück, als ein Angriff unbemerkt bleiben könnte?
8. Wann war der letzte echte Restore-Test?
9. Merkst du es, wenn das Backup nicht mehr läuft? Ein Backup ohne Alarm schweigt genau dann, wenn es aufhört.
10. Ist alles drin? Mach einmal eine Liste aller Dienste und Datenverzeichnisse und hake sie gegen die Backup-Pfade ab. Bei uns fiel so der Blog-Quellcode auf.

Wenn du gerade einen neuen Server aufsetzt, plane das Backup gleich von Anfang an mit ein. Die übrigen Grundschritte stehen in Linux-Server einrichten.

Häufige Fragen

Was bedeutet die 3-2-1-Regel?

Drei Kopien deiner Daten (das Original plus zwei Backups), auf zwei unterschiedlichen Speicherarten oder Systemen, und eine Kopie an einem anderen Ort. So überlebt mindestens eine Kopie den Ausfall eines Geräts, einen Fehler einer ganzen Speicherart und einen Schaden am Standort.

Zählt das Original als eine der drei Kopien?

Ja. Die Regel meint drei Kopien insgesamt, also die Arbeitsdaten plus zwei Backups. Mehr Backups schaden nicht.

Was ist die 3-2-1-1-0-Regel?

Eine moderne Erweiterung: Zusätzlich zu 3-2-1 ist eine Kopie unveränderlich oder offline (gegen Ransomware und Angreifer mit Admin-Rechten), und Restore-Tests laufen mit null Fehlern. Sie schließt genau die Lücke, die wir bei uns gefunden haben: ein externes Backup, das der Server selbst löschen kann.

Ist RAID ein Backup?

Nein. RAID schützt vor dem Ausfall einer Festplatte und spiegelt dafür jede Änderung sofort, also auch Löschungen, Überschreibungen und Verschlüsselungen. Es erhöht die Verfügbarkeit, ersetzt aber keine einzige Backup-Kopie.

Reicht ein Snapshot beim Hosting-Anbieter?

Als lokale Kopie ja, als externe Kopie nein. Provider-Snapshots liegen beim selben Anbieter und meist im selben Kundenkonto. Wird das Konto gesperrt oder kompromittiert, sind sie mit weg. Für 3-2-1 brauchst du zusätzlich ein Backup außerhalb.

Ist rsync ein Backup?

Ein rsync --delete auf ein Ziel ist ein Spiegel, kein Backup. In unserem Test hat er 20 von 20 verschlüsselten Dateien übernommen und die guten Fassungen überschrieben. rsync mit --link-dest und datierten Zielordnern erzeugt dagegen echte Versionen und ist ein brauchbares Backup.

restic oder Borg: was ist besser?

Beide sind sehr gut. restic kann direkt in viele Ziele sichern (SFTP, S3, B2) und braucht auf dem Ziel nichts Besonderes. Borg ist etwas effizienter und lässt sich per SSH einfach auf append-only beschränken, braucht dafür aber Borg auf dem Ziel. Für den Einstieg empfehlen wir restic, wer einen eigenen Backup-Server betreibt, fährt mit Borg ebenso gut.

Wie oft sollte ich ein Server-Backup machen?

So oft, wie du Datenverlust verkraften kannst. Für die meisten Server reicht täglich, Datenbanken mit vielen Änderungen sichert man stündlich als Dump. Die Frage dahinter heißt Recovery Point Objective: Wie viele Stunden Arbeit darfst du verlieren?

Wie lange sollte ich Backups aufbewahren?

Mindestens so lange, dass ein unbemerkter Angriff oder Fehler noch vor dem ältesten Snapshot liegt. Eine gute Grundeinstellung: 7 tägliche, 4 wöchentliche und 6 monatliche Stände. Bei rechtlichen Aufbewahrungspflichten gelten zusätzlich die gesetzlichen Fristen.

Muss ich Backups verschlüsseln?

Sobald eine Kopie das Haus verlässt: ja. restic und Borg verschlüsseln immer. Bewahre das Passwort aber zusätzlich außerhalb des Servers auf, sonst ist dein Backup nach einem Totalausfall unlesbar.

Wie teste ich, ob mein Backup funktioniert?

Mit restic check --read-data prüfst du, ob alle Daten lesbar sind. Der eigentliche Test ist aber eine echte Wiederherstellung, am besten auf einem frischen Rechner, ohne Zugriff auf den alten Server. Erst dann weißt du, dass Passwort, Zugangsdaten und Anleitung wirklich vollständig sind.

Fazit: Die 3-2-1 Backup-Strategie ist leicht zu merken und leicht zu verfehlen

Die Regel selbst ist simpel, und die Werkzeuge sind ausgereift und kostenlos. restic hat in unserem Test einen vollständigen Restore aus einem anderen Land in dreieinhalb Sekunden geschafft und einen simulierten Verschlüsselungstrojaner mühelos überstanden, an dem ein klassischer rsync-Spiegel gescheitert ist.

Schwierig ist nicht das Einrichten, sondern das ehrliche Nachzählen. Auf unserem eigenen Server erfüllte das am besten gebaute Backup die Regel nur auf dem Papier, weil der Server seine externe Kopie selbst löschen kann. Eine Datenbank-Sicherung war mit ihrem Dienst still gestorben, und der Quellcode dieses Blogs lag in gar keinem Backup.

Wenn du nach diesem Artikel nur eine Sache tust, dann diese: Schreib alle Daten auf, die dir wichtig sind, und schreib daneben, wo die zweite und die dritte Kopie liegt und ob dein Server sie löschen könnte. Die leeren Zeilen sind deine To-do-Liste.