ZimaOS Backup is a disaster!

Operating System
1

[Automatic Google translation]

Hardware: ZimaBoard 2
OS: ZimaOS v1.6.1
Storage: RAID 1, 2x 4TB
App: Backup

Hi everyone! I’ve been using several ZimaBoard 2 units for months now. I love the hardware, but I’m disappointed with the operating system. Honestly, I’m now terrified of data loss!

I have so many unanswered questions; I run into problems with the simplest tasks every day and am considering switching to a different system. Maybe it’s just me, or maybe I don’t understand the system well enough.

USB Hard Drive:
The external USB backup works fine on the first run. Then I disconnect the drive. Later, I can plug the USB drive back in—it gets detected and I can start the backup—but nothing happens. No data is backed up, and there is no access to the drive.
If I manually stop the backup and start it again, it runs through without issues. Every single time! This problem occurs with all four of my external hard drives.

Folder Backup:
Why can’t I exclude specific folders?
A backup function where I can’t manually select or exclude specific folders is ridiculous.

Security:
Data is simply copied. No encryption, no protection against unauthorized access by others.
Then again, it’s questionable whether the backup is even useful. Apparently, apps aren’t paused during the backup, which would inevitably lead to errors during restoration. Which brings me to the next point.

Missing Data:
I happened to notice that, for example, while the folder Safe-Storage/docker/volumes/mailcowdockerized_vmail-vol-1 exists on the USB backup, the folder itself is empty. In an emergency, I would have lost over 1,000 emails! Something like this simply shouldn’t happen with an integrated backup function.

System Backup:
It is impossible to create a complete system backup. While backing up personal data and folders might suffice for many users, it unfortunately isn’t enough for me. I need a simple solution for creating a full backup—including settings, apps, databases, folders, data, etc.

So far, I haven’t even received a clear answer regarding which data actually needs to be backed up… In the “Files” app, the ZimaOS-HD drive appears empty. There isn’t even an option to display all files so I could back them up manually.

Backup after restart:
External backups usually take 1–2 hours, provided I don’t restart the NAS. However, the first backup following a restart takes me 2–3 days (with 2.3 TB of 4 TB used)! I have no idea what is happening or why this is the case. Once that initial post-restart backup completes, all subsequent backups revert to taking just 1–2 hours.

My requirement:
The backup must be restorable offline; this means that in the event of a total failure of a ZimaBoard2 (including its hard drives), I should be able to restore the backup to a different ZimaBoard2 without relying on an internet connection.

My attempts to restore my entire system to another ZimaBoard2 have always ended in disaster. The dashboard remained blank, apps wouldn’t launch, and data was missing. As I mentioned earlier, it is unclear exactly which folders and data need to be backed up.

I realize this all sounds very negative, but I don’t mean it unkindly. I simply want to highlight the issues I’m facing and prompt some reflection. There are likely other users relying on this backup who could find themselves empty-handed in an emergency.

Best regards, Manfred

2

Your concerns are valid. I would not treat the current USB copy as a verified backup until you have successfully restored it on the second ZimaBoard 2.

The ZimaOS Backup app is documented as a file-and-folder backup system. It should not be assumed to provide a complete bare-metal recovery of ZimaOS, applications and live databases.

Before changing or reinstalling anything, we need to confirm where Docker is actually storing your Mailcow volume. Please run these two read-only commands and post the complete output:

docker info --format 'DockerRootDir={{.DockerRootDir}}'

docker volume inspect mailcowdockerized_vmail-vol-1 --format 'Name={{.Name}} Mountpoint={{.Mountpoint}}'

Do not delete, recreate or move any Docker volumes.

Nextcloud is also a good option for protecting selected folders containing documents, photos and other important files. The required folders can be mapped into Nextcloud and synchronised to another independent device, with file versions providing additional protection.

However, Nextcloud should not be the only copy, especially if it is running on the same ZimaBoard 2 and RAID. It also does not replace application-consistent backups of Mailcow, databases or the complete ZimaOS system.

