Backups, Safety, and Troubleshooting

A modified reMarkable Paper Pro is only as safe as the backup behind it. Because the entire root partition is overwritten on every OS update and any developer-mode change can leave the device unbootable, the durable safeguard is a copy of your own data plus a clear path back to a working state. This closing section covers pulling a full data backup over SSH, restoring after a mistake, reflashing a soft-bricked device with the official recovery tool, resolving the everyday sync and Wi-Fi failures, and the habits that keep a modified device maintainable across updates.

Backing Up Data over SSH

All documents managed by xochitl live at /home/root/.local/share/remarkable/xochitl/, stored as a flat set of UUID-keyed files. The device configuration, including the root password in plaintext, sits at /home/root/.config/remarkable/xochitl.conf — treat any backup of it as sensitive. Everything under /home survives OS updates, so a data-only backup is sufficient; full disk images are unnecessary because a stock OS can always be re-flashed. USB (the device presents itself at 10.11.99.1) is far faster than Wi-Fi for large transfers.

The simplest approach uses scp:

mkdir -p ~/remarkable-backup/files
scp -r root@remarkable:/home/root/.local/share/remarkable/xochitl/ ~/remarkable-backup/files/
scp root@remarkable:/home/root/.config/remarkable/xochitl.conf ~/remarkable-backup/

For repeat runs, rsync transfers only what changed. Note that rsync is not on the stock OS — it is installed via Toltec/Entware at /opt/bin/rsync, so the --rsync-path flag is required:

rsync -rv -zz --rsync-path=/opt/bin/rsync \
  --exclude='*.cache' --exclude='*.thumbnails' \
  root@remarkable:/home/root/.local/share/remarkable/xochitl/ \
  ~/remarkable-backup/files/

Figure 10.2: Backup and restore data flow between tablet and host

Restoring and Reflashing

If a device still boots and is SSH-reachable, restoring is a matter of copying files back and forcing a re-index:

scp -r ~/remarkable-backup/files/* \
  root@remarkable:/home/root/.local/share/remarkable/xochitl/
ssh root@remarkable systemctl restart xochitl

Figure 10.1: Recovery decision tree — from symptom to a restored device

When a modification leaves the device soft-bricked — no UI, no SSH — use the official software recovery, available only for the Paper Pro, Paper Pro Move, and Paper Pure. Keep the device powered on and connected to USB, hold the power button ~25-30 seconds, release for a second, do one short press, then release; this puts the NXP loader into serial-download mode. Recovery is also the required way to exit Developer Mode. On a Linux host, run the rm_recover tool:

chmod u+x rm_recover
./rm_recover restore   # reinstall software, KEEP user data
# ./rm_recover reset   # factory reflash, ERASE user content

Both restore and reset disable Developer Mode; use reset only if you intend to wipe data. Cloud-synced documents re-sync after sign-in regardless. Exit recovery by holding power ~7-10 seconds.

Troubleshooting Common Problems

Most day-to-day failures resolve without recovery. Wi-Fi and sync issues are frequently a 2.4 GHz/WPA2 mismatch or a drifted internal clock rather than a device fault.

Keeping a Modified Device Maintainable

OS updates preserve /home but replace the root partition wholesale, so any modification outside /home is erased on every update. Store your own scripts and files under /home/root so they persist, and plan to reapply out-of-/home mods afterward. Toltec must be re-enabled after each upgrade to recreate its root-partition changes; check the Toltec release notes before and after updating, since some upgrades need manual steps to avoid soft-bricking. Critically, never factory reset a device with Toltec installed — run toltecctl uninstall first. Take a fresh xochitl backup before any OS update or risky change so recovery is always clean.