[Tutorial] ZimaOS Backup and Restore using USB drive (Shared by @gelbuilding)

This tutorial and script are written by our MOD @gelbuilding. Welcome to test it in the test environment, and give us the feedback.

Zima System Restore to USB (Complete Tutorial + Suggestion for Integration)

I’ve read many posts across the forum where users were asking for a proper system-level restore method or struggling after a bad update, system corruption, or reinstall. Because of that, I put together a complete and safe method for backing up and restoring the ZimaOS system disk to a USB device.

This lets users create a 1:1 clone of the OS disk that can be restored in minutes on ZimaBlade, ZimaCube, Proxmox, or bare metal.

It also avoids touching DATA disks, which ZimaOS will re-mount automatically after restoration.

This tutorial now includes everything needed: correct USB mounting, device verification, ZimaBlade onboard eMMC support, optional checksum validation, and complete backup + restore commands.


1. Why Only the OS Disk Should Be Backed Up

ZimaOS is designed like modern NAS systems:

  • The OS and system partitions live on a small partition (32–64 GB)
  • All media, AppData, containers, downloads, and user files sit on DATA partition

Backing up just the OS partition:

  • Keeps the backup tiny (2–6 GB compressed)
  • Finishes in under 2 minutes
  • Avoids cloning terabytes of data
  • Restores cleanly regardless of hardware

After restoration, ZimaOS automatically re-mounts DATA partitions, other storage space, and all apps reappear instantly.


2. Safety Checks Before You Begin

Identify the OS disk and USB drive

Always confirm the correct disk to avoid overwriting the wrong one:

lsblk

# In most cases:
# ZimaCube / NVMe systems: `/dev/nvme0n1`
# ZimaBlade / onboard eMMC: `/dev/mmcblk0`
# Proxmox / SATA systems: `/dev/sda`

Check USB size

Ensure at least 8–16 GB available:

df -h /media/<USB drive>

USB formatting

ext4 is recommended for large image files.
FAT32 cannot store files above 4 GB.

Format if needed:

mkfs.ext4 /dev/sdX1

3. Creating the System Backup on USB

Step 1. Identify the USB device

lsblk

Find something like /dev/sdb1.

Step 2. Create USB mount point

mkdir -p /media/usb
mkdir -p /media/usb/backup

Step 3. Mount the USB

(This step is required)

mount /dev/sdX1 /media/usb

Verify:

mount | grep /media/usb

Step 4. Back up the OS disk

NVMe systems (ZimaCube / PC / Proxmox)

dd if=/dev/nvme0n1 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz
sync

Emmc onboard storage

dd if=/dev/mmcblk0 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz
sync

Step 5. Optional: verify the backup

sha256sum /media/usb/backup/zimaos_system_backup.img.gz > /media/usb/backup/backup.sha256

Later check:

sha256sum -c /media/usb/backup/backup.sha256

4. Restoring ZimaOS From USB

Step 1. Confirm USB is mounted

mount | grep /media/usb

If not:

mount /dev/sdX1 /media/usb

Step 2. Restore the system image

NVMe systems

gunzip -c /media/usb/backup/zimaos_system_backup.img.gz | dd of=/dev/nvme0n1 bs=64M status=progress

Emmc onboard storage

gunzip -c /media/usb/backup/zimaos_system_backup.img.gz | dd of=/dev/mmcblk0 bs=64M status=progress

Step 3. Reboot into the restored system

reboot

ZimaOS will return exactly to the state captured in the backup.
All DATA disks will auto-mount and all apps will reappear as before.


5. How the Commands Work

dd if=/dev/nvme0n1
Reads the entire OS disk byte-for-byte.

bs=64M
Improves performance.

status=progress
Shows live status.

gzip
Compresses the output.

sync
Flushes all pending writes to USB.

gunzip -c
Decompresses the backup image for restore.

dd of=/dev/...
Writes it back exactly as it was.


Suggestion for ZimaOS

This would be a great built-in feature for ZimaOS.
A simple UI could:

  • Detect the OS disk automatically
  • Detect and validate a USB device
  • Check available space
  • Perform the backup and compression
  • Provide a one-click restore option
  • Prevent overwriting DATA disks

This would eliminate most user errors and give ZimaOS a fast, reliable, pro-level recovery system.

