Unraids Array mit Parität schützt Sie lokal gegen einen ausgefallenen Datenträger – aber nicht gegen Feuer, Diebstahl, Ransomware oder den versehentlichen Löschbefehl. Die 3-2-1-Regel verlangt genau deshalb eine Kopie außer Haus. intercolo i3 Object Storage ist diese Offsite-Kopie: S3-kompatibel, angesprochen über den Endpoint https://de-fra.i3storage.com in der Region de-fra, strong read-after-write, 99,999999% Durability – und Daten, die das RZ Frankfurt nie verlassen. Von Unraid aus führen zwei bewährte Wege dorthin: rclone (installiert über die Community Applications, geplant per User Scripts) für den schlanken Sync und Duplicacy für versionierte, deduplizierte und clientseitig verschlüsselte Backups. Beide sind günstig, DSGVO/AVV-konform und planbar.
Installieren Sie das rclone-Plugin (oder einen rclone-Container) aus den Unraid Community Applications und dazu das Plugin User Scripts. rclone übernimmt den Transfer, User Scripts plant den Lauf per Cron – mehr Werkzeuge brauchen Sie für den Sync-Weg nicht.
Legen Sie ein S3-Remote mit provider Other, endpoint https://de-fra.i3storage.com und region de-fra an. Als Zugangsdaten dienen Access- und Secret-Key aus Ihrem intercolo API-Key-Paar – der Zugriff läuft ausschließlich über SigV4, es gibt keinen Passwort-Login.
Setzen Sie ein crypt-Remote auf das i3-Remote auf. rclone verschlüsselt Datei-Inhalte und -Namen dann VOR dem Upload; im Storage landen nur unlesbare Chiffrate, der Schlüssel bleibt auf Ihrem Server. Notieren Sie Passwort und Salt sicher – ohne sie kein Restore.
Hinterlegen Sie in User Scripts ein Skript, das rclone sync für /mnt/user/appdata und Ihre wichtigen Shares ausführt, und planen es mit einem eigenen Cron-Ausdruck (etwa nachts). Für konsistente Appdata-Stände stoppen Sie die Container vorher oder nutzen das Plugin Appdata Backup, das saubere Archive erzeugt.
Starten Sie den ersten Lauf manuell und prüfen das Ergebnis mit rclone ls und rclone check. Danach läuft der Sync automatisch über den Cron. Behalten Sie die Logdatei im Blick, bis der erste vollständige Durchlauf sauber durch ist.
Path-Style: https://de-fra.i3storage.com/unraid-backup · Virtual-hosted: https://unraid-backup.de-fra.i3storage.com. rclone spricht i3 über --endpoint bzw. das gespeicherte Remote an; Region de-fra.
/mnt/user/appdata enthält die Konfigurationen und Datenbanken Ihrer Docker-Container – klein, aber wertvoll und ständig in Bewegung. Stoppen Sie die Container vor dem Lauf oder erzeugen mit dem Appdata-Backup-Plugin konsistente Archive, die Sie anschließend hochladen.
Fotos, Dokumente, Projektdaten – die wirklich unersetzbaren Bestände gehören zuerst offsite. Große Medien-Libraries sichern Sie selektiv oder mit eigenem Bucket, damit Volumen und Egress planbar bleiben.
vDisks aus /mnt/user/domains und exportierte Container-Backups gehören als eigener Datensatz in die Offsite-Kopie. So können Sie eine VM oder einen Dienst nach einem Cache- oder Server-Ausfall vollständig neu aufsetzen.
Die Unraid-Konfiguration auf dem /boot-Stick ist winzig, entscheidet aber über schnelles Disaster Recovery. Eine regelmäßige Kopie des Flash-Backups im Offsite-Ziel bringt Ihren Server nach einem Totalausfall zügig zurück.
Ein reiner rclone sync spiegelt – wird eine Datei lokal gelöscht oder von Ransomware verschlüsselt, ist sie es nach dem nächsten Lauf auch in der Kopie (außer Sie arbeiten mit --backup-dir). Wer echte Wiederherstellungspunkte („gestern", „letzte Woche") will, nimmt Duplicacy. Es läuft als Container auf Unraid, lädt per Block-Deduplizierung nur geänderte Blöcke hoch, verschlüsselt clientseitig mit Ihrem eigenen Schlüssel und hält versionierte Snapshots. Wichtig zur Einordnung: Diese Versionierung und das Prune passieren IM Tool, nicht storage-seitig – es gibt keine S3-Objektversionierung. Duplicacy adressiert i3 über sein S3-Backend mit Endpoint https://de-fra.i3storage.com und Region de-fra; die Aufbewahrung legen Sie über die Duplicacy-Retention fest. Viele fahren beides parallel: rclone für große Medien-Shares, Duplicacy mit Historie für Appdata und kritische Daten.
Ehrlich eingeordnet: i3 bietet KEINE storage-seitige Unveränderlichkeit (kein Object Lock/WORM, keine Versionierung) und keine Verschlüsselung at-rest. Planen Sie entsprechend. Erstens: Dies ist Ihre Offsite-Kopie im 3-2-1-Muster – das lokale Array mit Parität bleibt Ihre schnelle erste Kopie, das Object Storage die Distanz-Kopie in Frankfurt. Zweitens: Versionshistorie holen Sie aus dem TOOL, nicht aus dem Speicher – Duplicacy-Snapshots mit Prune oder rclone mit --backup-dir statt reinem Spiegel. Ein blank gespiegelter rclone sync trägt gelöschte oder verschlüsselte Dateien in die Kopie weiter; für echte Point-in-Time-Wiederherstellung nutzen Sie Duplicacy-Snapshots oder --backup-dir. Drittens: Verschlüsseln Sie clientseitig – rclone crypt oder die Duplicacy-Verschlüsselung. Der Schlüssel bleibt bei Ihnen, der Transport läuft über TLS, im RZ liegen nur Chiffrate – auch wir können sie nicht lesen.
Das nutzlose Backup ist das ungetestete. Bei US-Hyperscalern bestraft jeder Rückholtest und jeder echte Restore mit Egress-Gebühren – also wird zu selten getestet. Hier ist pro gebuchtem TB Storage 1 TB Egress inklusive. Sie holen nach einem Cache-Ausfall die Appdata zurück, ziehen einen einzelnen Share oder bauen nach einem Totalschaden den ganzen Server neu auf, ohne dass die nächste Rechnung explodiert. Zusätzlicher Traffic wird transparent mit +3,99 €/TB abgerechnet – planbar statt überraschend. Testen Sie den Restore regelmäßig (rclone check oder eine Duplicacy-Wiederherstellung in ein Testverzeichnis): Sie wissen vorher, was ein vollständiger Restore kostet, bevor Sie ihn wirklich brauchen.
| Backblaze B2 | Wasabi | intercolo i3 | |
|---|---|---|---|
| Standort / Datenhoheit | EU-Region wählbar, US-Konzern | EU-Region wählbar, US-Konzern | RZ Frankfurt, 100% DE, DSGVO/AVV |
| Endpoint | s3.eu-central-*.backblazeb2.com | s3.eu-central-*.wasabisys.com | https://de-fra.i3storage.com (de-fra) |
| rclone & Duplicacy | S3-kompatibel | S3-kompatibel | S3-kompatibel, strong read-after-write |
| Egress-Modell | 1 TB frei/Tag, dann pro GB | 'kostenlos' bis Speichermenge, dann gedrosselt | 1 TB inkl./TB, dann +3,99 €/TB |
| Ab-Preis Storage | Listenpreis US$/TB | Listenpreis US$/TB | 2,49 €/TB |
| Support / Ansprechpartner | Ticket, EN | Ticket, EN | Direkt, deutsch, RZ-Team |
| Strom | variiert | variiert | 100% Ökostrom |
Der Zugriff läuft ausschließlich über SigV4-Schlüsselpaare (Access/Secret) – kein Passwort-Login und keine Bucket-Policies oder ACLs, die man falsch konfigurieren könnte. Geben Sie jedem Zweck einen eigenen Bucket und ein eigenes Key-Paar: eins für Appdata, eins für Medien, eins für VM-Backups. Leckt ein Schlüssel oder wird ein Container kompromittiert, rotieren Sie genau diesen Schlüssel isoliert, ohne den Rest anzufassen. Für geteilte Restore-Links nutzen Sie presigned URLs mit kurzer Gültigkeit. Halten Sie Access- und Secret-Key möglichst aus den Skripten heraus – hinterlegen Sie sie in der rclone- bzw. Duplicacy-Konfiguration statt im Klartext im User-Script.
Unsere Erfahrung spricht für sich: Wir haben bereits erfolgreich Migrationen mit mehreren Petabyte an Daten und über 500 Millionen Dateien durchgeführt.