Offsite-Backup einrichten: Storage Box oder Objektspeicher

Die Kopie außer Haus ist der Teil der 3-2-1-Strategie, der am häufigsten fehlt. Nicht weil er schwierig wäre, sondern weil die lokale Sicherung sich bereits sicher anfühlt. Sie schützt nur eben nicht gegen Brand, Wasser, Einbruch und Blitzschlag – also gegen genau die Fälle, in denen man ein Backup wirklich braucht.

Dieser Artikel zeigt die zwei praktikablen Wege dorthin und die Fallstricke, die man erst bemerkt, wenn man zurückspielen muss.

Die zwei Wege

Für Homelabs und Kleinbetriebe kommen realistisch zwei Arten von Zielen infrage:

SFTP-/SSH-Speicher („Storage Box“, „Backup Space“ und Ähnliches). Ein Verzeichnis auf einem fremden Server, erreichbar über SSH, SFTP, rsync, teils SMB oder WebDAV. Viele Anbieter erlauben zusätzlich BorgBackup direkt auf der Gegenseite.

Objektspeicher (S3 und S3-kompatible Dienste). Kein Dateisystem, sondern eine API: Objekte in Buckets. Dafür kommen Funktionen dazu, die es beim SFTP-Speicher nicht gibt – vor allem Objekt-Sperren.

	SFTP-Speicher	Objektspeicher
Bedienung	wie ein Verzeichnis	über API/Client
Werkzeuge	rsync, Borg, restic, PBS-Sync	restic, rclone, PBS je nach Version
Unveränderlichkeit	über Append-only-SSH oder Snapshots	Objekt-Sperre
Abrechnung	meist feste Kapazität	Speicher + Zugriffe + Rückübertragung
Rückweg-Kosten	in der Regel enthalten	anbieterabhängig, siehe unten
Eignung	einfach, planbar	flexibler, sicherer, komplexer

Kurzfassung: Wenn du Borg einsetzt oder einen PBS zu PBS synchronisieren willst, nimm SFTP-Speicher. Wenn du restic einsetzt oder Unveränderlichkeit auf Objektebene brauchst, nimm Objektspeicher.

Welches Werkzeug zu dir passt, klärt restic, Borg oder PBS?.

Die Kostenfalle: Rückübertragung

Das ist der Punkt, der die meisten Vergleiche unbrauchbar macht, weil er im Preisblatt nicht in der großen Zahl steht.

Bei Objektspeichern gibt es typischerweise drei Kostenarten:

1. Speicher       pro TB und Monat        -> steht immer im Angebot
2. Anfragen       pro 1000 Operationen    -> meist vernachlaessigbar
3. Rueckuebertragung (Egress)             -> die Ueberraschung

Die dritte Position fällt genau dann an, wenn du sie am wenigsten brauchen kannst: beim Restore nach einem Schaden. Manche Anbieter berechnen sie voll, andere gewähren ein Freikontingent, wieder andere verzichten ganz darauf – bei einzelnen ist der Verzicht an Mindestspeicherdauern geknüpft.

Prüfe vor der Anbieterwahl genau drei Dinge:

1. Was kostet die vollständige Rückübertragung deines gesamten Bestands?
2. Gibt es eine Mindestspeicherdauer? Wenn ja, wie wirkt sie sich auf deine Prune-Regeln aus – Daten, die vor Ablauf gelöscht werden, werden oft trotzdem berechnet.
3. Unterstützt der Anbieter Objekt-Sperren? Ohne sie fehlt dir die „1“ aus 3-2-1-1-0.

Vorab: verschlüsseln, immer

Sobald Daten das Haus verlassen, gehören sie verschlüsselt – und zwar bevor sie übertragen werden, nicht erst beim Anbieter.

Der Grund ist nicht Misstrauen gegenüber einem konkreten Anbieter, sondern die simple Tatsache, dass du die Kontrolle abgibst. Clientseitige Verschlüsselung macht die Frage, wie gut der Anbieter seine Systeme absichert, für deine Daten irrelevant.

restic tut das automatisch. Bei Borg und PBS ist es eine bewusste Entscheidung beim Anlegen. Wie du den Schlüssel so verwahrst, dass du ihn im Ernstfall auch hast: Backup-Verschlüsselung.

Weg 1: restic gegen Objektspeicher

Der geradlinigste Aufbau, weil restic S3 direkt spricht.

Zugangsdaten anlegen. Beim Anbieter einen Bucket und dazu einen eigenen Anwendungsschlüssel erstellen – nicht die Hauptzugangsdaten des Kontos verwenden. Der Schlüssel sollte nur auf diesen einen Bucket zugreifen dürfen.

Berechtigungen einschränken. Wenn der Anbieter es unterstützt: Schreiben und Lesen erlauben, Löschen und Überschreiben verbieten. Das ist der eigentliche Schutz gegen ein kompromittiertes Quellsystem.

Repository anlegen:

export RESTIC_REPOSITORY="s3:https://<endpunkt>/<bucket>"
export AWS_ACCESS_KEY_ID="<schluessel-id>"
export AWS_SECRET_ACCESS_KEY="<geheimnis>"
export RESTIC_PASSWORD_FILE="/root/.restic-passwort"

