Offsite-Backup fürs Homelab: die dritte Kopie

Das Backup im feuerfesten Tresor neben dem Server ist eine schöne Idee – bis zu dem Tag, an dem der ganze Raum das Problem ist. Die dritte Kopie gehört woandershin, und „woandershin“ hat mehr Möglichkeiten, als die meisten Anleitungen zugeben.

Die Kurzantwort

Eine Offsite-Kopie ist eine Kopie, die weder Gebäude noch Stromleitung noch Zugangsdaten mit dem Original teilt [17]. Für ein Homelab gibt es vier realistische Wege: einen zweiten Standort in Eigenregie, eine gemietete Storage Box per SFTP, S3-kompatiblen Objektspeicher oder ein Cloud-Laufwerk für Privatkunden, das du über rclone ansprichst. Entscheide nach fünf Kriterien: welches Protokoll dein Backup-Werkzeug spricht, ob vor dem Hochladen verschlüsselt wird, was Speichern und Wiederherstellen kosten, wie gut die Kopie gegen Löschen geschützt ist und wie lange der erste Upload dauert. Unsere Einschätzung: Mit restic oder Borg passt eine Storage Box oder ein S3-Bucket am einfachsten. Produkte für „unbegrenztes Computer-Backup“ sind für Desktop-Rechner gebaut und nicht für Server oder NAS [8][9].

So funktioniert’s