For Mailcow, I would not rely solely on a general folder copy. Mailcow provides its own supported backup script, which backs up the mail, databases, encryption keys and other required components. We first need to verify your installation and storage paths before providing the correct command:

Mailcow Backup

A proper offline recovery plan should eventually contain:

  • Nextcloud or another independent copy of selected personal folders
  • Application-consistent database backups
  • Compose files and application configuration
  • Mailcow’s mail data, databases and encryption keys
  • Copies of the exact Docker images required for an offline rebuild
  • A successful restore test on the second ZimaBoard 2

The USB reconnect problem and the first backup after reboot taking several days also appear repeatable. Those should be investigated separately using the Backup app logs after we establish which container provides the service.

3

Please upgrade version to v1.7.1 and try it.

if also not work, please run the following two commands in the command line:

sudo -i

tmpdir=$(mktemp -d) && cp -a /var/log/icewhale/files-backup* "$tmpdir"/ && journalctl -xe -u icewhale-files-backup > "$tmpdir"/icewhale-files-backup-journal.log && tar -czf /DATA/icewhale-files-backup-logs.tar.gz -C "$tmpdir" . && rm -rf "$tmpdir" && echo "Command completed."

After the command is completed, please open Files, find the icewhale-files-backup-logs.tar.gz file in the ZimaOS-HD directory, and send it to us.

Our develop team email address is: dina@icewhale.org

4

Thanks for the quick reply!

Is a full-fledged backup solution including system settings, databases, etc. planned for ZimaOS? Is there any other software I could use for this? The main requirement is ease of use, so that I can have employees run the backups. I don’t want automated backups. To put it simply, I just want a button I can press to back up the entire system to an external location. It doesn’t matter to me whether this happens via an app’s GUI or a dashboard shortcut.

I’m probably spoiled by Synology. There, I just had to select the apps and folders, and the app handled the rest.
If someone could put together a simple solution like that for me, I’d certainly be happy to pay for it.
I use Syncthing to back up data from our computers and smartphones. If I could somehow use that software to back up the entire ZimaBoard2 as well, that would be the ideal solution for me!

Since I now have several ZimaBoard2 units in use, I could quickly switch to a spare device with hard drives in an emergency. The only missing piece right now is the actual data. Honestly, that makes me very nervous!

sudo docker info --format ‘DockerRootDir={{.DockerRootDir}}’
/media/Safe-Storage/docker

sudo docker volume inspect mailcowdockerized_vmail-vol-1 --format ‘Name={{.Name}} Mountpoint={{.Mountpoint}}’
Name=mailcowdockerized_vmail-vol-1 Mountpoint=/media/Safe-Storage/docker/volumes/mailcowdockerized_vmail-vol-1/_data

My workaround:
Currently, I create manual backups for most apps directly using a function within the app itself. I save this data to the hard drive in a subdirectory of /media/Safe-Storage. Additionally, I use the ZimaOS Backup app to back up the main folder /media/Safe-Storage to an encrypted folder on a USB hard drive, since the respective subfolders contain my personal data as well as the AppData and docker folders. However, this process is cumbersome and time-consuming. And as I have since discovered, not all files are reliably backed up either.

I use Nextcloud for email and internal chat. I use Mailcow to receive and archive emails, which are then displayed within Nextcloud. This might be an awkward setup, but unfortunately, I haven’t found a better solution. I spent weeks experimenting with various email servers, but due to a lack of experience with Linux and the terminal, I was unable to get anything running properly.

1 Like
5

Should I really perform an update without a full backup? :fearful:

6

Okay, so no answers to my questions?

Is a full-fledged backup solution including system settings, databases, etc. planned for ZimaOS?
Is there any other software with a graphical user interface I could use for this?
Should I really perform an update without a full backup?

7

Sorry for the delayed reply, and thank you for explaining your use case in so much detail.

First, regarding updates: if a ZimaOS backup is still in progress when you perform an update, the backup task will automatically continue after the system finishes updating and restarts.

