Was passiert, wenn ich das restic-Passwort verliere?

Dann sind die Backups endgültig verloren. restic verschlüsselt alles auf dem Client, einen Wiederherstellungsschlüssel gibt es nicht. Bewahren Sie das Passwort in einem Passwortmanager auf, nicht nur auf dem Server, den Sie sichern.

Wo sollte das Repository liegen?

Überall außer auf dem Server selbst: in S3-kompatiblem Objektspeicher, auf einem anderen VPS per SFTP oder auf einem Rechner zu Hause. Ein Backup auf derselben Platte stirbt mit dieser Platte.

Wie sichere ich eine Datenbank mit restic?

Erst dumpen, dann den Dump sichern — für PostgreSQL 'pg_dump -Fc', für MySQL 'mysqldump --single-transaction'. Das Kopieren von Dateien einer laufenden Datenbank kann ein Backup ergeben, das nicht startet.

Wie viel Platz brauchen die Backups?

Weniger, als man denkt. restic zerlegt Dateien in Blöcke und speichert jeden Block nur einmal, deshalb fügen tägliche Snapshots eines kaum veränderten Servers nur die Änderungen hinzu.

Brauche ich dann noch Managed Backups?

Sie lösen unterschiedliche Probleme. Managed Backups liefern tägliche Wiederherstellungspunkte des ganzen Servers, die Sie im Kundenbereich zurückspielen. restic liefert Kopien auf Dateiebene außerhalb des Servers, die Sie selbst kontrollieren. Viele nutzen beides.

VPS mit restic sichern (verschlüsselt und extern)

Verschlüsselte, deduplizierte VPS-Backups mit restic: Repository auf S3-kompatiblem Speicher oder einem anderen Server, systemd-Timer, Aufbewahrung und ein echter Restore-Test.

Jeder hat Backups — bis er versucht, eines wiederherzustellen. Der Ordner ist leer, der Cronjob ist im März gestorben, oder das Archiv liegt auf genau der Platte, die gerade ausgefallen ist. restic behebt das meiste davon: Es verschlüsselt auf Ihrer Seite, speichert jedes Datenstück nur einmal und macht das Wiederherstellen einer einzelnen Datei so einfach wie das Sichern des ganzen Servers.

Hier ein Setup, dem wir selbst vertrauen würden, auf Ubuntu oder Debian.

1. restic installieren

apt update && apt install -y restic
restic self-update

Distributionspakete hinken hinterher; self-update holt die aktuelle Version.

2. Einen Ort für das Repository wählen

Das Repository darf nicht auf dem Server liegen, den Sie schützen. Zwei gängige Varianten:

Ein anderer Server per SFTP: sftp:backup@203.0.113.20:/srv/restic/web1
S3-kompatibler Objektspeicher: s3:https://s3.example.com/my-bucket/web1

3. Die Zugangsdaten ablegen

Alles in einer Datei, die nur root lesen darf, damit Timer und Shell dieselben Einstellungen nutzen:

cat > /root/.restic-env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-bucket/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="your-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret"
EOF
openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-env /root/.restic-pass

Kopieren Sie jetzt den Inhalt von /root/.restic-pass in Ihren Passwortmanager. Ohne ihn lassen sich die Backups nicht entschlüsseln — weder von Ihnen noch von jemand anderem.

4. Initialisieren und erstes Backup

source /root/.restic-env
restic init
restic backup /etc /home /root /srv /var/www \
  --exclude-caches --exclude '/root/.cache'
restic snapshots

Passen Sie die Pfade an den Ort an, an dem Ihre Daten tatsächlich liegen. Docker-Volumes liegen unter /var/lib/docker/volumes, Anwendungsdaten oft in /srv oder /opt.

5. Datenbanken: erst dumpen, dann sichern

Sichern Sie nicht die Rohdateien einer laufenden Datenbank. Dumpen Sie direkt vor dem Backup:

mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc mydb > /var/backups/db/mydb.dump

Nehmen Sie /var/backups/db in die Backup-Pfade auf. Unsere PostgreSQL-Anleitung erklärt mehr zu Dumps.

6. Mit systemd planen

Ein Timer ist hier besser als cron: Er schreibt ins Journal und holt einen Lauf nach, wenn der Server zur geplanten Zeit aus war.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic backup

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source /root/.restic-env && restic backup /etc /home /root /srv /var/www /var/backups/db --exclude-caches && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

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

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

forget --prune behält 7 tägliche, 4 wöchentliche und 6 monatliche Snapshots und löscht den Rest. Brauchen Sie einen Datenbank-Dump, legen Sie ihn in eine ExecStartPre=-Zeile.

7. Wirklich etwas wiederherstellen

Dieser Schritt macht aus „wir haben Backups“ eine Tatsache. Holen Sie ein Verzeichnis in einen temporären Ordner zurück und schauen Sie es sich an:

source /root/.restic-env
restic restore latest --target /tmp/restore-test --include /etc/nginx
ls -la /tmp/restore-test/etc/nginx
restic check

Machen Sie das jetzt und dann alle paar Monate wieder. restic check prüft die Struktur des Repositorys; das Wiederherstellen beweist, dass die Daten wirklich da sind.

restic und Managed Backups

Sie konkurrieren nicht. Managed Backups legen täglich einen Wiederherstellungspunkt des ganzen Servers an, den Sie im Kundenbereich zurückspielen — die schnelle Rettung nach einem kaputten Upgrade. Sie kosten $2 im Monat und sind bei jedem Jahrestarif kostenlos enthalten. restic liefert Kopien auf Dateiebene in einem Speicher, den Sie kontrollieren; das zählt, wenn eine Datei vom letzten Dienstag fehlt oder Sie eine Kopie ganz außerhalb unserer Infrastruktur wollen.

Speichern Sie sensible Daten, kombinieren Sie das mit Festplattenverschlüsselung, oder schauen Sie sich den Anwendungsfall verschlüsselter Speicher für ein eigenes Backup-Ziel an. Ein Micro-Tarif reicht für die meisten kleinen Server samt Backup-Jobs.