restic-backup-suite ist ein produktionsreifes Backup-Toolkit für Linux-Server, das auf restic basiert. Es automatisiert den vollständigen Backup-Lifecycle: Datenbank-Dumps, Datei-Backup, Retention-Policy, Integritätsprüfung — alles in einem konfigurierbaren Shell-Script.
Automatisiert den gesamten Backup-Lifecycle auf Linux-Servern — von Datenbank-Dumps bis zur Integritätsprüfung — mit einem einzigen Befehl.
Das Toolkit besteht aus drei Komponenten:
| Datei | Funktion |
|---|---|
backup.sh |
Automatisches Backup mit Retention und Verifikation |
restore.sh |
Interaktives Restore-Menü aus beliebigen Snapshots |
install.sh |
System-Installation mit Aliases und optionalem Cron-Job |
set -euo pipefail) in allen Scriptsinstall.sh mit Shell-Aliases und optionalem Cron-Job| Anforderung | Version | Hinweise |
|---|---|---|
| Bash | 4.4+ | Standard auf modernen Linux-Distributionen |
| restic | beliebig | Muss im PATH vorhanden sein |
| Root-Zugriff | — | Scripts benötigen sudo |
| sftp | — | Nur für SFTP-Remote-Backends (z.B. Hetzner Storage Box) |
| docker | — | Nur für Docker-Datenbank-Dumps |
| mysqldump / mysql | — | Nur für native MySQL-Dumps / Restore |
Das install.sh Script richtet alles systemweit ein:
git clone https://github.com/markus-michalski/restic-backup-suite.git
cd restic-backup-suite
sudo ./install.sh
Danach stehen bereit:
/etc/restic/config.sh/usr/local/bin/restic-backup und /usr/local/bin/restic-restore/etc/profile.d/restic-aliases.shMit optionalem Cron-Job (täglich 03:00):
sudo ./install.sh --cron
git clone https://github.com/markus-michalski/restic-backup-suite.git
cd restic-backup-suite
cp config.example.sh config.sh
chmod 600 config.sh
Scripts direkt aufrufen:
sudo ./backup.sh
sudo ./restore.sh
echo "dein-starkes-passwort" > /etc/restic/password.txt
chmod 400 /etc/restic/password.txt
In config.sh auf diese Datei verweisen:
RESTIC_PASSWORD_FILE="/etc/restic/password.txt"
Für SFTP-Backends (z.B. Hetzner Storage Box) einen dedizierten Key anlegen:
ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519_backup -N ""
Public Key auf den Remote-Server kopieren, dann in config.sh:
SSH_KEY_FILE="/root/.ssh/id_ed25519_backup"
backup.sh schreibt den SSH-Config-Eintrag automatisch beim ersten Aufruf.
Die Konfiguration liegt in config.sh (aus config.example.sh kopieren). Diese Datei ist gitignored und wird nie committed.
config.shenthält sensible Zugangsdaten. Berechtigungen aufchmod 600setzen — nur root darf lesen.
| Variable | Beschreibung | Standard |
|---|---|---|
RESTIC_PASSWORD_FILE |
Pfad zur Passwort-Datei | /etc/restic/password.txt |
RESTIC_REPOSITORY |
Repository-URL | — |
RESTIC_CACHE_DIR |
Lokales Cache-Verzeichnis | ~/.cache/restic |
GOMAXPROCS |
CPU-Kerne für restic | 2 |
SSH_HOST |
SSH-Alias (SFTP-Backend) | — |
SSH_HOSTNAME |
Echter Remote-Hostname | — |
SSH_PORT |
SSH-Port | 22 |
SSH_USER |
SSH-Benutzername | — |
SSH_KEY_FILE |
Pfad zum SSH-Private-Key | — |
LOG_DIR |
Log-Verzeichnis | /var/log/restic |
BACKUP_PATHS |
Array der Backup-Pfade | — |
BACKUP_EXCLUDES |
Array der Exclude-Pattern | — |
RETENTION_KEEP_DAILY |
Tägliche Snapshots behalten | 7 |
RETENTION_KEEP_WEEKLY |
Wöchentliche Snapshots behalten | 4 |
RETENTION_KEEP_MONTHLY |
Monatliche Snapshots behalten | 6 |
REPO_CHECK_SUBSET |
Anteil der Daten zur Verifikation | 5% |
MYSQL_BACKUP_ENABLED |
Nativen MySQL-Dump aktivieren | false |
DOCKER_MARIADB_CONTAINERS |
MariaDB-Container für Dumps | () |
DOCKER_POSTGRES_CONTAINERS |
PostgreSQL-Container für Dumps | () |
SERVICES_TO_STOP |
Systemd-Services zum Pausieren | () |
# SFTP (Hetzner Storage Box)
RESTIC_REPOSITORY="sftp:myhost:/backup/restic"
# Lokal
RESTIC_REPOSITORY="/mnt/backup/restic-repo"
# Amazon S3
RESTIC_REPOSITORY="s3:s3.amazonaws.com/bucket-name"
# Backblaze B2
RESTIC_REPOSITORY="b2:bucket-name:/path"
sudo restic-backup --dry-run
# oder direkt:
sudo ./backup.sh --dry-run
Zeigt, was gesichert würde — ohne restic auszuführen.
sudo restic-backup
# oder:
sudo ./backup.sh
sudo ./backup.sh --config /etc/restic/config.sh
sudo restic-restore
# oder:
sudo ./restore.sh
Das Menü erscheint:
What do you want to restore?
----------------------------
1) Full backup (all paths)
2) Web files (/var/www)
3) Configuration (/etc)
4) Home directories (/home)
5) Database dumps (SQL files from backup)
6) SSL certificates (/etc/letsencrypt)
7) Custom path
q) Quit
sudo ./restore.sh --snapshot abc12345
Wiederhergestellte Dateien landen immer zuerst in einem temporären Verzeichnis (/tmp/restic-restore-XXXXXX). Erst nach Prüfung werden sie manuell an den Zielort verschoben.
Nach sudo ./install.sh stehen nach dem nächsten Login (oder source /etc/profile.d/restic-aliases.sh) folgende Aliases zur Verfügung:
| Alias | Funktion |
|---|---|
restic-snapshots |
Alle Snapshots auflisten |
restic-stats |
Repository-Größe und Dedup-Statistiken |
restic-check |
Integritätsprüfung (5% Sample) |
restic-ls |
Dateien im neuesten Snapshot auflisten |
restic-mount |
Repository via FUSE mounten |
restic-unlock |
Veralteten Lock entfernen |
restic-rawstats |
Rohe On-Disk-Größe |
Aliases laden automatisch die Konfiguration aus
/etc/restic/config.sh— kein manuellesexportnötig.
| Symptom | Prüfen | Lösung |
|---|---|---|
Config file not found |
Existiert config.sh? |
cp config.example.sh config.sh |
Permission denied |
Script ausführbar? | chmod +x backup.sh |
SFTP connection failed |
SSH-Config korrekt? | sftp myhost manuell testen |
Wrong password |
Passwort-Datei korrekt? | Inhalt prüfen: cat /etc/restic/password.txt |
Repository not found |
Repo initialisiert? | Erstes Backup init automatisch, oder restic init |
Lock exists |
Anderer Prozess läuft? | restic-unlock aufrufen |
No such snapshot |
Snapshot-ID korrekt? | restic-snapshots für Liste |
Beim ersten Aufruf wird das restic-Repository automatisch initialisiert — kein manuelles
restic initnötig.
# SSH-Config prüfen
grep -A5 "Host myhost" /root/.ssh/config
# Manuelle SFTP-Verbindung testen
sftp myhost
# Known Hosts befüllen
ssh-keyscan -p 22 storage.example.com >> /root/.ssh/known_hosts_backup
# Letztes Backup-Log
tail -100 /var/log/restic/backup-$(date +%Y-%m-%d).log
# Cron-Log
tail -100 /var/log/restic/cron.log
Alle Scripts folgen dem gleichen Pattern:
set -o errexit -o nounset -o pipefail — Strict Modetrap cleanup EXIT ERR INT TERM — Zuverlässige Aufräumlogikmain "$@" — Einstiegspunkt am Ende der Dateimain deklariertconfig.sh — keine hardcoded WerteDas Script schreibt SSH-Konfiguration nach ~/.ssh/config.d/restic-backup und fügt automatisch Include ~/.ssh/config.d/* am Anfang von ~/.ssh/config ein — ohne bestehende Konfiguration zu überschreiben.
| Exit Code | Bedeutung |
|---|---|
| 0 | Backup/Restore erfolgreich |
| 1 | Allgemeiner Fehler (Config fehlt, Permission denied, etc.) |
Kann ich mehrere Server mit einer Konfiguration sichern?
Nein — eine config.sh entspricht einem Server und einem Repository. Für mehrere Server separate Configs und Cron-Jobs anlegen.
Was passiert, wenn das Backup unterbrochen wird?
restic hinterlässt einen Lock. Nach einem Neustart restic-unlock aufrufen, dann das Backup erneut starten.
Werden Datenbanken konsistent gesichert?
Ja — Datenbank-Dumps werden vor dem Backup erstellt und anschließend gelöscht. Die SQL-Dateien landen im Backup-Set.
Wie groß ist der Overhead durch restic-Deduplizierung?
Sehr gering. Inkrementelle Backups sichern typischerweise nur 1–5% der Gesamtdatenmenge.
Kann ich das Repository auf mehreren Medien spiegeln?
restic unterstützt kein natives Mirroring. Alternative: rclone als zusätzlicher Sync-Schritt nach dem Backup.
Wie deinstalliere ich alles wieder?
sudo ./install.sh --uninstall
Konfiguration und Logs werden dabei nicht gelöscht (auf Nachfrage).
MIT — Freie Nutzung, Modifikation und Weiterverteilung. Keine Garantie.