That said, I understand your main concern. What you need is not just a file backup, but something closer to a full system recovery solution.

I think this is something we should design for ZimaOS. Ideally, a System Backup feature could back up:

  • ZimaOS system/service configurations

  • Databases

  • Docker app configurations

  • Docker app data

And users should be able to choose exactly what they want to back up, for example:

  • System settings only

  • App configurations

  • App data

  • Specific apps instead of everything

The goal should be very simple: select what you want, choose the backup destination, and press one button.

Your Synology example is very helpful because it clearly shows the experience you’re looking for. I’ll bring this use case and your requirements to our product team.

For now, since the current ZimaOS Backup is mainly focused on data backup rather than complete disaster recovery, I would still recommend keeping the built-in backup/export functions of important services such as Mailcow or Nextcloud for critical data.

Thanks again for pushing us on this. This is a very reasonable requirement, especially when ZimaOS is being used on multiple machines in a business environment.

1 Like
8

Many thanks for your response! I updated to ZimaOS 1.7.1, and now I’m in a little panic.

The installation went normally, as far as I can tell. After the restart, several apps (FileZilla, Home Assistant, Syncthing) wouldn’t launch. The culprit in each case was the network setting, which I was able to fix myself.

The Files app wasn’t showing any storage drives or folders—neither the USB drive nor the ZimaOS-HD and Safe-Storage (RAID1) volumes. However, I had full access via Windows 11 Explorer. After restarting the NAS several times, the drives and folders suddenly reappeared in the Files app. I performed five more test restarts, and the error didn’t recur.

But: Mailcow is missing!
I apologize for the following unprofessional explanation; unfortunately, I can’t describe it any better.

I originally installed Mailcow with the help of AI, using commands I only partially understood—which, of course, wasn’t exactly smart. But it worked in the end. However, I didn’t have a standard dashboard icon to launch the app; instead, I had an icon showing numerous tabs and countless settings, which didn’t actually launch the app. To avoid messing with that, I simply created a shortcut to the app’s URL on the dashboard.

That icon with the tabs is gone from the dashboard after the update. The custom shortcut I created no longer gets me into Mailcow. Consequently, I currently have no access to my emails, which is a major problem for me.

There is also another issue, though it’s not high priority.
USB problem: This issue has existed since ZimaOS 1.5, so it’s nothing new.

I use the Ultrafeeder app with a USB receiver on the device. Whenever I connect a USB drive, Ultrafeeder apparently loses its connection to the USB receiver. Restarting the Ultrafeeder app restores the connection. So I have to restart the app for every external backup. This issue also occurs with other apps that require this USB receiver.

9

Interesting timing — I’m actually working on exactly this kind of solution at the moment.

I’m developing a backup application specifically for ZimaOS, currently called ZimaBackup.

The goal is to go beyond simple file copying and make disaster recovery much easier:

  • Detect installed Docker/ZimaOS applications automatically

  • Back up application configuration and AppData

  • Back up selected folders separately

  • Save the Docker application definition needed to recreate an app

  • Use encrypted, deduplicated snapshots with Restic

  • Let the user choose which application volumes should or shouldn’t be included

  • Eventually restore an application, its configuration and its data after a fresh ZimaOS installation

The idea is basically:

Select your apps and folders → choose a backup destination → click Backup.

And after a failure:

Fresh ZimaOS → install ZimaBackup → connect the backup → select the apps to restore.

A working prototype already exists: repository creation, encrypted Restic backups, snapshots, manual folder backups and Docker application discovery are working. I’m currently working on the application backup/restore part.

This thread actually confirms that there is a real need for something like this, so I’ll definitely keep working on it.

If people here are interested, I can share progress and eventually provide builds for testing. Feedback about what you would expect from a complete ZimaOS disaster-recovery solution would also be very useful.

4 Likes
10

