TrueNAS Cloud Sync zu AWS S3, Backblaze B2 und Wasabi: wann sich der Hyperscaler-Umweg lohnt

Eine typische Frage aus dem Alltag: “Wir haben ein TrueNAS, das läuft stabil. Wie bekommen wir die Daten zusätzlich in die Cloud – ohne dass die Kosten davonlaufen und ohne dass wir im Ernstfall tagelang auf einen Restore warten?” Die Antwort beginnt selten mit einem Anbieternamen und meistens mit drei Rückfragen: Wie groß ist der Datenbestand, wie oft wird restauriert, und wie viel Zeit darf ein Restore kosten? Erst danach lohnt sich die Entscheidung zwischen AWS S3, Backblaze B2 oder Wasabi – und ob TrueNAS Cloud Sync überhaupt das richtige Werkzeug ist, oder ob eine klassische TrueNAS-zu-TrueNAS-Replikation der sauberere Weg bleibt.

Dieser Artikel ist der Praxisteil zu unserem Cloud-Backup-Anbieter-Vergleich: Dort haben wir die Provider nach Preisstruktur, Egress und EU-Standort sortiert, hier geht es um die konkrete Konfiguration auf einem TrueNAS 25.10 Goldeye-System, um Verschlüsselungsentscheidungen und um die Frage, wann das Hyperscaler-S3 wirklich die beste Antwort ist.

Warum Cloud Sync statt Replikation – und wann umgekehrt

TrueNAS kennt zwei grundlegend verschiedene Wege, Daten aus dem Haus zu schaffen. Beide erscheinen im WebUI unter “Data Protection”, aber sie lösen unterschiedliche Probleme.

ZFS-Replikation sendet Snapshots von einem TrueNAS an ein anderes TrueNAS. Das Zielsystem ist ein kompletter ZFS-Pool, die Replikation ist blockbasiert, inkrementell über Snapshot-Diffs, erhält Rechte, ACLs, Snapshots und Dataset-Struktur. Ein Restore ist in Minuten machbar, weil das Zielsystem die Daten bereits nativ bereithält – im Zweifel bootet man das Replikationsziel und arbeitet weiter.

Cloud Sync dagegen schickt Dateien über ein Protokoll (S3, B2, SFTP, WebDAV und einige mehr) an einen Fremddienst. Zielseitig entsteht ein Objekt-Store oder ein Dateibaum, nicht ein ZFS-Dataset. Snapshots gehen verloren, Rechte sind nur rudimentär, Metadaten entfallen. Dafür ist das Ziel beliebig weit weg, benötigt keine eigene Hardware und erfüllt die “offsite”-Komponente der 3-2-1-Backup-Regel sauber.

Die ehrliche Faustregel aus unserer Beratung: Wer ein zweites TrueNAS in einem anderen Brandabschnitt oder einer Partner-Lokation hat, nutzt dort ZFS-Replikation. Wer das nicht hat oder zusätzlich eine zweite, unabhängige Schiene aufbauen will, nimmt Cloud Sync in Richtung Hyperscaler oder S3-nativen Anbieter. Beides schließt sich nicht aus – im Gegenteil, die Kombination ist der Normalfall.

Cloud Sync konfigurieren: der Weg durch das WebUI

Auf TrueNAS 25.10 Goldeye liegt der Workflow unter Credentials → Backup Credentials für die Zugangsdaten und unter Data Protection → Cloud Sync Tasks für die eigentlichen Jobs. Die Trennung ist kein Zufall: Zugangsdaten gehören in den Credential-Store, damit sie zentral rotierbar bleiben und nicht pro Task doppelt geführt werden.

Credentials anlegen

Für AWS S3 braucht es eine IAM-Benutzerin mit einer Access-Key-Paarung, die ausschließlich Rechte auf genau den Zielbucket hat – nie den Root-Account, nie einen Admin-Key. Backblaze B2 arbeitet mit Application-Keys, die ebenfalls bucket-scoped angelegt werden. Wasabi folgt der AWS-Logik und kennt entsprechend IAM-Policies.

Ein typischer Fehler, den wir regelmäßig aufräumen: Alte TrueNAS-Installationen tragen noch einen globalen “Full Access”-Key, der nach einem Admin-Wechsel niemand mehr rotieren mag. Spätestens wenn jemand kündigt, der Zugriff auf diese Credentials hatte, muss der Key weg – und wenn er zu umfangreich ist, nimmt man gleich das ganze Cloud-Backup mit in Haft. Enger scopen heißt: ruhiger schlafen.

