I lost a week of OpenClaw configuration once. Not because of a hack or a hardware failure. Because I ran a system update that corrupted my SD card. Everything — my config, my custom skills, my memory files, my cron job definitions — gone.
Rebuilding took an entire weekend. And the worst part: I knew I should have had backups. I just kept putting it off because “I’ll set it up tomorrow.”
Here’s the backup strategy I use now. It takes 20 minutes to set up and runs automatically. No excuses.
What Needs Backing Up
Not everything. OpenClaw itself can be reinstalled. The operating system can be reflashed. What can’t be easily recreated:
Configuration files. Your main config (YAML), API keys, model settings, integration configurations. This is hours of careful tuning that you don’t want to redo.
Memory and workspace files. Long-term memory, daily notes, project documentation, custom instructions. This is your agent’s accumulated knowledge.
Custom skills. Any skills you’ve written or modified. Community skills can be reinstalled, but your custom ones exist only on your machine.
Session history. Optional — depends on whether you care about past conversations. I keep 30 days of history for reference, but I wouldn’t cry if it disappeared.
Cron job definitions. Your scheduled tasks and their configurations. Recreating these from memory is error-prone.
The Backup Strategy
Three layers, each serving a different purpose:
Layer 1: Daily local backup. A cron job that runs at 2 AM, copies the critical directories to a dated folder on the same machine. This protects against accidental deletion and config mistakes. If I mess up a config file at 3 PM, I can restore last night’s version in seconds.
Retention: 7 days of daily backups. Older ones get automatically deleted.
Layer 2: Daily remote backup. After the local backup completes, rsync copies the backup to a second machine (I use a NAS on my home network, but a cheap VPS works too). This protects against hardware failure. If the Pi’s SD card dies, the backup exists elsewhere.
The rsync command is simple: rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. The --delete flag keeps the remote copy in sync without growing indefinitely.
Layer 3: Weekly cloud backup. Every Sunday, the critical config files (just the small stuff — config, skills, memory files — about 5MB total) get encrypted and uploaded to cloud storage. This is the disaster recovery layer. If my house burns down and takes both the Pi and the NAS, I still have my configs.
I use rclone to sync to Backblaze B2 (pennies per month for this amount of data). The files are encrypted locally before upload using GPG.
The Backup Script
The entire backup is one bash script, about 30 lines long:
1. Define the directories to back up (config, workspace, skills, sessions)
2. Create a dated tarball of those directories
3. Keep the last 7 local tarballs, delete older ones
4. Rsync the latest tarball to the remote server
5. On Sundays: encrypt and upload to cloud storage
6. Log the result (success/failure, sizes, duration)
The script runs via cron at 2 AM daily. Total execution time: about 30 seconds for a typical installation.
Testing Restores
A backup you’ve never tested is not a backup — it’s a hope.
Every month, I do a restore test. Not on my production Pi — on a spare SD card. Flash a fresh OS, install OpenClaw, restore from backup, and verify everything works. The whole test takes about 30 minutes.
Things I’ve caught in restore tests:
– A backup path that changed after an OpenClaw update (the directory structure moved)
– A cron job definition that referenced a local path not included in the backup
– An API key that was stored in an environment variable instead of the config file (and therefore wasn’t backed up)
Each of these would have been a nasty surprise during a real recovery. Better to find them during a calm Saturday test than during a 3 AM emergency.
The Recovery Procedure
When things go wrong, you want a checklist, not a decision tree. Here’s mine:
1. Flash fresh OS on new SD card / SSD
2. Install Node.js and OpenClaw
3. Copy backup tarball to the new system
4. Extract to the correct directories
5. Verify API keys and connections
6. Start OpenClaw and verify basic functionality
7. Check cron jobs and scheduled tasks
8. Verify memory and workspace files are intact
Total recovery time: about 45 minutes from a blank SD card to a fully operational system. Compare that to the weekend I spent rebuilding without backups.
What Most People Get Wrong
Backing up too much. You don’t need to back up the entire system. The OS and OpenClaw itself are easily reinstalled. Back up only what’s unique to your installation.
Not backing up API keys. If your API keys are in environment variables instead of config files, they won’t be in your backup. Move them to the config file or maintain a separate secure document with all keys.
No remote copy. A backup on the same machine that fails is no backup at all. At minimum, copy to a second machine. The simplest version: email yourself the config file once a week.
Never testing restores. Test your restore process before you need it. The time to discover that your backup is incomplete is not during an emergency.
🕒 Last updated: · Originally published: December 27, 2025