I’m trying to use Zimaos backup to save Outlook .pst files, but it’s not working automatically. Another thing that caught my attention is that the task doesn’t appear. Then I realized that if I wait about 15 seconds, the backup task appears. Has anyone else experienced something similar?
You will have to translate this to English please.
Yes, a few of us have noticed this behavior. The backup task doesn’t always appear instantly and can take 10 to 20 seconds to show up, which looks like a UI or scheduler delay rather than the task not being created.
In most cases:
- The task is created, just not immediately visible
- A page refresh after a short wait usually makes it appear
- Automatic runs can still fail if the source files are locked (Outlook .pst files are often in use)
Worth double-checking:
- ZimaOS version
- Whether Outlook is fully closed during the scheduled backup
- Backup logs to confirm if the job actually triggers
Do u need to wait 15 seconds regardless of the type of my backup file?
It looks like a bit of both, but for different reasons.
The short delay before the backup task appears seems to be on the ZimaOS side and doesn’t appear to be related to the file type. It behaves the same even with other kinds of data, which points more to how the task is registered or shown in the UI.
The actual backup not running reliably with .pst files is more likely Outlook-related, since those files are usually locked while Outlook is open. If Outlook is running, many backup systems can’t copy the file.
So the delay is likely ZimaOS behavior, while the backup issue itself is often caused by Outlook having the file in use.
Outlook .pst files are often locked by Outlook when it’s running, which makes them hard to back up unless the backup tool uses volume shadow copies — that’s a known Windows behavior, not specific to ZimaOS.
1 Like
The Zimaos version is 1.53, Outlook is closed, I checked and there’s a task for that, I don’t know where to see the backup log, can you help me with that?
You can check the backup logs in two ways.
From the ZimaOS UI
- Open Files
- Go to ZimaOS-HD > .log > casaos
- Look for backup related logs and check the timestamps around the scheduled run
From the terminal (read-only)
ls /ZimaOS-HD/.log/casaos
ls /ZimaOS-HD/.log/casaos | grep -i backup
tail -n 100 /ZimaOS-HD/.log/casaos/backup.log
If the task exists but there’s no log activity at the scheduled time, it usually means the scheduler didn’t trigger the job rather than an issue with Outlook or the files.
I actually noticed this too. My backup tasks weren’t running automatically. The last updated date was going higher each day. I haven’t found out why, nothing suspicious inside the backup logs.
I read somewhere, that the Backup App will check at 2 AM for changes. But that never worked I guess. My Fix was creating a cron task which runs at 3 AM killing the icewhale backup app and starting it again after 15 seconds and voilá it now works like a charm, the restart triggers a “backup now” for all tasks.
BR
Thanks for sharing that, interesting find.
It does line up with what others have seen where the tasks exist but don’t always trigger automatically as expected. Restarting the backup service forcing a run suggests the scheduler may not be firing consistently rather than the tasks themselves being broken.
That workaround makes sense as a temporary measure, but it would still be good for the team to look into why the scheduled trigger isn’t reliably kicking off at the expected time. Hopefully this helps narrow it down.
This also happened with some of my backup tasks, but even in this part, backups that refer to USB devices disappear as soon as there is a restart and also one of my google drive accounts disappeared due to a bug in another version and now it can no longer be added.
Yes, that matches what others have seen as well. Backup tasks tied to USB devices can disappear after a reboot if the device isn’t detected quickly or mounts differently at startup. The Google Drive account issue also sounds like a version-specific bug rather than user error, especially if it can no longer be re-added.
It would be good to report both points together, as they likely relate to how backups and external sources are being registered and restored on startup.
I found the log; it says it can’t connect to the network, but it turns out that if I do it manually it works, and the network is online 24/7. I’m going to try using Zimaos’ desktop software for Windows, and I’m also going to try moving the .pst file to a folder outside of Windows Documents since it has special permissions.
Good find, that helps narrow it down.
If the log shows a network error but the backup works when run manually, it usually points to a timing issue during the scheduled run rather than the network actually being offline. Trying the Windows desktop client is a good idea.
Moving the .pst file out of Documents also makes sense, that folder can have special permissions and background locks even when Outlook is closed. Testing it from a plain folder should help rule that out.
Let us know what you find, this is useful info for others too.
Finally, I opted to use Duplicati; it works much better. Zimaos has many flaws and a lot of room for improvement. The PST error was a security issue that I fixed by reversing the backup direction, sending backups from Windows to Zimaos. But Duplicati has many more options. For example, there’s no option to back up files, only folders, and it lacks compression and security options. Thank you all so much!
I believe it’s fair to say ZimaOS still has room for improvement in its native backup feature, especially around flexibility and edge cases.
Regarding the PST issue, I believe it wasn’t a security flaw in ZimaOS itself, but rather a file-locking and access limitation on Windows. Outlook keeps PST files open, which prevents external systems from reliably reading them. Reversing the backup direction (pushing from Windows to ZimaOS) avoids this entirely and is a common best practice.
So the fix makes sense, but it’s more about how Windows handles active files than a security problem in ZimaOS.
Duplicati can’t do any restore. It always fails. I’m just about to give up and go back to Zima Backup
I have no problems to restore, it must be something punctual From the destination where you make the backup, as duplicate use blocks to save space a write error due to a bad connection or a disk with failures, it can be a big problem, use the write verification to make sure everything is fine, and check that you are using the latest version of duplicati