While I understand how a GUI backup tool is beneficial to basic users, as a Linux system administrator ZimaOS comes with all the tools I need to solve every problem you mentioned. With rsync for local backups and rclone for remote backups. You can even create the simple backups with a click of a button for your employees by writing the backup commands as a bash script and using the Zima Cron UI to trigger them. Just keep the cron entry paused so it doesn’t run automatically, and your employees can simply press the “Run Once” button to run it manually.

In my setup, the ZimaOS NAS is actually a local backup for all of my other servers and clients on the network. The ZimaOS NAS is then encrypted and backed up remotely to Backblaze B2 with the rclone utility using bash scripts and the Zima Cron tool for automation.

zima-cron_tasks
zima-cron_tasks1609×688 72.7 KB

Here is an example of one of the backup scripts that encrypts and backs up the /media/Quick-Storage/Backup directory (that contains the backups from other clients and servers on the local network) to Backblaze B2, then sends a push notification to my Gotify server.

#!/bin/bash

# Define variables
JOB_NAME="Devices"
SOURCE="/media/Quick-Storage/Backup"
DEST="B2-Crypt:ZimaOS-NAS-Backup/Quick-Storage/Backup"
LOGFILE="/var/log/rclone-b2-${JOB_NAME,,}.log"

GOTIFY_TOKEN="your-app-token"
GOTIFY_URL="https://gotify.example.com/message?token=$GOTIFY_TOKEN"

# Execute native rclone sync

rclone sync "$SOURCE" "$DEST" \
  --fast-list \
  --transfers 16 \
  --b2-hard-delete \
  --retries 5 \
  --low-level-retries 15 \
  --timeout 2m \
  --log-file="$LOGFILE" \
  --log-level INFO \
  --stats 0 \
  --stats-one-line

# Capture the exit code immediately
EXIT_CODE=$?

# Extract the final stats line from the log
if grep -q "Transferred:" "$LOGFILE"; then

  STATS=$(grep "Transferred:" "$LOGFILE" | tail -n 1 | sed 's/.*Transferred: //')
else
  STATS="No transfer data available. Backup may have been empty or failed."
fi

# Send Gotify notification
if [ $EXIT_CODE -eq 0 ]; then

  SUCCESS_MSG="The $JOB_NAME directory backup has completed successfully."$'\n\n'"Stats: $STATS"

  curl -s -X POST "$GOTIFY_URL" \
    -F "title=$JOB_NAME Backup" \
    -F "message=$SUCCESS_MSG" \
    -F "priority=4" > /dev/null
else
  FAIL_MSG="The $JOB_NAME directory backup has FAILED with exit code $EXIT_CODE. Check $LOGFILE."

  curl -s -X POST "$GOTIFY_URL" \
    -F "title=$JOB_NAME Backup: FAILED" \
    -F "message=$FAIL_MSG" \
    -F "priority=8" > /dev/null
fi

You can use this method to back up any directory on your server, including your ZimaOS configuration. Restoring the files is as simple as reversing the source and destination. For local backups (e.g., a USB drive or another local server) you can use the rsync tool in place of rclone. I actually use the same tools to back up other Linux servers and clients on the network to the ZimaOS NAS. While for Windows I use their built-in backup utility to back up files to a mapped network drive.

If you don’t mind putting in a little bit of work you can use these CLI tools to accomplish your backup goals while you wait for a GUI tool to be developed. I’m sure it won’t happen overnight, so it may be worth looking into. Once you have it set up there really isn’t any ongoing maintenance you need to do to keep it running. It will just continue operating automatically until you tell it not to.

Note: The more advanced way to do it would be to set up systemd services and timers to automate the backups which is what I do on my Linux workstation and laptop, but to keep things simpler I used Zima Cron for this example.

If you want to set this up while you wait for a more comprehensive GUI backup tool and you need some assistance, then feel free to ask. I would be happy to help.

1 Like
11

Very excited!! If there is an opportunity to try it out, please feel free to @ me.

12

Really looking forward to seeing this come out. Thank you for doing this.