1. Was „offsite“ heißen muss. Der BSI-Baustein zum Datensicherungskonzept verlangt, die Speichermedien der Datensicherung räumlich getrennt von den gesicherten Systemen aufzubewahren, und empfiehlt einen anderen Brandabschnitt [17]. Derselbe Baustein hält fest, dass eine Spiegelung über RAID keine Datensicherung ist: Die Spiegelung ändert sich im selben Moment wie das Original und schützt weder vor Überschreiben noch vor Schadsoftware [17]. Für Online-Speicher nennt er, was vertraglich zu regeln ist: Ort der Datenspeicherung, Dienstgüte, Authentisierung, Verschlüsselung auf dem Speicher und auf dem Transportweg [17]. Dieser Guide baut auf der 3-2-1-Regel aus unserem Backup-Grundlagenartikel auf. Hier klären wir nur, wo die „1“ liegt.
2. Verschlüsseln, bevor die Daten das Haus verlassen. restic verschlüsselt alles, was es ablegt, mit AES-256 im Counter-Modus, sichert es mit Poly1305-AES ab und leitet die Schlüssel mit scrypt aus deinem Passwort ab [16]. Das passiert auf deinem Rechner, der Anbieter sieht also nur Chiffretext. Bei Borg ist es genauso; unser Guide zu restic oder Borg erklärt das. Für Werkzeuge ohne eingebaute Verschlüsselung legt der crypt-Remote von rclone eine Schicht um jeden anderen Remote und verschlüsselt Inhalte (NaCl SecretBox) und standardmäßig auch Dateinamen [13]. Die Folge übersieht man leicht: Wenn dein Werkzeug selbst verschlüsselt, brauchst du kein „Zero-Knowledge“-Zusatzpaket des Anbieters. pCloud verkauft die clientseitige Verschlüsselung zum Beispiel als eigenes, separat bepreistes Produkt neben den Speichertarifen [10]. Die Kehrseite ist der Schlüssel. restic schreibt, dass ein verlorenes Passwort die Daten unwiederbringlich verloren macht [14], und rclone crypt braucht Passwort und Konfiguration [13]. Bewahre beides getrennt vom Repository und getrennt vom gesicherten Rechner auf.
3. Zieltyp 1: ein zweiter Standort in Eigenregie. Es gibt vier Arten von Zielen, und jede tauscht Aufwand gegen Kosten und Kontrolle. Gemeint ist hier die Wohnung von Verwandten, ein Büro oder die Garage von Freunden. restic schreibt per SFTP in ein Verzeichnis oder an einen REST-Server, den du dort betreibst [14]. Du zahlst keine Speichergebühr, besitzt dafür aber Platte, Strom, Router und Upload-Leitung an beiden Enden. Außerdem muss jemand das Gerät nach einem Stromausfall wieder einstecken.
4. Zieltyp 2: eine Storage Box über SSH. Die Storage Box von Hetzner ist ein Beispiel. Die Produktseite nennt SFTP, SCP, rsync, BorgBackup, restic, rclone, WebDAV und SMB, unbegrenzten Traffic, Snapshots, Deutschland oder Finnland als Standort, keine Mindestlaufzeit und sofortige Kündigung [1]. Die Dokumentation von Hetzner sagt, dass restic über SFTP nativ funktioniert und zusätzlich über das rclone-Backend, und nennt die Borg-Versionen 1.1, 1.2 und 1.4 [3]. Zwei Details zählen. Die Platten arbeiten in einem RAID-Verbund auf einem einzelnen Hostserver, die Daten werden nicht auf andere Server gespiegelt [1][2]. Das passt für eine dritte Kopie und ist als einzige Kopie dünn. Snapshots liegen auf der Box selbst und belegen deren Speicherplatz [2].
5. Zieltyp 3: S3-kompatibler Objektspeicher. Backblaze B2 ist ein Beispiel. restic dokumentiert jeden S3-kompatiblen Dienst über s3:https://server:port/bucket und empfiehlt für B2 die S3-Schnittstelle statt des nativen B2-Backends [14]. B2 behält alte Dateiversionen standardmäßig „versteckt“ vor, deshalb empfiehlt die restic-Dokumentation die Lifecycle-Regel „Keep only the last version of the file“, damit der Platz frei wird [14]. B2 bietet außerdem Object Lock, das Dateien für 1 bis 3.000 Tage vor Änderung und Löschung schützt. Hast du es für einen Bucket eingeschaltet, lässt es sich nicht mehr abschalten [6]. Backblaze warnt, bei Backup-Software die Aufbewahrung in der Software zu setzen und nicht als Bucket-Vorgabe, weil die Kombination zu unvorhersehbarem Datenverlust führen kann [7].
6. Zieltyp 4: ein Cloud-Laufwerk für Privatkunden. pCloud ist ein Beispiel. rclone unterstützt es über ein OAuth-Token und weist darauf hin, dass gelöschte Dateien je nach Tarif eine Zeit lang im Papierkorb bleiben [12]. restic kann jeden rclone-Remote nutzen [14]. pCloud bietet Abos und einmalig bezahlte Lifetime-Tarife an [11]. Wir haben keine pCloud-Dokumentation gefunden, die Server-Backups mit restic beschreibt. Die Kombination beruht auf dem rclone-Backend. Für kleine Datenmengen ist sie brauchbar, für ein Repository, das du unter Druck wiederherstellen musst, ist sie die schwächere Wahl.
7. Computer-Backup-Produkte sind eine andere Kategorie. Backblaze Computer Backup sichert keine Netzlaufwerke, Freigaben oder NAS-Geräte und sagt das in der Dokumentation selbst [8]. Linux, BSD und Unix sowie jede Variante von Windows Server stehen dort als nicht unterstützt [9]. Für ein NAS verweist Backblaze auf B2, mit fertigen Anbindungen für Synology, QNAP und TrueNAS [8]. Ein Hinweis zum Geld, denn die Kriterien kommen zuerst: Sollte die Seite einmal ein Partnerprogramm für Backblaze verlinken, gilt die Provision nur für Computer Backup, nicht für B2 und nicht für NAS-Sicherungen. An dieser Einschätzung ändert sie nichts.
8. Kosten wachsen mit der Datenmenge, die Wiederherstellung auch. Rechne so: Monatskosten = gespeicherte Terabyte × Preis je Terabyte + Restore-Traffic + Extras. Beispiele mit den Preisen von den Anbieterseiten am 24. Okt. 2026 stehen in der Tabelle unter der Liste. Das sind Listenpreise, keine Angebote. Die Preise von Hetzner verstehen sich ohne Mehrwertsteuer [1], der B2-Satz auf dieser Seite gilt für die Region US West [5], und die beiden Währungen rechnen wir hier nicht um. Eine Wiederherstellung von 1 TB bei 1 TB Speicher bleibt in B2 im kostenlosen Rahmen. Egress über diesen Rahmen hinaus kostet 0,01 $ pro GB, also etwa 10 $ je zusätzlichem Terabyte [5]. Die Tarife von pCloud lassen sich nicht in eine Zeile pressen, schau auf die aktuelle Preisseite [11]. Rechne in jedem Fall die Kosten eines Test-Restores ein (Schritt 10).
9. Der erste Upload ist die eigentliche Rechnung. Upload-Dauer = Datenmenge ÷ Upload-Geschwindigkeit. Ein Terabyte sind 8 × 10¹² Bit. Bei angenommenen 50 Mbit/s im Upstream dauert das bei voller Leitungsgeschwindigkeit 44 Stunden, in der Praxis länger. Plane Tage statt Minuten. Drossle den Job, damit er deinen übrigen Verkehr nicht erstickt: restic-Setups über rclone akzeptieren ein Bandbreitenlimit über die Variable RCLONE_BWLIMIT [14]. Ist die Leitung zu langsam, befülle die erste Kopie am zweiten Standort oder beginne mit den Daten, die du nicht neu erzeugen kannst.
10. Teste die Wiederherstellung, und zwar an der Offsite-Kopie. restic check prüft die Struktur eines Repositorys. --read-data liest alle Pack-Dateien und lädt damit das ganze Repository herunter, was Bandbreite und Zeit kosten kann. --read-data-subset prüft pro Lauf nur einen Teil, zum Beispiel 10% oder 1/5 [15]. Ein bestandener Check zeigt, dass das Repository heil ist. Er zeigt nicht, dass du wiederherstellen kannst, was du brauchst. Stelle in ein leeres Verzeichnis auf einem zweiten Rechner wieder her, nur mit dem getrennt aufbewahrten Passwort, und notiere, wie lange es gedauert hat.