8 Likes

+1 thx

1 Like

Beautiful work. Thank you @gelbuilding!

2 Likes

This is great work! Simple to run, and only backs up what is needed!

Thanks @gelbuilding

2 Likes

I think it would be a good idea to do the same thing HomeAssistant does with its backups; it’s very simple.
I’m currently backing up all of ZimaOS, and I’d like to migrate the folders to a USB drive, but it won’t let me. Is this correct?
Or should I uncheck the option to keep file versions?

What should we see as output to verify this? I Apparently did something wrong trying to do this last night. I thought I had followed all the instructions. but apparently something didn’t work right. I have a 1TB drive the OS is installed on (Bare metal) , the gz file was over 700gb, and filled up to full the boot drive. This is the exact command I ran. I see 2 problems. Problem 1 is, it didn’t backup to the thumb drive. I’m sure that is related to it not mounting and me not realizing that properly, That is on me. Problem 2 is a puzzling one to me. The SIZE of it.

This is all of the partitions on the boot drive.

nvme0n1     259:2    0 931.5G  0 disk
├─nvme0n1p1 259:3    0    32M  0 part  /mnt/boot
├─nvme0n1p2 259:4    0    24M  0 part
├─nvme0n1p3 259:5    0     6G  0 part  /
├─nvme0n1p4 259:6    0    24M  0 part
├─nvme0n1p5 259:7    0     6G  0 part
├─nvme0n1p6 259:8    0     8M  0 part
├─nvme0n1p7 259:9    0    96M  0 part  /var/lib/rauc
│                                      /var/lib/zerotier-one
│                                      /mnt/overlay
└─nvme0n1p8 259:10   0 919.3G  0 part  /var/log
                                       /var/lib/libvirt
                                       /var/lib/icewhale
                                       /var/lib/extensions
                                       /var/lib/docker
                                       /var/lib/casaos
                                       /DATA
                                       /var/lib/bluetooth
                                       /opt
                                       /media
                                       /var/lib/casaos_data

And this is the command I ran

dd if=/dev/nvme0n1 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz

I think the problem was I followed the example at the top