Task-Richtung: PUSH, PULL oder SYNC

TrueNAS Cloud Sync kennt drei Modi.

• PUSH schiebt lokale Daten in die Cloud – der Standard für Backup-Szenarien.
• PULL holt Daten aus der Cloud auf das TrueNAS – nützlich für Restore oder Migration.
• SYNC gleicht beide Seiten ab und löscht in der Cloud, was lokal nicht mehr existiert.

Für Backup ist SYNC gefährlich. Wer lokal eine Datei verliert und das vor dem nächsten Job nicht merkt, hat sie auch in der Cloud nicht mehr. PUSH mit der Option Keep (nicht Replace und erst recht nicht Sync) ist der sichere Modus. Löschen in der Cloud erledigen Lifecycle-Policies im Bucket, nicht die Cloud-Sync-Task selbst.

Schedule und Direction-Modus

Für aktive Datasets reicht meist ein nächtlicher Job. Für hochfrequent geänderte Daten – etwa Fileserver mit Buchhaltung oder Konstruktion – empfiehlt sich alle 4 bis 6 Stunden ein inkrementeller Lauf. Cloud Sync nutzt intern Rclone und erkennt Änderungen zuverlässig anhand von Größe und Zeitstempel, bei S3-Zielen auch über ETag. Wichtig: Bei sehr großen Datasets kann der Vergleichslauf allein mehrere Minuten dauern. Das ist normal.

Verschlüsselung: drei Ebenen, drei Entscheidungen

Verschlüsselung bei Cloud Sync ist kein Schalter, sondern drei Fragen übereinander.

Transportverschlüsselung

Trivialer Teil: Alle drei Anbieter sprechen TLS, Cloud Sync nutzt es standardmäßig. HTTP-Endpunkte deaktivieren, falls aus Legacy-Gründen irgendwo noch aktiv.

Server-Side Encryption (SSE)

Hier beginnt der interessante Teil. SSE-S3 (bei AWS) oder das Äquivalent bei Wasabi und B2 verschlüsselt die Objekte im Bucket mit providerverwalteten Schlüsseln. Das schützt gegen den Diebstahl physischer Disks beim Anbieter, nicht gegen einen kompromittierten API-Key. Es ist der niedrigste gemeinsame Nenner und sollte immer aktiv sein – es kostet nichts extra und bringt die Compliance-Minimalabsicherung.

SSE-KMS (nur AWS) nutzt zusätzlich KMS-Schlüssel, die kundenseitig verwaltet werden. Preislich spürbar, administrativ anspruchsvoller, aber im regulierten Umfeld oft gefordert.

Client-Side Encryption

Die sauberste Variante: Daten werden auf dem TrueNAS verschlüsselt und erreichen den Provider nur als Chiffrat. Der Provider sieht Dateinamen und -größen oder nicht einmal die, je nach Konfiguration. Cloud Sync bietet dafür die Option Encryption im Task selbst – intern verwendet Rclone eine passwort- oder keyfile-basierte Verschlüsselung. Das Keyfile gehört nicht in den Cloud-Bucket und auch nicht nur auf das TrueNAS, sondern zusätzlich an einen zweiten, bewusst getrennten Ort (z.B. Passwort-Tresor der Geschäftsführung, Papier im Safe). Ohne den Schlüssel ist das Backup Datenmüll – ein verlorener Schlüssel bedeutet: Backup verloren.

Unsere Praxisempfehlung: Für Daten mit personenbezogenem oder berufsrechtlichem Charakter (Kanzlei, Praxis, Steuerbüro) Client-Side-Encryption als Pflicht. Für reine Firmendaten ohne besondere Vertraulichkeit genügt SSE-S3 – mit sauberem Key-Management auf Provider-Seite. Mehr dazu in unserem Artikel Backup-Verschlüsselung und Schlüsselverwaltung richtig.

Egress-Kosten: der stille Posten

Storage pro Terabyte ist bei allen drei Anbietern transparent. Die Falle liegt woanders: beim Egress, also beim Herausziehen der Daten im Restore-Fall.

• AWS S3 rechnet Egress pro Gigabyte ab, gestaffelt nach Volumen pro Monat.
• Backblaze B2 gibt pro Monat ein Freivolumen von drei Mal der gespeicherten Datenmenge, danach kostet jedes weitere Gigabyte.
• Wasabi verzichtet komplett auf Egress-Gebühren – dafür gilt eine Mindest-Storage-Zeit von 90 Tagen auch für Objekte, die vorher gelöscht werden.

