Fort Knox für den Heimserver – ein echtes Backup-Konzept aus der Praxis
Backups gehören zu den Themen, über die jeder redet und die trotzdem erstaunlich oft falsch oder halbherzig umgesetzt werden.
Ich wollte kein „wird schon gut gehen“-Backup, sondern ein Setup, dem ich wirklich vertraue. Herausgekommen ist ein mehrstufiges Backup-Konzept, das lokal, per Mail und verschlüsselt in der Cloud funktioniert, inklusive Checksummen, Monitoring und echten Fehlern auf dem Weg dorthin.
Das hier ist kein Hochglanz-Tutorial, sondern eine reale Umsetzung.
Ausgangslage
Auf meinem Server laufen unter anderem:
• Webserver (HTTP/HTTPS)
• Mailserver (Postfix + Dovecot)
• SSH
• Firewall, Fail2ban, Logging (inkl. Wazuh)
Ein Backup muss in diesem Kontext mehr leisten als „einmal täglich ein Tarball irgendwohin“.
Es muss ausfallsicher, nachvollziehbar und wiederherstellbar sein.
Warum ein einzelnes Backup nicht reicht
Ein einziges Backup ist kein Backup.
Ich wollte bewusst drei Ebenen:
1. Lokales Backup
Schnell verfügbar, unabhängig von Internet oder Drittanbietern.
2. Mail-Benachrichtigung
Sofortige Rückmeldung, ob das Backup wirklich gelaufen ist und nicht erst, wenn es zu spät ist.
3. Offsite-Backup in der Cloud
Für den Fall von Hardware-Defekt, Diebstahl oder Totalausfall –> clientseitig verschlüsselt.
Das Grundprinzip
Täglich wird ein vollständiges Archiv erzeugt, das folgende Inhalte enthält:
• Konfigurationen (Postfix, Dovecot, nginx, Fail2ban, SSH, sysctl usw.)
• Webinhalte
• Maildir des lokalen Mailusers
• TLS-Material (Let’s Encrypt)
• Systemrelevante Einstellungen
Das Archiv wird:
• mit Checksummen versehen
• lokal abgelegt
• verschlüsselt in die Cloud hochgeladen
• und per Mail gemeldet (inkl. Anhang, solange die Größe sinnvoll bleibt)
Realität statt Theorie: typische Stolpersteine
Natürlich lief das nicht alles reibungslos und genau das ist der interessante Teil.
Mail-Anhänge
Der Backup-Anhang war größer als Postfix standardmäßig erlaubt.
Lösung: gezieltes Anheben der message_size_limit-Werte für interne Nutzung, nicht blind global.
Cloud-Auth & OAuth
OneDrive + rclone funktionieren hervorragend, wenn man die richtige Region nutzt und versteht, wie Headless-OAuth wirklich funktioniert.
Falsche Region oder falsche Endpoints führen zu kryptischen Fehlern, die nichts mit Firewalls zu tun haben.
Personal Vault
OneDrive „Personal Vault“ ist für APIs teilweise problematisch.
Die Lösung war simpel: klarer Zielordner, keine Root-Scans.
Shell-Realität
set -u ist großartig..bis man vergisst, Variablen in der richtigen Reihenfolge zu setzen.
Ein klassischer Fehler, den man nur im echten Betrieb lernt.
Warum Verschlüsselung Pflicht ist
Cloud-Backups ohne clientseitige Verschlüsselung sind kein Backup, sondern Hoffnung.
Ich nutze eine rclone-crypt-Schicht, sodass:
• Dateinamen
• Inhalte
• Metadaten
für den Cloudanbieter nicht lesbar sind.
Entschlüsseln geht nur mit lokalem Passwort + Salt.
Das Ergebnis
Am Ende habe ich jetzt ein System, das:
• täglich automatisch läuft
• mir per Mail bestätigt, dass es gelaufen ist
• mir anzeigt, was in der Cloud liegt
• und jederzeit prüfbar wiederhergestellt werden kann
Das ist kein Enterprise-Overkill, aber auch kein Bastelbackup.
Es ist realistisch, nachvollziehbar und wartbar.
Was ich beim nächsten Projekt wieder so machen würde
• Backups immer mehrstufig
• Fehler nicht verstecken, sondern dokumentieren
• Monitoring und Benachrichtigung gleich mitdenken
• Cloud nur verschlüsselt
• Restore-Tests fest einplanen
Fazit
Security entsteht nicht durch perfekte Diagramme, sondern durch ehrliche Umsetzung.
Ein Backup ist erst dann gut, wenn man ihm im Ernstfall vertraut – und genau dafür lohnt sich der Mehraufwand.