It is a NVME system, and I should have probably had ran this command (assuming the destination was correct.

dd if=/dev/nvme0n1p1 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz

Just the part that is /mnt/boot ? Or would that be the p3 one that it is 6G with just /

What about data consistancey. What will happen if something is changed in configs or data bases during backup?

ZimaOS is safe to back up live because the OS disk doesn’t hold any active databases or high-write data. The core system is read-only (squashfs), and the writable overlay is tiny and low-activity. All app data and databases live on the separate DATA disks, which are not part of the system image. So even if something changes during backup, it won’t affect consistency of the OS backup.

You were very close, but here’s the key thing:

You must back up the entire OS disk (/dev/nvme0n1), not an individual partition like nvme0n1p3 or the 6G partition.

That 6G partition is only one piece of the system.
ZimaOS uses multiple partitions together:

  • boot
  • two squashfs system partitions
  • overlay
  • casaos-data

All of these form the OS.
So the correct input device for backup is always the whole disk:

dd if=/dev/nvme0n1 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz

Not /dev/nvme0n1p1, not /dev/nvme0n1p3, not a 6G partition, the full disk.

The reason your backup grew huge is simply because the USB wasn’t mounted, so the file was written to your internal drive instead. Once the USB is properly mounted, you’ll get a normal compressed size (2–6 GB).

If you run:

mount | grep /media/usb

and it returns nothing, the USB isn’t mounted and dd will fill your OS disk again.

Mount the USB first and everything will work as expected.

The Backup app doesn’t allow moving the destination to a USB drive because it only supports internal ZimaOS-managed disks for versioned backups. USB storage isn’t treated as a managed data volume, so migration is blocked.

Unchecking “keep file versions” won’t change that, it still won’t let you move the backup target to USB.

If you want a USB-based backup of the system, the correct method is the System Restore tutorial above (dd + gzip). That creates a full, consistent OS image and doesn’t rely on the Backup app.

So yes, what you’re seeing is expected behaviour.

Por este motivo digo que lo mejor seria que ZimaOS tuviera un sistema de copias de seguridad como hace Home Assintant que el mismo genera un fichero comprimido y si tienes que cambiar de maquina solo con ese fichero y montando la base se restaura solo sin hacer nada es muy sencillo y fácil.
Sin meter nada de código al igual ZimaOS esta bloqueado al acceso root por este motivo deberíamos tener esta opción, y desde el Backup interno subirla al drive o USB o lo que sea pero ese fichero comprimido que contenga todo el ZimaOS configuraciones y actualizaciones contenedores etc.

Se podria aplicar ese sistema para el ZimaOS?

Good point, and the Home Assistant model makes a lot of sense.

ZimaOS can support this idea within its current design boundaries. Because the system is immutable and root access is restricted by design, a full single-file system image restore like Home Assistant is not currently available.

What can be achieved today:

  • Backup of app data, containers, and user configuration
  • Export to USB or cloud storage
  • Restore of apps and settings after a fresh ZimaOS install

For the community, I created and shared a USB-based backup and restore method that works within these boundaries. It’s intended as a practical community solution and a reference for what’s possible today.

A Home Assistant–style backup workflow would be a great long-term enhancement and would need to be implemented directly within ZimaOS to align with its architecture and security model.

1 Like

First at all, thank you for the guide.

I want to add a comment to make sure things are not going in the wrong direction.

In my opinion, you should clarify, that it is absolutely crucial that users of course backup their DATA-partition too. Harddrives can break down and the DATA-partition is where all the app-data is saved.

In my opinion, backup is, right now, one of the things, I don’t like about ZimaOS. It is absolutely necessary that there will be two things added in the system:

  1. A simple way to perform bare-metal backup of the system drive with the option to back up to local drives, e.g., USB drives, and to cloud storage such as OneDrive, etc.
  2. A simple way to backup the DATA-Drive, also local and cloud.

Both backups need to have the option to encrypt the backups. When I backup my system and data to one drive for example encryption of the backup is a must have.

And there need to be easy recovery solutions too. The best backup is worthless, if recovery in case of disaster is a pain in the ass.

I really hope we will see very soon integrated backup solutions that meet the above requirements.

Muy buen trabajo y bien explicado, gracias por su aporte

Gracias, he realizado la copia de seguridad del sistema, importante hacerla antes de culaquier actualización importante.

I seem to be having a similar issue as SirWill. I have a 1tb nvme boot (338gb used) that I’m backing up to usb (512gb) and the backup is already up to 343gb.

Here were my steps:

  1. Identify usb as /media/sde1-usb-USB_SanDisk_3.2G
  2. Run umount /dev/sde1 to prepare it for format (otherwise get error /dev/sde1 is mounted; will not make a filesystem here!)
  3. Run mkfs.ext4 /dev/sde1
  4. Run mkdir -p /media/usb
  5. Run mount /dev/sde1 /media/usb
  6. Run mkdir -p /media/usb/backup (I did this after mounting since I was getting an error trying to run the disk backup command otherwise)
  7. Verify mount | grep /media/usb and receive /dev/sde1 on /media/usb type ext4 (rw,relatime)
  8. Run the nvme boot command dd if=/dev/nvme0n1 bs=64M status=progress | gzip > /media/usb/backup/zimaos_system_backup.img.gz sync
  9. In a separate terminal window verify that the usb is filling up with df -h /media/usb. Output seems to confirm it’s usb /dev/sde1 452G 343G 87G 80% /media/usb. Checking the frontend hub confirms the USB is filling up and not the boot drive or raid array as well.

Having done all this I’m not sure what’s going wrong so I’d appreciate help.

Thanks for the detailed steps.

From what you’ve shared, your commands are correct and nothing is actually “broken”. The key point is this:

Why your backup file is so large

You are running:

dd if=/dev/nvme0n1 ...

That command makes a raw 1:1 clone of the entire NVMe disk, not just the ZimaOS system partition.

So if your boot NVMe shows 338GB used, your .img.gz can absolutely grow to 300GB+, especially if the NVMe contains:

  • AppData / Docker data

  • media / downloads

  • databases

  • anything else that doesn’t compress well

Also worth noting:

  • df -h shows filesystem usage

  • dd copies raw disk blocks

  • gzip only shrinks it if the disk has lots of empty/zero space

Quick check (recommended)

This will confirm what partitions exist on the NVMe:

lsblk -f /dev/nvme0n1

If you see large partitions beyond the small ZimaOS system partitions, it confirms your NVMe is being used for more than just OS.


My suggestion (best practice)

I suggest keeping ZimaOS on a small dedicated disk only (32–64GB is perfect), and keeping apps + data on the DATA pool / RAID.

This is the layout that makes the USB restore method fast and reliable:

Recommended layout

Disk 1 (System / Boot disk)

  • 32–64GB SSD / small NVMe / eMMC

  • ZimaOS only

  • This disk is what you dd to USB

  • Backup size becomes small (usually a few GB)

Disk 2+ (DATA pool / RAID)

  • HDD / SSD array / RAID pool

  • AppData, containers, media, downloads, shares

  • These disks are not backed up with dd

  • After restoring the OS disk, ZimaOS will auto-remount DATA, and apps usually reappear immediately

Why this is ideal

  • Backups complete in minutes

  • Restores are fast

  • Low risk (no chance of cloning TBs)

  • Designed around how ZimaOS separates OS vs DATA


So in short: your result is expected because your NVMe boot disk currently contains much more than “just the OS”. The USB restore method works best when the OS lives on a small dedicated system disk.

Thanks for this comment, I fully agree, and I believe it’s important to clarify this so nobody misunderstands the goal of the guide.

This tutorial is ONLY for system-level recovery (OS disk)

The purpose of the USB dd backup method is:

  • bare-metal recovery of the ZimaOS system drive

  • fast restore after a bad update / corruption / failed boot

  • restoring the OS without touching DATA drives

It is not meant to replace proper backup of user data.


Important clarification: users MUST also back up DATA

I believe this is a critical point for new users:

This USB dd method protects the system drive only.
It does not protect you from DATA loss.

DATA backups are still essential because:

  • drives can fail without warning

  • accidental deletion happens

  • corruption/ransomware is possible

  • RAID improves uptime, but RAID is not a backup

The DATA pool is where the important items live:

  • personal shares / files

  • AppData (containers, configs, databases)

  • media libraries

  • downloads and documents

So the correct mindset is:

  • OS backup = fast bare-metal recovery (this guide)

  • DATA backup = proper backup strategy (external + versioned + ideally encrypted)


Why OS-only backup still matters

Even if DATA backups are perfect, OS failures still happen and can stop everything quickly.

This system restore method gives you:

  • a clean OS rollback in minutes

  • minimal risk of accidentally wiping DATA

  • quickest way back to a working dashboard + apps

After restoring the OS disk, ZimaOS typically re-mounts the DATA pool and apps reappear.


DATA Backup Best Practices (suggestion to add to the tutorial)

I believe the best way to describe this in the tutorial is to recommend a simple, realistic approach:

1) Follow the 3-2-1 rule

