OpenClaw Disaster Recovery Agent for Raspberry Pi SD Card Backup and Cloning

The Raspberry Pi Foundation's own recommendation for SD-card-heavy workloads is to move to an SSD. That recommendation exists because consumer SD cards have finite write endurance, and an always-on agent host burns through it faster than most hobbyist setups. System journals, OpenClaw conversation history, scheduled-task logs, and workspace artifacts all hit the same flash. When the card reaches its limit the filesystem goes read-only, the agent keeps running from memory until the next reboot, and then nothing comes back.

The gap in most backup guides is that they describe a procedure, not a system. You read a tutorial, run dd once, feel responsible for a week, and then stop. A 2026 survey of Raspberry Pi forum threads shows the same pattern: users ask about backup after a failure, not before. The guides themselves are thorough, covering dd, SD Card Copier, rpi-clone, and rsync, but none of them automate the cycle of image, compress, verify, and ship off-site.

That automation gap is exactly what an OpenClaw agent can fill. OpenClaw runs as a daemon on the Pi, executes shell commands, and persists state across reboots in ~/.openclaw/. The same runtime that schedules your other agent tasks can schedule a backup, check whether it completed, and notify you if it didn't. Instead of a procedure you remember to follow, you get a process that runs whether you remember or not.

A few realities make this more urgent than it sounds:

• A 32 GB SD card clone with dd takes roughly 5 to 15 minutes depending on USB bus speed and card class. That's short enough to run nightly without disrupting workloads.
• Gzip compression typically reduces a 32 GB raw image to 5 to 8 GB. That fits comfortably on a 16 GB USB drive or ships to cloud storage without burning through bandwidth.
• The failure mode is silent. SD cards don't warn you. They go read-only or corrupt the FTL mapping table and stop booting.

If your Pi runs anything you'd rather not rebuild from scratch, an automated backup agent is cheaper than the time you'll spend if you skip it.

Helpful references: Fastio Workspaces, Fastio Collaboration, and Fastio AI.

Not every backup tool works the same way, and the right choice depends on whether you prioritize speed, storage efficiency, or the ability to back up while the Pi is running.

Full disk image with dd

The simplest approach. dd copies every block on the SD card to an image file, including empty space. The result is a byte-for-byte clone that can be written back to any card of equal or greater size. The downside is that it copies unused blocks too, so a 32 GB card always produces a 32 GB raw image. Compression with gzip or pigz brings that down to the 5 to 8 GB range for a typical Raspberry Pi OS installation.

rpi-clone

This tool uses rsync internally to copy only occupied blocks to a destination drive. It's faster than dd for partially filled cards because it skips empty space. The geerlingguy fork works on Raspberry Pi OS Bookworm and Pi 5 hardware. The output is a bootable drive, not an image file, so you can swap it in directly if the original card fails.

SD Card Copier (piclone)

A GUI tool pre-installed on Raspberry Pi OS Desktop. It clones the running system to a USB drive without requiring a shutdown. Useful for interactive one-off backups but hard to automate from a headless agent.

rsync to remote storage

File-level incremental backups. Fast for daily runs since only changed files transfer. The catch is that an rsync backup is not bootable on its own; you need a working OS to restore onto. Good as a supplement to full-image backups, not a replacement.

For an OpenClaw disaster recovery agent, the practical choice is dd piped through compression for the scheduled full backup. It produces a self-contained bootable image that doesn't depend on having a working Pi to restore. Pair it with rsync for more frequent incremental snapshots if you want finer recovery granularity.

The agent has three jobs: create a compressed image of the SD card, verify the image is not corrupt, and move it somewhere that isn't the SD card. Keep those responsibilities separate in the agent's design so a failure in one step doesn't silently skip the others.

The backup step

The core operation reads the SD card block device and pipes it through compression to a mounted USB drive:

sudo dd if=/dev/mmcblk0 bs=4M status=progress | gzip > /mnt/backup/pi-backup-$(date +%Y%m%d_%H%M%S).img.gz

A few details matter here. The bs=4M block size keeps throughput reasonable. status=progress gives the agent something to parse for completion percentage. The timestamp in the filename prevents overwriting older backups. On a Pi 4 with a USB 3.0 drive, a 32 GB card finishes in roughly 8 to 12 minutes compressed.

The verify step

A backup you can't restore is not a backup. After the image is written, the agent should verify it:

gunzip -t /mnt/backup/pi-backup-20260526_030000.img.gz

If gunzip -t exits non-zero, the image is corrupt and the agent should flag the failure rather than overwrite the last good backup. Keep at least two verified images on the USB drive so a failed backup run doesn't leave you with zero good copies.

The notify step

OpenClaw can send notifications through messaging channels like Telegram, Discord, or email. Wire the agent to report three things: successful backups with the image size, failed backups with the error, and storage capacity remaining on the USB drive. You don't need a dashboard. A message in your preferred channel is enough to confirm the system is working.

Scheduling the cycle

OpenClaw supports scheduled task execution through its runtime. The specifics depend on your installed version, so verify the scheduling interface against your current OpenClaw docs. The alternative is a standard cron entry that triggers the agent:

0 3 * * * openclaw run backup-agent

A 3 AM daily schedule avoids interfering with daytime workloads. Adjust the frequency based on how much state you can afford to lose. If your Pi collects sensor data or serves an application, you might want backups every 12 hours.