Preise von den Seiten der Anbieter, 24. Okt. 2026 (dieselben Werte wie in Schritt 8):

Ein Homelab-Beispiel

So könnte ein Aufbau aussehen. Es ist ein Beispiel und kein Bericht über unsere Systeme, und wir sagen nichts darüber, welches Backup-Ziel wir nutzen. Angenommen, es gibt ein lokales restic-Repository unter /mnt/backup/restic-lokal und eine Hetzner Storage Box mit einem Unterkonto für Backups.

Zuerst ein SSH-Alias in ~/.ssh/config. Die Storage Box nimmt SFTP auf Port 22 und, sobald die SSH-Unterstützung aktiviert ist, auf Port 23 an. Von außerhalb des Hetzner-Netzes, etwa von deinem Heimanschluss, musst du im selben Einstellungsdialog zusätzlich „External Reachability“ einschalten [3]. Das restic-Tutorial in der Hetzner-Community nutzt Port 23 und einen Schlüssel im OpenSSH-Format [3][4]:

Host offsite-box
  Hostname u123456.your-storagebox.de
  Port 23
  User u123456
  IdentityFile ~/.ssh/restic_offsite
  ServerAliveInterval 60
  ServerAliveCountMax 240

Dann legst du das entfernte Repository mit denselben Chunker-Einstellungen wie das lokale an und kopierst die Snapshots hinüber. restic braucht die Passwörter beider Repositorys [15]:

restic -r sftp:offsite-box:./restic-offsite init --from-repo /mnt/backup/restic-lokal --copy-chunker-params
restic -r sftp:offsite-box:./restic-offsite copy --from-repo /mnt/backup/restic-lokal

Für einen S3-Bucket sieht dieselbe Idee so aus. Endpunkt und Bucket-Name stehen in der Konsole deines Anbieters, und restic erwartet bei Nicht-Amazon-Diensten Pfad-URLs [14]:

export AWS_ACCESS_KEY_ID=<key-id>
export AWS_SECRET_ACCESS_KEY=<secret>
restic -r s3:https://<s3-endpunkt-deines-buckets>/<bucket> init

Prüfe nach jedem Kopieren einen Teil des Offsite-Repositorys und mache einmal im Quartal einen vollständigen Restore-Test:

restic -r sftp:offsite-box:./restic-offsite check --read-data-subset=5%
restic -r sftp:offsite-box:./restic-offsite restore latest --target /tmp/restore-offsite

Wo passt die Alternative ohne Partnerprogramm hin? Für restic- oder Borg-Nutzer in Deutschland mit ein paar Terabyte hat eine Storage Box einen festen Preis, keine Traffic-Gebühren und ein SFTP-Ziel, das beide Werkzeuge nativ unterstützen [1][3]. Wir sehen keinen Grund, dich zu einem Anbieter mit Partnerprogramm zu schieben, wenn der ohne besser passt. B2 passt, wenn du eine S3-Schnittstelle, Object Lock oder eine NAS-App brauchst, die S3 spricht. Ein Cloud-Laufwerk wie pCloud passt, wenn du es ohnehin bezahlst und die Datenmenge klein bleibt.

Prüfliste

• Lege fest, was einen Brand im Haus überleben muss, und führe diese Verzeichnisse zuerst auf.
• Prüfe, ob das Offsite-Ziel in einem anderen Gebäude und hinter anderen Zugangsdaten liegt als das Original.
• Stelle sicher, dass dein Backup-Werkzeug vor dem Hochladen verschlüsselt, oder setze rclone crypt vor den Remote.
• Bewahre das Repository-Passwort und ein eventuelles rclone-Passwort getrennt vom Repository und vom gesicherten Rechner auf.
• Vergleiche Ziele nach Preis je Terabyte, Restore-Traffic, Mindestlaufzeit sowie Snapshot- oder Lock-Funktionen, jeweils mit der Seite des Anbieters und ihrem Datum.
• Rechne den ersten Upload mit deiner echten Upstream-Geschwindigkeit und drossle den Job.
• Schalte eine Lifecycle- oder Aufbewahrungsregel erst ein, nachdem du gelesen hast, wie sie mit deiner Backup-Software zusammenspielt.
• Führe nach jedem Kopieren check mit --read-data-subset aus und einmal im Quartal einen vollständigen Restore auf einem zweiten Rechner.
• Notiere Datum, Dauer und Ergebnis jedes Restore-Tests.