Für die reine Backup-Strategie bedeutet das: Wer selten restauriert, kommt mit allen drei Modellen gut aus. Wer aber monatliche Restore-Drills fährt (und das sollten alle, siehe Restore-Test-Tag), muss das Egress in die Rechnung einbeziehen – oder bei Wasabi landen, wo es strukturell egal ist.

Rechenbeispiel-Logik ohne harte Zahlen: 10 TB im Backup, einmal pro Quartal ein voller Restore-Test eines einzelnen Datasets von ~500 GB, einmal pro Jahr ein Teil-Restore nach echtem Zwischenfall. Bei AWS und B2 bleibt das Egress-Budget übersichtlich. Bei einem Totalausfall-Szenario mit vollem Rückzug der 10 TB sieht die Rechnung anders aus – dann wird selbst B2 mit seinem Freivolumen deutlich teurer, und bei AWS kommt eine kleinere Hausrechnung zustande, die bei der Geschäftsführung Fragen aufwirft. Diese Spitze gehört in die Risikobetrachtung – nicht in die monatliche Budgetplanung, aber in das Recovery-Konzept.

Restore-Dauer: die Zahl, die man vorher kennen muss

Die ehrlichste Metrik beim Cloud-Backup ist nicht der Preis, sondern die realistische Restore-Dauer. Sie steht und fällt mit der Internet-Anbindung, nicht mit dem Provider.

Grobe Hausrechnung für die Hinleitung: Eine 1-Gbit/s-Leitung schafft brutto etwa 450 GB pro Stunde, netto durch Overhead und Prüfungen deutlich weniger. 10 TB sind damit praktisch nicht an einem Werktag zurückgeholt – auch wenn der Provider das Material in Millisekunden bereitstellen würde. Wer wirklich auf einen 10-TB-Restore in unter 24 Stunden angewiesen ist, muss entweder die Leitung ausbauen (10 Gbit/s symmetrisch ist in Städten verfügbar, auf dem Land nicht trivial) oder ein zweites TrueNAS vor Ort halten.

Das führt zur unbequemen Wahrheit: Cloud Sync ist eine hervorragende letzte Verteidigungslinie gegen Totalverlust, nicht die primäre Recovery-Methode. Primäre Recovery läuft über das lokale Replikat oder den Proxmox Backup Server in einem zweiten Brandabschnitt. Die Cloud fängt den Fall “beides weg” ab – Ransomware, Diebstahl, Totalbrand – und darf dann auch 48 bis 72 Stunden brauchen.

Wann S3 Object-Lock, wann klassischer Rsync-Modus

Innerhalb von S3-Zielen gibt es zwei Konfigurationsstile.

Rsync-ähnlicher Modus

Ohne Object-Lock, mit Lifecycle-Policy für ältere Versionen, mit Cloud Sync im Modus “Keep”. Das ist der klassische Weg: Nächtlicher Push, Versionierung aktiv, nach X Tagen automatische Löschung alter Versionen über die Bucket-Policy. Einfach, günstig im Storage, flexibel in der Pflege.

Immutable-Modus (Veeam-Pattern)

Mit S3 Object-Lock im Compliance Mode: Jedes Objekt ist für eine definierte Retention-Zeit nicht mehr löschbar – auch nicht von der Admin-Rolle, auch nicht vom Root-Account. Das ist der Härtegrad, den Veeam für Immutable-Backups nutzt und den Cyberversicherer zunehmend fordern (mehr dazu in unserem Artikel Cyberversicherung 2026: was Versicherer fordern).

Beide Anbieter – AWS und Wasabi – unterstützen Object-Lock vollständig. B2 unterstützt es ebenfalls, mit leicht abweichender API-Semantik. Für TrueNAS Cloud Sync gilt: Der Lock wird auf Bucket-Ebene aktiviert, nicht in der Cloud-Sync-Task. Cloud Sync schreibt Objekte, die Policy des Buckets macht sie unveränderlich.

Wichtig: Immutable-Backups sind nur dann wirksam, wenn der Angreifer keinen Zugriff auf die Konfiguration des Buckets hat. Das heißt: Multi-Factor-Delete, getrennte Admin-Accounts, und – idealerweise – ein Audit-Trail über CloudTrail (AWS) oder äquivalente Logs. Wer den Lock aktiviert und gleichzeitig den Admin-Key auf dem TrueNAS unverschlüsselt liegen lässt, hat sich eine Illusion gebaut.

Wann welche Variante

