Recover a ZimaOS RAID 1 After Reinstalling the System

If ZimaOS is reinstalled and an existing RAID 1 appears as unused disks, do not immediately click Create RAID. Recreating or formatting the array can destroy the data that is still present on the member disks.

The first recovery path should be the current official ZimaOS method: restore the saved local-storage.db file from the previous system installation. The community tutorial behind this page documents a more invasive fallback for the harder case where that database was not backed up. That fallback was tested on ZimaOS 1.6.1, but it includes destructive RAID operations and should only be considered after the source data has been independently copied and verified.

First Choice: Restore local-storage.db

ZimaOS keeps storage configuration information in:

/ZimaOS-HD/.casaos/db/local-storage.db

The current official recovery guide recommends downloading this file before reinstalling the system, then placing it back into the same directory after the new ZimaOS installation and rebooting.

Official ZimaOS RAID recovery after reinstall

If you still have access to the old system disk, try to recover this database before touching the RAID member disks.

Why the Data Array May Still Be Intact

ZimaOS uses Linux software RAID. The member disks can retain RAID metadata even when the new ZimaOS installation no longer has the old storage database. That is why disks can appear physically present while the UI no longer recognizes the original pool.

ZimaOS 1.6 also introduced improved RAID metadata recovery and re-identification behavior, so a problem originally seen on one system should not be assumed to occur identically on every newer release.

Do Not Create a New RAID Until Recovery Is Decided

If the disks contain data you need, avoid:

• formatting either member disk;
• creating a new RAID over the same disks;
• running wipefs or mdadm --zero-superblock prematurely;
• guessing which /dev/sdX device is which.

Before any recovery work, identify disks by model, serial number, and capacity rather than relying only on device letters.

Verify the RAID Metadata Read-Only

The community author first used read-only inspection to confirm both RAID 1 members still belonged to the same array.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

For a healthy RAID 1, both members should report the same array UUID and compatible RAID metadata. If one member is missing, degraded, or reports different metadata, stop and get recovery assistance rather than following a generic rebuild recipe.

Assemble and Mount the Old Array Read-Only

For advanced recovery, a read-only assembly reduces the chance of modifying the source while verifying that files are accessible:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Then inspect the filesystem:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

Device names above are examples only. Never paste them unchanged unless you have confirmed they match your hardware.

Create a Full Offload Copy Before Any Destructive Step

The source workflow used an external ext4 drive large enough to hold all used RAID data. For Linux application data, ext4 is useful because it can preserve normal ownership, permissions, links, ACLs, and extended attributes.

A typical archive-style copy is:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Run the copy in tmux or another persistent terminal if an SSH disconnect would otherwise interrupt it.

Verify the Backup Before Going Further

Do not rely only on an rsync exit line. Compare file counts and inspect major directory sizes:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

For irreplaceable data, a second independent backup is preferable. RAID is not itself a backup.

Last Resort: Offload, Remove Old RAID Metadata, Recreate in the UI

The original community author wanted the recovered array to return to normal ZimaOS UI management. Their last-resort method was:

1. verify the old array read-only;
2. copy all data to an external drive;
3. verify the copy;
4. stop the old md array;
5. remove the old RAID metadata;
6. create a fresh RAID 1 using the ZimaOS Storage UI;
7. restore the copied files;
8. verify the restored data.

This procedure intentionally destroys the old RAID metadata. Once you perform that step, the offload copy becomes your recovery source. Do not use this approach if the copy is incomplete or if you are unsure about device identity.

The Irreversible Command in the Source Workflow

The community procedure used:

mdadm --zero-superblock /dev/sda /dev/sdb

This is not a troubleshooting command. It removes RAID metadata from the specified disks. A wrong device path can cause major data loss.

For that reason, this page does not recommend running it merely because the ZimaOS UI does not recognize a RAID. Restore local-storage.db, check current ZimaOS recovery behavior, and contact support first when the array contains important data.

Why Recreate the Array Through the ZimaOS UI?

The purpose of the source workflow was to end with a storage pool managed normally by ZimaOS rather than a permanently hand-assembled md device outside the storage UI.

After the old data is safely offloaded and the disks are intentionally reset, use the current Storage interface to create RAID 1 and let the initial synchronization complete.

Restore the Files to the New Pool

After the new pool is created and mounted, restore from the offload disk:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Replace /media/Storage with the actual destination path shown by your system.

Verify the Restored Pool

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Keep the offload drive untouched until the RAID synchronization is complete and you have verified normal access through the ZimaOS Files interface and the applications that depend on the data.

Back Up local-storage.db Before the Next Reinstall

The easiest recovery is the one prepared in advance. Keep a current copy of:

/ZimaOS-HD/.casaos/db/local-storage.db

outside the system drive. The official documentation now provides a direct restore procedure using this file.

Which Recovery Path Should You Choose?

ZimaOS RAID Recovery FAQ

Does reinstalling ZimaOS automatically erase RAID data?

No. Reinstalling the system disk is different from formatting the RAID member disks. The storage configuration can be lost while RAID metadata and data remain on the members.

Should I click Create RAID if the old disks show as unused?

Not until you have confirmed that no existing data needs to be recovered. Creating a new RAID can be destructive.

What is the safest recovery if I backed up local-storage.db?

Use the current official ZimaOS procedure to restore that database and reboot.

Is zeroing the mdadm superblock safe?

It is intentionally destructive to RAID metadata. Use it only as part of a verified recovery plan after data has been safely copied elsewhere.