Stand: 15.10.2026

Eine Hetzner Storage Box richten Sie für belastbare Server-Backups am sinnvollsten über SSH auf Port 23 und BorgBackup ein. Entscheidend sind ein eigener Zugang beziehungsweise ein Sub-Account, SSH-Schlüssel statt Passwort, verschlüsselte Borg-Repositories und ein regelmäßig getesteter Restore.

Für KMU ist die Storage Box damit kein Ersatz für ein Backup-Konzept, sondern dessen externes Ziel: Die Sicherung entsteht auf dem Produktivsystem und wird getrennt abgelegt. Dieser Leitfaden zeigt den technischen Grundaufbau mit Befehlen, die Sie an Ihre Umgebung anpassen müssen.

Auf einen Blick

  • SSH, rsync und BorgBackup greifen laut Hetzner über Port 23 auf die Storage Box zu.
  • Aktivieren Sie in der Hetzner Console SSH-Support; für Zugriffe außerhalb des Hetzner-Netzes zusätzlich die externe Erreichbarkeit.
  • Verwenden Sie einen SSH-Schlüssel und speichern Sie Borg-Passphrase sowie Schlüsselmaterial getrennt vom Server.
  • Borg verschlüsselt und dedupliziert Backups; ein Restore-Test gehört trotzdem in den Betriebsplan.

Welche Vorbereitung braucht eine Hetzner Storage Box?

Notieren Sie aus der Hetzner Console den Storage-Box-Hostnamen und den Benutzernamen. Aktivieren Sie dort den SSH-Support. Soll ein Server außerhalb des Hetzner-Netzes sichern, muss außerdem die externe Erreichbarkeit aktiviert sein. Hetzner dokumentiert dafür den SSH-Zugang über Port 23; eine vollwertige Shell steht dabei nicht zur Verfügung. Das genügt für Borg und rsync.

Trennen Sie technische Zugänge: Ein eigener Sub-Account pro Server oder pro Mandant begrenzt die Folgen eines kompromittierten Systems und erleichtert die Zuordnung. Legen Sie außerdem fest, welche Daten gesichert werden, wie lange sie aufbewahrt werden und wer einen Restore freigibt. Bei virtuellen Servern gehört das in die Betriebsdokumentation Ihrer Proxmox-Backup- und Betriebsstrategie; bei Webdiensten sollten Konfiguration, Datenbank-Dumps und Anwendungsdaten gemeinsam betrachtet werden.

Wie richten Sie SSH-Schlüssel ein?

Erzeugen Sie den Schlüssel auf dem Quellsystem, nicht auf der Storage Box. Ein passender Startpunkt ist:

ssh-keygen -t ed25519 -f /root/.ssh/storagebox_ed25519 -C "backup-server-01"

Hinterlegen Sie anschließend den Inhalt der Datei storagebox_ed25519.pub in der Hetzner Console für den vorgesehenen Zugang. Prüfen Sie die Verbindung bewusst vor dem ersten Backup:

ssh -i /root/.ssh/storagebox_ed25519 -p 23 uXXXXX@uXXXXX.your-storagebox.de

Ersetzen Sie uXXXXX und den Hostnamen durch die tatsächlichen Werte. Ein Login ohne Passwortabfrage zeigt, dass Schlüssel und Berechtigungen passen. Private Schlüssel gehören mit restriktiven Dateirechten auf das Quellsystem und nicht in ein Repository oder Ticket. Wenn mehrere Personen Zugriff brauchen, verwenden Sie getrennte Schlüssel je Person oder Automatisierung statt eines geteilten Schlüssels.

Wie wird BorgBackup auf der Storage Box initialisiert?

Borg speichert verschlüsselte, deduplizierte Archive in einem Repository. Hetzner unterstützt dafür Borg über SSH-Port 23 und empfiehlt, die entfernte Borg-Version explizit anzugeben. Das vermeidet Überraschungen, wenn Client und Storage Box unterschiedliche Versionen verwenden. Prüfen Sie zuerst lokal die installierte Version mit borg --version.

Das folgende Beispiel erstellt ein Repository im Ordner borg-repository. Die Borg-Dokumentation verlangt beim Initialisieren einen Verschlüsselungsmodus; repokey ist dort die allgemeine Empfehlung bei einer starken, einzigartigen Passphrase:

export BORG_RSH='ssh -i /root/.ssh/storagebox_ed25519 -p 23'; export BORG_REPO='ssh://uXXXXX@uXXXXX.your-storagebox.de:23/./borg-repository'; borg init --encryption=repokey --remote-path=borg-1.4 "$BORG_REPO"