• Klassisch (Rsync-Stil): Für Fileserver-Daten mit langer Historie, überschaubarer Vertraulichkeit, bei denen die 3-2-1-Regel durch das lokale Replikat primär erfüllt ist. Cloud ist “nur” die dritte Kopie.
• Immutable: Sobald Ransomware-Risiko dominant ist – also bei allem, was einen Produktionsstopp verursachen würde – oder wenn die Cyberversicherung es verlangt. Immer bei VM-Backups aus Proxmox oder Veeam.

Ein pragmatischer Mittelweg: Zwei Buckets beim gleichen Provider. Der eine klassisch versioniert und per Lifecycle gepflegt (für aktive Datasets), der andere immutable mit 30 bis 90 Tagen Retention (für die Monthly-Snapshots und für Veeam). Cloud Sync läuft als zwei getrennte Tasks, die Verwaltung bleibt übersichtlich.

Welcher Anbieter zu welchem Workload

Die kurze Faustregel aus unseren TrueNAS-Projekten (mehr Hintergrund im TrueNAS-Support und bei der TrueNAS-Konfiguration):

• AWS S3: Wo bereits AWS-Workloads liegen, wo KMS-Verschlüsselung gefordert ist, wo Compliance-Zertifikate (BSI C5, ISO 27001) formal nachgewiesen werden müssen. Oft die teuerste Option bei reinem Storage, aber die mit der tiefsten Integration und den granularsten Policies.
• Backblaze B2: Für Workloads mit wenig Egress und einem klaren Preisrahmen. Technisch solide, S3-kompatibel, EU-Standort in Amsterdam. Gute Wahl für mittelgroße Backups ohne besondere Compliance-Anforderungen.
• Wasabi: Wenn häufige Restores oder regelmäßige Restore-Tests Teil der Strategie sind und die 90-Tage-Mindestlaufzeit toleriert werden kann. Frankfurt-Standort verfügbar.

Für die TrueNAS-eigene Welt existiert außerdem iX-Storj – die Storj-Integration mit Geofencing-Option. Das ist in unserem Anbieter-Vergleichsartikel ausführlich beschrieben; hier führt sie zu weit, weil Storj architektonisch einen eigenen Pfad geht.

Konfigurations-Checkliste

Wer eine neue Cloud-Sync-Task aufsetzt, geht sinnvoll diese Liste durch:

1. Dedizierter Bucket pro TrueNAS, nicht pro Dataset – reduziert Konfigurationsaufwand, erlaubt Bucket-weite Policies.
2. IAM-User oder Application-Key mit Minimalrechten, Rotation vor Admin-Wechsel eingeplant.
3. Server-Side-Encryption aktiviert, bei Bedarf Client-Side-Encryption zusätzlich.
4. Object-Lock aktiv, falls Immutable-Strategie – vor dem ersten Push, nicht nachträglich.
5. Lifecycle-Policy für Versionsmanagement und ggf. Tiering (bei AWS: nach 30 Tagen in Glacier IR, nach 180 in Deep Archive).
6. Multi-Factor-Delete auf dem Bucket.
7. TrueNAS-Task im Modus PUSH mit Keep, nicht Sync.
8. Zeitplan mit Pre-Script für ZFS-Snapshot vorab, damit Cloud Sync einen konsistenten Zeitpunkt kopiert.
9. Monitoring: TrueNAS schickt Job-Benachrichtigungen per E-Mail oder in einen zentralen Alertmanager; Fehlalarme nach drei stillen Tagen prüfen.
10. Restore-Test: Innerhalb der ersten vier Wochen einmal einen Test-Restore eines mittelgroßen Datasets. Die Zahl, die dabei rauskommt (GB pro Minute real), ist die Hausnummer für alle späteren Recovery-Planungen.

Was wir unseren Kunden konkret empfehlen

Für ein typisches TrueNAS-M-Series-System in einem Kanzlei- oder KMU-Umfeld mit 10 bis 40 TB Nutzdaten läuft die Standardarchitektur so: ZFS-Snapshots nach Richtlinie, ZFS-Replikation an ein zweites TrueNAS in anderem Brandabschnitt oder bei einem Partner, Cloud Sync als dritte Schiene in Richtung Wasabi Frankfurt oder B2 Amsterdam mit Object-Lock auf 30 Tage. Die Verschlüsselung läuft client-seitig, der Key liegt bei der Geschäftsführung – nicht nur auf dem Gerät.

Diese Dreier-Konstruktion ist nicht die billigste – aber die ehrlichste. Sie überlebt Hardware-Totalausfall, Standort-Totalausfall und Ransomware mit kompromittierten Admin-Zugängen gleichermaßen. Mehr dazu in unserer Backup-Strategie für KMU mit Proxmox und TrueNAS.