I suggest using:

  • 3 copies of your data

  • 2 different storage types

  • 1 copy offsite

Example:

  • Primary DATA pool in ZimaOS

  • Secondary backup to USB HDD / second NAS

  • Offsite backup to cloud (or another physical location)

2) Back up AppData separately (containers / configs / DBs)

I believe AppData is the most overlooked risk area. Even if your media can be re-downloaded, losing AppData often means:

  • losing settings

  • losing databases

  • breaking apps

I suggest ZimaOS eventually provides a built-in “AppData backup/export”, but today users can still protect it using either:

  • scheduled backup app

  • rsync-based sync to another disk/share

  • versioned backup to cloud

3) Encrypt backups by default

I strongly agree with your encryption point.

I believe:

  • local USB backups should support encryption

  • cloud backups should support encryption

  • restore should be guided and simple

I suggest this becomes a first-class feature in ZimaOS because encrypted backup should not require advanced Linux knowledge.


Strongly agree with your feature request

I believe ZimaOS needs integrated backup + recovery options, ideally:

  1. System drive bare-metal backup

    • local USB / NAS target

    • cloud target (OneDrive/Google Drive/etc)

    • encryption

  2. DATA drive backup

    • local + cloud

    • encryption

    • incremental + versioned backups (not always full copy)

  3. Easy recovery tools

    • guided restore

    • clear disk safety checks

    • prevention of wiping DATA disks

That combination would make backup/recovery “pro-grade” and remove a lot of risk and stress for users.