Unraid's array with parity protects you locally against a failed drive – but not against fire, theft, ransomware or the accidental delete command. That is exactly why the 3-2-1 rule demands a copy off the premises. intercolo i3 Object Storage is that off-site copy: S3-compatible, reached via the endpoint https://de-fra.i3storage.com in region de-fra, strong read-after-write, 99.999999% durability – with data that never leaves the Frankfurt facility. Two proven paths lead there from Unraid: rclone (installed via Community Applications, scheduled with User Scripts) for the lean sync, and Duplicacy for versioned, deduplicated and client-side encrypted backups. Both are cheap, GDPR/DPA-compliant and predictable.
Install the rclone plugin (or an rclone container) from the Unraid Community Applications, plus the User Scripts plugin. rclone handles the transfer, User Scripts schedules the run via cron – you need no more tools for the sync path.
Create an S3 remote with provider Other, endpoint https://de-fra.i3storage.com and region de-fra. Access and secret key from your intercolo API-key pair serve as credentials – access runs exclusively through SigV4, there is no password login.
Layer a crypt remote on top of the i3 remote. rclone then encrypts file contents and names BEFORE upload; only unreadable ciphertext lands in storage and the key stays on your server. Store the password and salt safely – without them, no restore.
Add a script in User Scripts that runs rclone sync for /mnt/user/appdata and your important shares, and schedule it with a custom cron expression (e.g. overnight). For consistent appdata, stop the containers first or use the Appdata Backup plugin, which produces clean archives.
Run the first pass manually and check the result with rclone ls and rclone check. After that the sync runs automatically via cron. Keep an eye on the log file until the first full pass completes cleanly.
Path-style: https://de-fra.i3storage.com/unraid-backup · Virtual-hosted: https://unraid-backup.de-fra.i3storage.com. rclone reaches i3 via --endpoint or the stored remote; region de-fra.
/mnt/user/appdata holds the configurations and databases of your Docker containers – small, but valuable and constantly changing. Stop the containers before the run or create consistent archives with the Appdata Backup plugin, which you then upload.
Photos, documents, project data – the truly irreplaceable stuff goes off-site first. Back up large media libraries selectively or in their own bucket so volume and egress stay predictable.
vDisks from /mnt/user/domains and exported container backups belong in the off-site copy as their own dataset. That way you can rebuild a VM or a service completely after a cache or server failure.
The Unraid configuration on the /boot stick is tiny but decisive for fast disaster recovery. A regular copy of the flash backup in the off-site target gets your server back quickly after a total failure.
A plain rclone sync mirrors – if a file is deleted locally or encrypted by ransomware, it will be gone or encrypted in the copy after the next run too (unless you use --backup-dir). If you want true restore points ('yesterday', 'last week'), reach for Duplicacy. It runs as a container on Unraid, uploads only changed blocks via block-level deduplication, encrypts client-side with your own key and keeps versioned snapshots. Important to frame correctly: this versioning and pruning happen IN the tool, not on the storage side – there is no S3 object versioning. Duplicacy addresses i3 through its S3 backend with endpoint https://de-fra.i3storage.com and region de-fra; you set retention via the Duplicacy prune policy. Many run both in parallel: rclone for large media shares, Duplicacy with history for appdata and critical data.
Framed honestly: i3 provides NO storage-side immutability (no Object Lock/WORM, no versioning) and no at-rest encryption. Plan accordingly. First: this is your off-site copy under 3-2-1 – the local array with parity remains your fast first copy, object storage the distance copy in Frankfurt. Second: get version history from the TOOL, not the storage – Duplicacy snapshots with prune, or rclone with --backup-dir instead of a plain mirror. A blank mirrored rclone sync carries deleted or encrypted files into the copy; for real point-in-time recovery use Duplicacy snapshots or --backup-dir. Third: encrypt client-side – rclone crypt or Duplicacy encryption. The key stays with you, transport runs over TLS, only ciphertext sits in the data center – not even we can read it.
The useless backup is the untested one. With US hyperscalers every retrieval test and every real restore is penalised with egress fees – so testing happens too rarely. Here 1 TB of egress is included per booked TB of storage. You pull appdata back after a cache failure, restore a single share or rebuild the whole server after a total loss without the next invoice exploding. Extra traffic is billed transparently at +€3.99/TB – predictable, not surprising. Test the restore regularly (rclone check or a Duplicacy restore into a test directory): you know what a full restore costs before you actually need it.
| Backblaze B2 | Wasabi | intercolo i3 | |
|---|---|---|---|
| Location / data residency | EU region selectable, US corporation | EU region selectable, US corporation | Frankfurt DC, 100% DE, GDPR/DPA |
| Endpoint | s3.eu-central-*.backblazeb2.com | s3.eu-central-*.wasabisys.com | https://de-fra.i3storage.com (de-fra) |
| rclone & Duplicacy | S3-compatible | S3-compatible | S3-compatible, strong read-after-write |
| Egress model | 1 TB free/day, then per GB | 'free' up to storage limit, then throttled | 1 TB incl./TB, then +€3.99/TB |
| Starting storage price | List price US$/TB | List price US$/TB | €2.49/TB |
| Support / contact | Ticket, EN | Ticket, EN | Direct, German, DC team |
| Power | varies | varies | 100% green power |
Access runs exclusively through SigV4 key pairs (access/secret) – no password login and no bucket policies or ACLs you could misconfigure. Give each purpose its own bucket and its own key pair: one for appdata, one for media, one for VM backups. If a key leaks or a container is compromised, you rotate exactly that key in isolation without touching the rest. For shared restore links use presigned URLs with a short lifetime. Keep access and secret keys out of the scripts where possible – store them in the rclone or Duplicacy configuration rather than in plaintext in the User Script.
ประสบการณ์ของเราพูดแทนตัวเอง: เราย้ายข้อมูลสำเร็จแล้วหลายเพตะไบต์และไฟล์กว่า 500 ล้านไฟล์