Die Passphrase wird beim ersten Lauf abgefragt. Sie ist kein Detail: Ohne Passphrase und Borg-Schlüssel kann ein verschlüsseltes Repository nicht sinnvoll wiederhergestellt werden. Exportieren und verwahren Sie das Schlüsselmaterial daher getrennt von Server und Storage Box, zum Beispiel in einem zugriffsgeschützten Passwortmanager oder einem dokumentierten Notfallverfahren. Die konkrete Aufbewahrung richtet sich nach Ihrem Berechtigungskonzept.

Wie erstellen Sie ein erstes verschlüsseltes Backup?

Starten Sie mit einem kleinen, nachvollziehbaren Umfang. Bei einem Linux-Server sind etwa Anwendungsdaten und Konfigurationen typische Kandidaten; virtuelle Maschinen oder Datenbanken brauchen je nach Plattform einen konsistenten Sicherungsweg. Borgs Beispielbefehl könnte so aussehen:

borg create --stats --compression lz4 "$BORG_REPO"::{hostname}-{now:%Y-%m-%d_%H-%M} /etc /srv

Das ist absichtlich kein Befehl zum Sichern des gesamten Root-Dateisystems. Prüfen Sie Ausschlüsse für flüchtige Pfade wie /proc, /sys, temporäre Daten und Mountpoints sowie die Konsistenz von Datenbanken. Für viele Systeme ist ein geplanter Datenbank-Dump vor dem Borg-Lauf sinnvoll. Die Storage Box ist das Ziel, aber die Verantwortung für eine wiederherstellbare Datenauswahl bleibt beim Betriebsteam.

Für eine einfache Spiegelung einzelner Verzeichnisse ist rsync möglich. Hetzner weist jedoch darauf hin, dass sich damit nicht der gesamte Server sichern lässt und empfiehlt für solche Aufgaben ein Backup-Werkzeug wie Borg. --delete bei rsync löscht Dateien am Ziel, die an der Quelle nicht mehr vorhanden sind; setzen Sie diese Option nur ein, wenn das Aufbewahrungskonzept das ausdrücklich vorsieht.

Wie prüfen Sie Backup und Wiederherstellung?

Ein erfolgreicher Job beweist nur, dass ein Prozess gelaufen ist. Prüfen Sie zunächst die Archive:

borg list "$BORG_REPO"; borg check --repository-only --remote-path=borg-1.4 "$BORG_REPO"

Die Borg-Dokumentation unterscheidet die Repository-Prüfung von der Archiv- und Datenprüfung. --verify-data führt eine vollständige kryptografische Integritätsprüfung aus, benötigt aber das Lesen aller Daten und kann entsprechend lange dauern. Planen Sie solche Prüfungen nach Größe und verfügbarem Zeitfenster. Den Reparaturmodus sollten Sie nicht routinemäßig aktivieren: Borg warnt, dass --repair potenziell zu Datenverlust führen kann.

Mindestens ebenso wichtig ist ein echter Test-Restore in ein separates Verzeichnis oder eine isolierte Testumgebung. Dokumentieren Sie Dauer, benötigte Zugangsdaten, Abhängigkeiten und Ergebnis. Der vorhandene Artikel zu Kubernetes Persistent Storage ergänzt das Thema für containerisierte Workloads: Persistenz und Backup müssen zusammen geplant werden, nicht erst nach einem Ausfall.

Was gehört in den laufenden Betrieb?

AufgabeZiel
Backup-Job überwachenFehler und ungewöhnliche Laufzeiten zeitnah erkennen
Aufbewahrung mit Borg prune planenSpeicher und Wiederherstellungspunkte steuern
Schlüssel und Passphrase dokumentierenWiederherstellung auch bei Personalausfall ermöglichen
Restore testenInhalt, Ablauf und benötigte Zeit verifizieren

Behandeln Sie die Storage Box wie einen produktiven externen Dienst: Zugänge regelmäßig prüfen, nicht mehr benötigte Schlüssel entfernen und Änderungen an Backup-Scope oder Infrastruktur nachvollziehbar festhalten. Ergänzend hilft eine IT-Sicherheitsprüfung, wenn Zugriffskonzepte, Härtung und Monitoring über das einzelne Backup hinaus geklärt werden sollen.

Fazit

Eine Hetzner Storage Box ist mit SSH und Borg in wenigen Schritten als externes Backup-Ziel eingerichtet. Die Qualität der Sicherung entscheidet sich aber bei Schlüsselverwaltung, passendem Scope, kontrollierter Aufbewahrung und einem getesteten Restore. Erst wenn sich ein konkreter Dienst wiederherstellen lässt, ist das Backup betriebsbereit.

Sie möchten Backup, Restore-Tests und den Betrieb Ihrer Infrastruktur strukturiert aufsetzen? Vereinbaren Sie ein Erstgespräch oder nutzen Sie die Kontaktseite.

Quellen