Store Pi backup images where your team can reach them

generous storage workspace storage, audit-trailed uploads, and MCP access for your OpenClaw agent. No credit card, no trial expiration.

Start 14-Day Trial

A USB drive sitting next to the Pi protects against SD card failure. It does not protect against power surges, theft, water damage, or the drive itself failing. For real disaster recovery, at least one copy of the backup image needs to live somewhere else.

Local network storage

The simplest off-site option is another machine on the same network. An rsync push from the Pi to a NAS, a desktop, or another Pi with larger storage moves the image without external dependencies. The weakness is that a network-local copy still shares the same physical risks as the original.

Cloud object storage

S3-compatible storage, Google Cloud Storage, or Backblaze B2 give you geographic redundancy for a few cents per gigabyte per month. The agent can use rclone or aws s3 cp to ship the compressed image after verification. Bandwidth is the constraint: uploading a 6 GB image on a typical home connection takes time, so schedule the sync after the backup window.

Fastio as the off-site destination

For OpenClaw deployments that already use Fastio as a workspace, the same platform works as a backup destination. The agent can upload compressed images to a dedicated workspace through the Fastio MCP server or API, giving you versioned storage with audit trails and the ability to share backup images with a team. The Business Trial includes 50 GB of storage, enough for 6 to 8 compressed backups of a 32 GB card. No credit card required.

The advantage of a workspace-based destination over raw object storage is that the backup images become queryable and shareable. You can hand a workspace to a colleague who needs to restore a Pi without giving them SSH access to your infrastructure. Fastio's audit trail also logs every upload and download, so you know exactly which images were accessed and when.

Whatever off-site option you choose, the agent should track two things: the timestamp of the last successful off-site sync and the number of backup images stored remotely. If the remote copy falls more than one backup behind the local copy, that's worth an alert.

Backup agents are only useful if the restore path works. Test it before you need it.

Restoring to a new SD card from another machine

This is the most common scenario. Pull the compressed image from your USB drive or off-site storage, decompress it, and write it to a fresh SD card:

gunzip -c pi-backup-20260526_030000.img.gz | sudo dd of=/dev/sdX bs=4M status=progress

Replace /dev/sdX with the actual device path of the new SD card. Triple-check the device path. dd does not ask for confirmation and will happily overwrite your laptop's main drive if you point it wrong.

The target card must be at least as large as the source. A 32 GB image won't fit on a 16 GB card. If you're standardizing on a card size for a fleet of Pis, buy the same capacity across the board to avoid restore failures.

Restoring from a remote Fastio workspace

If your off-site copy lives in a Fastio workspace, download it through the web UI, API, or MCP server to any machine with a card reader. The workspace keeps every uploaded version, so you can roll back to a specific date if the most recent image has a problem.

Post-restore verification

After writing the image and booting the restored Pi:

1. Verify OpenClaw starts and its daemon is healthy. Check with systemctl status for the OpenClaw service.
2. Confirm agent state is intact: conversation history, scheduled tasks, OAuth tokens.
3. Check that the backup agent itself is scheduled and will resume its cycle. A restored backup that doesn't re-enable future backups creates a false sense of safety.
4. Run a test backup to the USB drive immediately. This confirms the restore didn't produce a read-only or degraded filesystem.

Recovery time

A full restore from a compressed image takes roughly the same time as the backup: 8 to 15 minutes for a 32 GB card. If you keep a pre-written spare SD card from a recent backup on the USB drive (via rpi-clone), the swap is even faster since you just pull the old card and insert the clone. Total downtime drops to however long a reboot takes, usually under two minutes.

Run a restore drill at least once before you depend on it. Monthly is better. The drill doesn't need to be destructive: write the image to a spare card, boot it in a second Pi or the same Pi with the original card removed, and verify that everything comes up.

Without a retention policy, your USB drive fills up and backups stop. The agent needs rules for how many images to keep and when to delete old ones.

A practical starting point:

• Keep the 7 most recent daily backups on the local USB drive.
• Keep one weekly backup for the past 4 weeks.
• Keep one monthly backup for the past 3 months.
• Delete everything older unless you have a specific reason to keep it.

Implement rotation as part of the backup agent's post-verification step. After a new backup is verified, the agent checks the backup directory, sorts by timestamp, and removes images that fall outside the retention window. Log every deletion so you have an audit trail.

Monitoring the USB drive

The backup drive itself has a finite lifespan, especially if it's another flash device. The agent should check available space before starting a backup and alert if free space drops below 20 percent. If you're using a spinning USB hard drive, SMART data can signal pending failures.

Handling backup failures gracefully

The most common failure modes are:

• USB drive not mounted (unplugged, USB port reset, kernel driver issue).
• Insufficient space on the destination.
• Network timeout during off-site sync.
• Corrupt image (power loss during write).

For each case, the agent should log the failure, keep the previous good backup untouched, and send a notification. Never let a failed backup overwrite or delete the last successful one.

Keeping the agent itself recoverable

The OpenClaw state directory at ~/.openclaw/ contains the agent configuration, credentials, and scheduled tasks that define the backup agent. OpenClaw's built-in openclaw backup create command archives this state into a portable .tar.gz file. Include that archive in your SD card backup image, and also keep a separate copy on your off-site storage. If you ever need to rebuild the agent from scratch rather than restoring an image, that archive gets you back to a working configuration without re-entering API keys and re-creating task schedules.