Als autorisierter iXsystems-Partner planen und betreiben wir solche Setups schlüsselfertig. Bei Interesse an einer Bestandsaufnahme der vorhandenen TrueNAS-Umgebung oder einer Neuplanung helfen die IT-Service-Pakete weiter.

FAQ

Kann ich mit TrueNAS Cloud Sync direkt zu Glacier Deep Archive sichern?

Direkt nicht sinnvoll, weil Deep Archive mehrstündige Abrufzeiten hat und die Mindest-Storage-Zeit 180 Tage beträgt. Der saubere Weg: Cloud Sync schreibt in S3 Standard, eine Lifecycle-Policy auf dem Bucket verschiebt Objekte nach 30 Tagen in Glacier IR und nach 180 Tagen in Deep Archive. So bleibt der jüngste Restore schnell, älteres Material wird günstig gelagert.

Lohnt sich für ein kleines KMU mit 2 TB Daten überhaupt der Hyperscaler-Umweg?

Für die reine Datenmenge ist jeder der drei Anbieter wirtschaftlich. Die wichtigere Frage: Gibt es einen zweiten Standort mit TrueNAS? Wenn nein, ist Cloud Sync der einzige saubere “offsite”-Pfad – und dann rechnet sich auch bei 2 TB der Aufwand. Wenn ja, ist die Cloud die dritte Schiene und muss sich nicht um jeden Preis lohnen; sie ist Versicherung, nicht Hauptkomponente.

Was passiert bei Insolvenz des Cloud-Anbieters?

Keiner der drei Anbieter wird morgen pleite gehen – aber die Frage ist berechtigt. Deshalb ist eine Multi-Provider-Strategie bei kritischen Datenbeständen sinnvoll: Primär auf einem Provider, sekundär (nur für wirklich kritische Daten) auf einem zweiten. Zusätzlich: Client-Side-Encryption bedeutet, dass die Daten portabel sind – wer vom Provider wechseln will, zieht sie ab und schiebt sie zu einem anderen S3-kompatiblen Ziel. Vendor-Lock gibt es bei reinem Object-Storage faktisch nicht, solange die Verschlüsselung in eigener Hand liegt.

Reicht nicht ein USB-Platten-Wechselsystem statt Cloud?

Für sehr kleine Umgebungen mit disziplinierter Rotation ja – und wir setzen das auch ein, wo es passt. Zwei Nachteile bleiben: Die Rotation ist manuell und wird in der Praxis oft nachlässig gefahren, und die Platten liegen physisch meistens am gleichen Ort wie das NAS. Für die 3-2-1-Regel braucht es eine echte offsite-Komponente – entweder ein zweites NAS an einem anderen Standort oder ein Cloud-Ziel. USB als zusätzliche Schicht ist fein; als Ersatz für die Cloud ist es Augenwischerei.

Was ist mit dem Grenzübertritt der Daten in US-Hyperscaler?

AWS und Wasabi haben EU-Rechenzentren (Frankfurt bzw. Amsterdam/Frankfurt), B2 ebenfalls (Amsterdam). Bei richtig gesetzter Region bleiben die Daten in der EU. Für personenbezogene Daten ist das die harte Mindestvoraussetzung. Mit Client-Side-Encryption ist der Transfer zusätzlich inhaltlich undurchsichtig – der Provider sieht Chiffrate, nicht Inhalte. Trotzdem gilt: Für Berufsgeheimnisse und besonders schützenswerte Daten ist eine EU-Region plus Client-Side-Verschlüsselung Standard, keine Option.

Wie oft sollte ich einen Cloud-Restore testen?

Mindestens einmal pro Quartal einen Teil-Restore, einmal pro Jahr ein ernsthaftes Szenario mit einem größeren Dataset. Mehr Hintergrund im Artikel Restore-Drill in 30 Minuten. Ein nie getestetes Backup ist kein Backup, sondern eine optimistische Vermutung.

Was kostet mich das realistisch pro Monat?

Dafür gibt es keine seriöse Pauschalantwort – zu viele Variablen (Datenmenge, Egress-Profil, Region, Encryption-Modus, Retention). Was wir im Beratungsgespräch tun: Datenbestand grob kalibrieren, Restore-Frequenz aus dem Betriebsalltag ableiten, dann ein konkretes Angebot auf Basis der aktuellen Provider-Preislisten rechnen. Pauschale “pro TB Monat”-Zahlen aus Marketing-Material sind fast immer unvollständig. Für eine belastbare Kalkulation einfach melden.