[FIX] ZimaOS Backup filling up System Drive or eMMC? Move Rclone cache to NVMe/HDD

Operating System ZimaOS
1

If you are using the built-in Backup app in ZimaOS, you may find your system drive filling up unexpectedly. In my case, a 64GB eMMC was nearly maxed out by hidden data. This is often caused by the Rclone cache (located at /DATA/.cache/rclone), which stores temporary “chunks” during cloud syncs.

Since the ZimaOS UI doesn’t allow you to change the Backup parameters or the cache location directly, here is a persistent fix using a symbolic link.

The Requirement

You will need a secondary storage drive (NVMe, SSD, or HDD) that is permanently mounted via the ZimaOS Storage Manager.

[!CAUTION]

Do not use a temporary USB stick or a drive that isn’t auto-mounted at boot. If the drive is missing when the backup starts, Rclone may bug out or default back to filling your system drive.

The Solution: Persistent Symlinking

1. Locate your Storage Path

Find where your large drive is mounted. In ZimaOS, these are usually found under:

/DATA/.media/your_drive_name

2. Create the new Cache folder

Run this in the terminal (replace your_drive_name with your actual path):

mkdir -p /DATA/.media/your_drive_name/rclone_cache

3. Wipe the bloated system cache

Make sure no backups are currently running in the UI.

sudo rm -rf /DATA/.cache/rclone

4. Create the Symbolic Link

This redirects the system to use your large drive instead of the internal storage:

ln -s /DATA/.media/your_drive_name/rclone_cache /DATA/.cache/rclone

To confirm the redirection is active, run:

ls -ld /DATA/.cache/rclone

The output should show an arrow pointing from the system path to your storage drive. Your system drive should now show a significant increase in free space!

Why this works

  • Persistence: Because /DATA is a persistent partition on ZimaOS, this link survives reboots.

  • Drive Health: Moving the cache to a secondary drive prevents unnecessary wear and tear on your internal system drive.

  • Seamlessness: The Backup app continues to work as intended, unaware that the data is actually living on your secondary storage.

Text was produced with ai, because I am not really good with English.
Note: last time Backup filled my entire drive (EMMC 64GB) and stopped working (+ Google Drive link was broken). Tmp fix: wipe the rclone cache.

1 Like
2

Solid write-up :+1: This is a legit fix, and you’ve correctly identified the real culprit: rclone cache growth outside the UI’s control.

A few confirmations + small clarifications for others reading:

  • /DATA/.cache/rclone is persistent on ZimaOS and will happily fill eMMC/NVMe during large or stalled cloud syncs
  • The Backup app does not expose cache limits or cache path, so symlinking is currently the cleanest solution
  • Using /DATA/.media/<drive> is correct as long as the disk is auto-mounted at boot

Extra safety notes worth highlighting:

  • Stop the Backup task before deleting the cache (as you said)
  • Do not point the symlink to removable or flaky USB storage
  • If the target disk is missing at boot, rclone may recreate a real directory and start filling system storage again

Optional verification (for peace of mind):

df -h /DATA
du -sh /DATA/.cache

Bottom line:
This is a practical, reboot-safe workaround until IceWhale exposes rclone cache controls in the Backup app. Nice catch.

1 Like