The architectural goal is sound: use RAID 0 SSDs only for the workload that truly needs maximum throughput, then protect that high-risk working pool with independent HDD backups and keep at least one copy off-site. RAID 0 has no redundancy, so one SSD failure can take the whole working array offline.
The 2025 community reply recommended standalone rotating HDDs plus nightly rsync, but the original poster raised an important objection: ZimaOS already had an Auto mode in Backup, and they wanted to know whether swapping an older HDD back into the same bay would be recognized automatically. The thread ended before those questions were answered. Current IceWhale documentation now gives a clearer supported baseline: the Backup app supports scheduled tasks, multiple independent destinations, resume/fault tolerance, and versioned restore points—but current public docs do not describe a guaranteed “hot-swap any old HDD into the same bay and automatically reconcile it by identity” workflow.
RAID 0 Needs a Real Backup Plan
RAID 0 combines SSDs for capacity/performance without parity or mirroring. A single member failure can destroy the array. For professional work, the backup should be treated as part of the design, not something added later.
Standalone Backup HDDs Fit Rotation Better Than RAID 1
The community recommended keeping each 26 TB HDD independent rather than pairing two of them into RAID 1. That makes each disk a complete removable/off-site copy and avoids rebuilding a mirror every time a drive is rotated.
This is a community design recommendation, not an IceWhale requirement. RAID 1 can improve availability while both HDDs remain installed, but it is awkward as a physical rotation/off-site mechanism.
Current ZimaOS Backup Supports the Core 3-2-1 Workflow
Current IceWhale documentation says one Backup app can use Zima, USB, LAN, or cloud sources/destinations, run tasks on schedules, resume interrupted transfers, keep versions/restore points, and maintain multiple tasks from one source to different destinations.
Use the current ZimaOS Backup model.
Do Not Freeze the 2025 “Auto Means Instant on Every Change” Label
The OP quoted a UI statement saying Zima/USB sources could run instantly when files changed. Another official community discussion from the same period described ZimaOS Backup Auto as executing at specific times, usually early morning. The source itself never reconciled those descriptions.
Current public documentation describes scheduled backup and does not promise filesystem-event replication after every change. For production planning, use the current documented schedule rather than relying on an old UI phrase.
rsync Is a Mirror/Transfer Tool, Not Automatically a Versioned Backup
The community script used:
rsync -avh --delete ...The --delete flag makes the destination mirror deletions from the RAID 0 source. That can be useful for a mirror, but it can also propagate accidental deletion to the backup disk.
If rsync is used, start without destructive flags, use --dry-run, verify the target path, and design snapshots/versioning separately if recovery from deletions matters.
Drive Rotation Needs Stable Identity and Explicit Verification
Swapping disks into one physical bay does not guarantee that every inserted disk always receives the same mount name/path. A robust rotation process should identify the disk by a stable device/storage identity, confirm that the expected target is mounted, then start the backup.
Do not run a destructive mirror job merely because “something” is mounted at the old target path.
Rotate Off-Site Copies More Frequently Than Every Few Months for Critical Work
A three- or four-month rotation leaves a large recovery-point gap if the on-site working pool and local backup are lost together. The appropriate interval depends on change rate and business tolerance, but important professional data usually warrants a more frequent off-site cadence.
Test Restore Before Trusting the Rotation
For each backup HDD, restore a representative project/file, verify checksums or application readability, and record the last successful backup date before taking the disk off-site.
RAID 0 Backup FAQ
Is RAID 1 on the backup HDDs the same as rotating independent backups?
No. RAID 1 improves availability while both drives are part of the mirror; independent disks are easier to remove and store off-site as separate copies.
Does current ZimaOS documentation promise true real-time per-change replication?
Current public Backup documentation describes scheduled tasks, resume/fault tolerance, and versions rather than a guaranteed filesystem-event mirror.
Is rsync --delete automatically safer than ZimaOS Backup?
No. It intentionally mirrors deletions and needs careful target validation plus separate versioning if you want recovery from mistakes.
