Ein Backup-Projekt, das mehr Nerven kostete als gedacht
Manchmal klingt eine Aufgabe auf dem Papier simpel: Ein Backup, das auf dem Hosting-Server entsteht, soll automatisch auf mein eigenes NAS zuhause wandern. Ein Befehl, ein Zeitplan, fertig – dachte ich. In der Praxis wurde daraus eine kleine Fehlersuche mit mehreren Umwegen, die ich hier dokumentiere, weil sie vermutlich nicht nur mir passiert.
Der Hintergrund: Meine Joomla-Website läuft bei einem klassischen Webhosting-Anbieter mit SSH-Zugang. Backups erzeugt dort Akeeba Backup zuverlässig – aber bislang blieben sie auf demselben Server liegen wie die Website selbst. Fällt der Server aus, sind Original und Sicherungskopie gemeinsam weg. Die Lösung: Die Backups sollen automatisch auf einen Raspberry Pi mit OpenMediaVault (OMV) bei mir zuhause wandern – eine physisch getrennte Kopie, wie es die bekannte 3-2-1-Backup-Regel vorsieht.
Die SystemarchitekturDas Grundprinzip ist einfach gehalten:
|
Werbung für Python |
Dieses Pull-Verfahren hat einen praktischen Vorteil: Die Zugangsdaten für die Verbindung liegen nur auf meinem eigenen NAS, nicht auf dem Hosting-Server. Zusammen mit der verschlüsselten SSH-Übertragung und der inkrementellen Synchronisation von Rsync (es werden nur geänderte Daten übertragen, nicht jedes Mal alles neu) ergibt das eine saubere, ressourcenschonende Lösung – zumindest in der Theorie.
Wo es klemmte
In der Praxis türmten sich mehrere Fehler nacheinander auf, wie es bei Erstinbetriebnahmen öfter vorkommt:
Zuerst schlug die Host-Key-Prüfung fehl – ein SSH-Sicherheitsmechanismus, der verhindert, dass man sich versehentlich mit einem falschen oder manipulierten Server verbindet. Nachdem das gelöst war, verweigerte der Server die Authentifizierung mit einer „Permission denied"-Meldung. Und an einer Stelle wurde es richtig unangenehm: Nach mehreren fehlgeschlagenen Verbindungsversuchen in kurzer Zeit sperrte der Hosting-Server die SSH-Verbindung vorübergehend komplett – eine automatische Schutzmaßnahme gegen Brute-Force-Angriffe, die in diesem Moment allerdings genau mir im Weg stand.
Die eigentliche Ursache
Die Protokolle zeigten den entscheidenden Hinweis: „Too many authentication failures" – zu viele fehlgeschlagene Authentifizierungsversuche. Bei der genaueren Untersuchung stellte sich heraus: Der öffentliche SSH-Schlüssel war auf dem Server nur unvollständig gespeichert. Ein SSH-Schlüssel ist eine einzige, lange Zeichenkette – fehlt auch nur ein Zeichen beim Kopieren, schlägt die Authentifizierung fehl, meist ohne einen offensichtlichen Hinweis darauf, dass genau das der Grund ist.
Die Lösung
Der öffentliche Schlüssel wurde erneut vollständig aus OpenMediaVault exportiert und sorgfältig in die Datei authorized_keys auf dem Server eingetragen. Wichtig dabei: Vorhandene ältere Schlüssel wurden nicht gelöscht, sondern blieben in separaten Zeilen bestehen – jede Zeile in dieser Datei ist ein eigenständiger, gültiger Zugang, unabhängig von den anderen. Nach dem Speichern lief der Testlauf durch: vollständige Synchronisation, keine weiteren Fehlermeldungen.
Sicherheit: warum SSH-Schlüssel statt Passwort
Für die Authentifizierung kommt bewusst ein SSH-Schlüsselpaar zum Einsatz, kein Passwort. Das hat zwei Vorteile: Es muss kein Passwort in der Backup-Konfiguration hinterlegt werden, das im Ernstfall in falsche Hände geraten könnte, und die gesamte Übertragung läuft ohnehin verschlüsselt über SSH. Für produktive Umgebungen gilt trotzdem: Schlüssel sollten regelmäßig überprüft und Backup-Protokolle im Blick behalten werden – „einmal eingerichtet, nie wieder angeschaut" ist auch bei automatisierten Systemen keine gute Idee.
Betrieb und Wartung
Mit dem funktionierenden Schlüssel läuft die Sicherung jetzt automatisiert über den Zeitplan von OpenMediaVault – ganz ohne manuelles Eingreifen. Für den laufenden Betrieb sind drei Dinge sinnvoll:
- Regelmäßig die verfügbare Speicherkapazität auf dem NAS prüfen
- Die Anzahl der aufbewahrten Akeeba-Backups begrenzen, damit der Speicher nicht unkontrolliert vollläuft
- Gelegentlich eine Testwiederherstellung durchführen – ein Backup, das man nie zurückgespielt hat, ist im Ernstfall eine Wundertüte
Fazit
Die Kombination aus Joomla, Akeeba Backup, Rsync und OpenMediaVault ergibt eine zuverlässige, automatisierte und sichere Datensicherung – sobald sie einmal sauber eingerichtet ist. Die größte Hürde lag nicht in der grundsätzlichen Architektur, sondern in einem kleinen, leicht zu übersehenden Detail: einem unvollständig kopierten SSH-Schlüssel. Eine gute Erinnerung daran, dass bei der Fehlersuche oft nicht das große Konzept falsch ist, sondern eine einzelne, unscheinbare Kleinigkeit den ganzen Prozess blockiert.
- Details
- Geschrieben von: Thomas Messer
- Zugriffe: 19
|
Eine persönliche Vorbemerkung: Ich habe viele Jahre mit professionellen Speicherlösungen gearbeitet – bei Unternehmen wie Raytheon, ADIC und Quantum, die damals zu den führenden Anbietern im Enterprise-Storage-Bereich gehörten. Tape Libraries, SAN-Systeme, hochverfügbare Speicherarchitekturen für große Rechenzentren – das war mein Alltag. Umso mehr schätze ich es, wenn eine einfache, elegante
|
Raspberry Pi 4 Raspberry Auswahl |
Lösung genau das leistet, was sie soll: Ein Automatisiertes Joomla-Backup aufs eigene NAS ist so eine Lösung. Kein Overhead, kein Vendor-Lock-in, kein Abo-Modell. Manchmal ist weniger tatsächlich mehr.
Ein Raspberry Pi ist ein erstaunlich kleines Gerät: ein vollständiger Computer auf einer Platine etwa in der Größe einer Kreditkarte, entwickelt von einer britischen gemeinnützigen Stiftung. Prozessor, Arbeitsspeicher, USB-Anschlüsse und WLAN – alles drauf, alles in einem Stück. Der aktuelle Raspberry Pi 5 mit 4 GB RAM ist derzeit für rund 60 bis 70 Euro erhältlich, unter anderem direkt bei Amazon. Hinzu kommen ein Netzteil und eine microSD-Karte als Systemspeicher – insgesamt kommt man für einen einfachen Einstieg mit etwa 80 bis 100 Euro aus.
- Details
- Geschrieben von: Thomas Messer
- Zugriffe: 38
Weiterlesen: Raspberry Pi als Heimserver – OpenMediaVault macht aus dem Mini-Computer ein NAS
