Page 2 of this community tutorial changes the decision from “how do I run dd?” to “what is actually worth protecting?” The user already had a large live NVMe and cared far more about losing DATA than losing the bootable OS. gelbuilding's advice was to avoid repartitioning the live boot NVMe, protect DATA/AppData first, and only keep a raw system clone if the recovery-time benefit justifies the extra backup space.
That priority fits current ZimaOS architecture. The OS has A/B system slots for quick recovery, while irreplaceable user data, AppData, and storage metadata live outside those immutable system images. A full-disk clone can return the machine to an exact point quickly, but it is not a substitute for independent, versioned DATA backups.
dd Clones the Whole Device, Not Only the Small OS Slots
The original tutorial uses a command conceptually like:
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzIf the system lives on a 1 TB NVMe, the raw imaging process still reads the entire block device. Compression may reduce the file size, but the backup target and process are tied to the physical disk layout rather than only the few gigabytes used by ZimaOS system partitions.
Do Not Repartition a Healthy Live System Just to Make dd Smaller
gelbuilding called repartitioning the live boot NVMe high-risk because a mistake can cause downtime or data loss. If the current layout works, make verified data backups before changing partition boundaries.
Protect DATA and AppData Before the OS Clone
If your priority is recoverability, back up:
- user files and storage pools;
- AppData/databases/configuration that cannot be recreated easily;
- important application-specific exports;
- ZimaOS storage metadata such as
local-storage.dbwhen relevant; - then, optionally, the whole system disk.
Current ZimaOS 3-2-1 guidance supports scheduled backups to independent destinations and versioned restore points.
Use the current ZimaOS 3-2-1 backup model.
Current ZimaOS Already Has A/B System Recovery
ZimaOS uses two approximately 6 GB system slots. If one slot fails, the current recovery guide lets the user boot the alternate slot from GRUB.
Use the current A/B system recovery path.
A Clean Reinstall Can Recreate the OS, but Not Your Exact Setup Automatically
As constgen noted, an immutable OS can often simply be reinstalled. gelbuilding's counterpoint was recovery time: a disk clone can return apps/configuration/system state exactly as captured, while a reinstall may require remapping AppData, reinstalling apps and reconnecting storage metadata.
Both are valid recovery strategies; they optimize different things.
A Small Dedicated Boot Disk Simplifies Whole-Disk Cloning
gelbuilding recommended eventually moving ZimaOS to a small 32-64 GB dedicated device and keeping large NVMe/RAID storage as DATA/AppData. The exact minimum for current ZimaOS installation is at least 25 GB.
This separates the disposable OS from large data storage and makes a full system image much smaller.
Raw Restore Commands Are Destructive
Restoring a dd image writes directly over the destination disk. Selecting the wrong /dev/... target can destroy another drive. The original tutorial was explicitly shared for testing, and these commands should only be used after identifying disks by model/serial and preserving DATA elsewhere.
Test the Recovery Path, Not Only the Backup Creation
A backup is only useful if you know how to restore it. For DATA, restore representative files. For a raw system image, test the workflow on spare media if possible rather than discovering device/path assumptions during an actual outage.
ZimaOS Clone vs Backup FAQ
Is a full system-disk clone required to protect ZimaOS data?
No. DATA/AppData backups and storage metadata are separate from the A/B system partitions and are the higher priority for irreplaceable information.
Why would I keep a raw OS clone anyway?
It can shorten recovery time by restoring the exact captured system/app configuration instead of rebuilding it manually.
Should I repartition a live NVMe just to make a clone smaller?
The source recommendation was no; back up DATA first and avoid unnecessary live partition changes.