restic init

Sicherung ausführen:

restic backup /pfad/zu/daten --verbose

Aufräumen – zwei getrennte Schritte, siehe Backup-Aufbewahrung planen:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic prune

forget entfernt nur die Snapshot-Verweise. Erst prune gibt Speicher frei – und prune braucht Löschrechte. Wenn du die Zugangsdaten wie oben empfohlen ohne Löschrechte ausgestattet hast, läuft der Aufräumlauf mit einem zweiten, getrennten Schlüssel, der nicht auf dem gesicherten System liegt. Genau das ist der Sinn der Trennung.

Automatisieren. Ein systemd-Timer ist einem Cron-Eintrag vorzuziehen, weil sich Fehlschläge sauber auswerten lassen – siehe Backup-Monitoring. Die Zugangsdaten gehören in eine Datei mit chmod 600, nicht in die Kommandozeile: Argumente sind auf dem System für jeden sichtbar, der ps ausführen kann.

Weg 2: Proxmox Backup Server nach außen spiegeln

Wenn du bereits einen PBS betreibst, soll dessen Datastore nach außen repliziert werden.

Der saubere Weg dafür sind Sync-Jobs zwischen zwei PBS-Instanzen. Die entfernte Instanz wird als Remote eingetragen, danach zieht oder schiebt ein Sync-Job die Sicherungen.

Zwei Punkte, die dabei zählen:

Zugriffsrichtung. Wenn die entfernte Instanz die Daten zieht (Pull), braucht das lokale System keine Zugangsdaten für das Ziel. Ein Angreifer auf dem lokalen System kommt dann nicht an die Offsite-Kopie. Deutlich sicherer als der umgekehrte Weg.

Getrennte Aufbewahrung. Der Sync-Job überträgt auch Löschungen, wenn er so konfiguriert ist. Die entfernte Instanz sollte deshalb eigene, längere Prune-Regeln haben. Sonst repliziert ein versehentliches Löschen brav nach außen.

Wenn keine zweite PBS-Instanz zur Verfügung steht, bleibt der Umweg über eine Dateisynchronisation des Datastore-Verzeichnisses. Das funktioniert, hat aber eine harte Bedingung: Der Datastore darf während der Übertragung nicht durch Backup-, Prune- oder GC-Jobs verändert werden. Sonst überträgst du einen inkonsistenten Stand. In der Praxis heißt das: Zeitfenster festlegen, Jobs entsprechend planen – und den Restore aus dieser Kopie unbedingt einmal testen.

Bandbreite realistisch einplanen

Der Erstlauf überträgt alles, danach nur noch Änderungen. Die relevante Frage ist deshalb nicht „wie lange dauert das erste Backup“, sondern „wie lange dauert der Restore“.

Reine Übertragungszeit, ohne Entschlüsseln und Prüfsummen:

  500 GB bei 100 Mbit/s  ->  ca. 11-12 Stunden
    1 TB bei 100 Mbit/s  ->  ca. 23-24 Stunden
    1 TB bei 250 Mbit/s  ->  ca.  9-10 Stunden

Vergleiche das mit deinem RTO aus der 3-2-1-Strategie. Wenn die Zahlen nicht zusammenpassen, ist die Konsequenz nicht „mehr Bandbreite kaufen“, sondern: Die Offsite-Kopie ist für den Katastrophenfall da, nicht für den Alltag. Der normale Restore läuft über die lokale Kopie.

Für den Erstlauf gilt zusätzlich: Er blockiert je nach Uplink tagelang die Leitung. Entweder man drosselt ihn – restic und rsync können das – oder man legt ihn auf ein Wochenende.

Checkliste Offsite

• Ziel liegt tatsächlich an einem anderen Standort
• Daten werden vor der Übertragung verschlüsselt
• Der Schlüssel liegt nicht nur auf dem gesicherten System
• Eigene Zugangsdaten nur für dieses Backup, nicht die Kontohauptdaten
• Löschrechte getrennt vom Sicherungszugang
• Objekt-Sperre oder Append-only aktiv
• Eigene Aufbewahrungsregeln am Ziel, nicht bloß gespiegelte
• Restore-Dauer gemessen und mit dem RTO abgeglichen
• Kosten der vollständigen Rückübertragung bekannt
• Fehlschläge lösen eine Benachrichtigung aus
• Ein Restore aus der Offsite-Kopie wurde durchgeführt – nicht nur aus der lokalen

Der letzte Punkt fehlt am häufigsten. Die lokale Sicherung testet fast jeder irgendwann; die entfernte fast niemand. Verfahren dafür: Restore testen.

Weiter im Cluster

• 3-2-1-Backup-Strategie – warum die dritte Kopie
• restic, Borg oder PBS? – Werkzeugwahl
• Backup-Verschlüsselung – Pflicht vor dem Versand
• Ransomware-sichere Backups – Objekt-Sperren im Detail
• Backup-Aufbewahrung planen – Regeln am Ziel
• Typische Backup-Fehler