Ein halbes Jahr später: ehrliche Zwischenbilanz
Vor rund einem halben Jahr habe ich hier beschrieben, warum die großen Tech-Konzerne enormen Einfluss auf unser digitales Leben haben – und warum der Weg zur digitalen Souveränität zwar nicht einfach und nicht kostenlos ist, aber lohnenswert. Zeit für eine ehrliche Zwischenbilanz: Was hat sich seitdem tatsächlich getan?
- Details
- Geschrieben von: Thomas Messer
- Zugriffe: 11
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: 13
