How to Build an Automated Backup Server Agent with Borg and Restic on OpenClaw Raspberry Pi

Running Borg or Restic on a Raspberry Pi is straightforward. Both tools install from standard package repositories, both handle deduplication automatically, and both encrypt data at rest. The hard part is not the backup itself. The hard part is everything around it.

A typical home network has three to six devices that need backups: a workstation, a laptop, a NAS, maybe a media server. Each device needs its own schedule. Each backup job can fail silently if the target disk fills up, the network drops, or the source machine is asleep. Repository integrity can degrade without warning. Storage consumption creeps up unless you prune old snapshots on a regular cycle.

Cron jobs handle scheduling, but they do not handle reasoning. A cron job cannot decide to skip a backup because the target disk is 95% full and pruning should run first. It cannot notice that the last three backup attempts for one machine failed while others succeeded, suggesting a network issue specific to that device. It cannot compose a summary of last night's backup results and send it somewhere useful.

OpenClaw fills this gap. Running on the same Pi that hosts your backup repositories, it acts as an orchestration layer that calls Borg and Restic through shell commands, reads their output, and makes decisions based on results. The agent schedules jobs, monitors disk usage, verifies archives, handles pruning, and reports status. The Pi handles storage I/O and runs the backup tools. The LLM (accessed through cloud API calls) handles the reasoning about what to do when conditions change.

This architecture keeps costs low. A Raspberry Pi 5 with an NVMe SSD draws around 5 to 8 watts under load. Cloud API costs for the agent's reasoning stay minimal because backup orchestration involves short, infrequent prompts. The backup tools themselves are free and open source.

Borg and Restic solve the same core problem, but they make different tradeoffs that matter on resource-constrained hardware.

Borg is written in Python with C extensions. It uses content-defined chunking for deduplication and supports zstd compression, which saves 30% to 50% additional storage beyond what deduplication alone provides. Encryption uses AES-256 in CTR mode with HMAC-SHA256 for authentication. On a Raspberry Pi, Borg's peak memory usage stays around 75 MB regardless of repository size, making it the safer choice when RAM is limited. Borg also supports FUSE mounting, so you can browse backup archives like a regular filesystem without restoring entire snapshots.

Restic is written in Go and compiles to a single static binary. It encrypts all data with AES-256 and authenticates with Poly1305-AES. Key derivation uses scrypt with default parameters (N=65536, r=8, p=1), which means the encryption key is derived from your password in a way that resists brute-force attacks. Restic's strongest advantage is backend flexibility: it supports local disks, SFTP, S3-compatible storage, Google Cloud Storage, Azure Blob Storage, and Backblaze B2 natively. If you want offsite copies of your backups, Restic handles that without additional tools.

Restic does not support compression (added only in newer experimental builds), and it uses more memory than Borg under identical workloads. On a Pi 4 with 2 GB RAM, this difference matters. On a Pi 5 with 8 GB, it is less of a concern.

The practical recommendation: use Borg for local backups to an attached drive, where its compression and low memory footprint deliver the most value. Use Restic for offsite copies to cloud storage, where its native S3 and B2 backends eliminate the need for rclone or other sync tools. Running both on the same Pi is common and well-supported, and an OpenClaw agent can manage both without conflict.

The agent does not care which tool it orchestrates. Both Borg and Restic produce structured output that the agent can parse. Both return nonzero exit codes on failure. Both support verification commands that confirm archive integrity. The orchestration logic is the same either way: run the backup, check the result, decide what to do next.

Hardware

A Raspberry Pi 5 with 8 GB RAM is the recommended base. The Pi 4 with 4 GB works but limits concurrent backup operations. Attach an NVMe SSD through a PCIe HAT (Pimoroni NVMe Base, Pineberry Pi HatDrive) for backup storage. NVMe on the Pi 5 delivers 400 to 800 MB/s sequential read throughput depending on the drive, which comfortably exceeds gigabit Ethernet speeds. This means the network connection, not the disk, is the bottleneck for incoming backups from other machines.

For bulk storage, a USB 3.0 external drive works as a secondary target. USB 3.0 on the Pi 5 caps around 300 to 400 MB/s, which is still faster than gigabit Ethernet. Avoid relying on SD cards for backup repositories. They wear out under sustained write loads and lack the throughput for multi-device backup workloads.

Total hardware cost: $80 to $120 for the Pi 5 kit, $30 to $60 for a 1 TB NVMe SSD, and $15 to $25 for a PCIe HAT. Under $200 for a backup server that draws 5 to 8 watts.

Operating system and backup tools

Flash Raspberry Pi OS Lite (64-bit) using Raspberry Pi Imager. After first boot and system updates, install the backup tools:

sudo apt update && sudo apt install borgbackup

For Restic, download the latest ARM64 binary from the project's GitHub releases page and place it in /usr/local/bin. The Debian/Raspbian package repositories sometimes lag behind the latest release, and newer versions include performance improvements that matter on ARM hardware.

Initialize your backup repositories on the attached storage:

borg init --encryption=repokey /mnt/nvme/borg-repo
restic init --repo /mnt/nvme/restic-repo

Borg's repokey mode stores the encryption key inside the repository (encrypted with your passphrase). Restic stores key files as JSON documents in the repository's keys directory. Both tools prompt for a passphrase at init time. Store these passphrases in a password manager or a separate encrypted file, not in plain text on the Pi.

OpenClaw installation

Follow the official Raspberry Pi installation guide at docs.openclaw.ai/install/raspberry-pi. The process involves installing Node.js 24 from the NodeSource ARM64 repository, running the OpenClaw install script, and completing the onboarding wizard. For headless Pi deployments, use API key authentication rather than OAuth. The minimum requirements are 1 GB RAM and 500 MB free disk, so OpenClaw coexists comfortably alongside Borg and Restic on a Pi 5 with 8 GB.

Configure OpenClaw to use a cloud LLM provider (Anthropic Claude, OpenAI GPT, or Google Gemini). The Pi does not run models locally. It sends prompts to the cloud API and acts on the responses. Backup orchestration prompts are short and infrequent, so API costs for this use case are negligible.

Give Your Backup Agent a Persistent Workspace

Store backup reports, query them with AI, and share status with your team. generous storage, MCP-ready endpoint, no credit card required.

Start 14-Day Trial

With Borg, Restic, and OpenClaw installed on the same Pi, the next step is defining the orchestration logic. The agent needs to know which devices to back up, which tool to use for each, where to store the results, and what to do when something goes wrong.

Defining backup targets

Create a configuration file that maps each device on your network to its backup parameters. For each source machine, specify the hostname or IP, the paths to back up, the backup tool (Borg or Restic), the target repository path, the retention policy (how many daily, weekly, and monthly snapshots to keep), and the preferred schedule window.

Machines that run SSH can be backed up by Borg over the network using borg create with an ssh:// prefix. Restic supports SFTP natively for the same purpose. The Pi pulls data from each source machine, so the source machines do not need Borg or Restic installed locally for a pull-based setup. They only need an SSH server running and a user account with read access to the target paths.

The orchestration loop

The agent's core logic follows a predictable cycle:

1. Check disk usage on the backup drive. If usage exceeds a threshold (say 85%), run pruning before starting new backups
2. For each backup target, check if it is reachable on the network
3. Run the scheduled backup for each reachable target
4. Capture the tool's output (bytes transferred, deduplication ratio, duration, errors)
5. Run a verification check on recently created archives
6. Compose a status summary
7. If any step failed, decide whether to retry, skip, or alert

The agent runs each step by executing shell commands and reading stdout/stderr. Borg and Restic both produce parseable output. Borg supports --json for machine-readable results. Restic outputs structured text that includes snapshot IDs, file counts, and byte totals.

Handling failures

Backup jobs fail for common reasons: the source machine was offline, the network timed out, the repository was locked by a previous interrupted job, or the disk ran out of space. A cron-based setup would silently skip the failed job and try again tomorrow. The agent can do better.

For a locked repository, the agent can check how long the lock has existed. If the lock is stale (say older than two hours with no active process), it can remove it with borg break-lock or by deleting Restic's lock file, then retry. For a network timeout, the agent can retry after a delay, then skip and flag the device if retries fail. For disk space issues, the agent can run an emergency prune with aggressive retention settings to free space, then retry the original backup.

These are judgment calls that a cron job cannot make but an LLM-driven agent can. The agent evaluates the error, picks the appropriate remediation, and executes it.

Backups that are not verified are not backups. Both Borg and Restic include verification commands that confirm archive integrity without performing a full restore.

Verification

Borg's verify command reads every chunk in an archive and confirms that checksums match:

borg check --verify-data /mnt/nvme/borg-repo

This is a slow operation that reads the entire repository. On a 500 GB repository with NVMe storage, expect 15 to 30 minutes. Schedule it weekly rather than after every backup.

Restic's equivalent checks the repository structure and data integrity:

restic check --read-data --repo /mnt/nvme/restic-repo

The --read-data flag forces Restic to read and verify every pack file. Without it, Restic only checks the metadata tree, which is faster but less thorough.

The agent can schedule verification during off-peak hours (say 3 AM on Sundays) and report the results. If verification finds corruption, the agent can flag the affected archives and notify you with the specific error output.

Pruning and retention

Without pruning, backup repositories grow indefinitely. Both tools support retention policies that specify how many snapshots to keep by time period.

Borg prunes with:

borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /mnt/nvme/borg-repo

Restic uses a similar syntax:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune --repo /mnt/nvme/restic-repo

Restic's forget command marks snapshots for removal, and the --prune flag actually reclaims disk space. Without --prune, the data stays on disk.

The agent manages pruning as part of the orchestration cycle. Before running backups, it checks disk usage. If usage is above the configured threshold, it runs pruning first, confirms that space was reclaimed, and then proceeds with the backup schedule. After pruning, the agent can compare the before and after disk usage and include the delta in its status report.

Offsite copies with Restic

For offsite redundancy, the agent can maintain a second Restic repository on S3-compatible storage (AWS S3, Backblaze B2, Wasabi, or MinIO). After completing local backups, the agent runs a Restic copy from the local repository to the remote one. Restic's copy command transfers only new data, so bandwidth usage stays proportional to the amount of new content, not the total repository size.

A backup server that reports only to local log files is a backup server you stop checking after two weeks. The agent needs to send its status reports somewhere visible.

Local options include writing logs to /var/log, sending email via a local MTA, or posting to a webhook. These work but create yet another system to maintain. The email server can break. The webhook endpoint can go down. Log files fill up and rotate out of view.

A cloud workspace provides persistent, searchable storage for backup reports that you can access from any device. Fastio offers free workspaces for agent workflows: 50 GB of storage, included credits, and 5 workspaces with no credit card or trial expiration. The OpenClaw agent can write its backup reports as files to a Fastio workspace through the MCP server or REST API.

Each backup cycle produces a report file with the date, per-device results, deduplication ratios, bytes transferred, any errors encountered, and the current disk usage summary. The agent uploads this file to a designated workspace. Over time, the workspace becomes a searchable archive of your backup history.

With Intelligence Mode enabled on the workspace, Fastio auto-indexes uploaded reports for semantic search. You can ask questions like "which devices had backup failures last week" or "show me the disk usage trend for the Borg repository" and get answers with citations pointing to specific report files. This turns a pile of daily backup logs into a queryable knowledge base.

For teams managing shared infrastructure, the workspace doubles as an audit trail. Every backup run, every pruning operation, and every verification result is documented and timestamped. If a restore is needed months later, you can search the workspace to find exactly when the last successful backup ran for a specific device and which archive contains the data you need.

Other cloud storage options work too. S3, Google Drive, Dropbox, or a self-hosted Nextcloud instance can all receive backup reports via API. Fastio's advantage for this workflow is that the MCP tooling gives the agent native access to upload, search, and query files without building custom API integrations. The agent can also create branded shares to send backup summaries to specific people, or set up a workspace where multiple agents from different locations report to the same central dashboard.

Alternatives like S3 or Google Drive require more setup for the search-and-query layer, but they are solid choices if you are already using them for other infrastructure.

A backup agent that runs silently is useful. One that alerts you when something needs attention is essential.

Alerting on failure

The agent should distinguish between transient failures (a laptop was closed during its backup window) and persistent ones (the same device has failed three consecutive backups). Transient failures get logged but do not trigger alerts. Persistent failures get escalated.

The simplest alerting path is a webhook to a messaging service. If OpenClaw is configured with Telegram or Discord messaging, the agent can send a message directly when it detects a persistent failure. The message includes the device name, the error output from the backup tool, and what remediation the agent attempted.

For teams, posting backup status to a shared workspace on Fastio means everyone with access can see the current state without subscribing to individual alerts.

Tracking deduplication and storage trends

Borg typically achieves deduplication ratios between 3:1 and 10:1 on workstation data with daily backups, depending on how much content changes between snapshots. The agent can track these ratios over time and flag unusual changes. A sudden drop in deduplication ratio might indicate that a source machine started generating large amounts of unique data (like video renders or database dumps), which is worth knowing before the backup drive fills up.

The agent can write a weekly storage summary that includes total repository size, deduplication ratio, largest archives by source device, and projected days until the drive reaches capacity at the current growth rate. This kind of trend analysis is tedious to script with bash but straightforward for an LLM-driven agent that can read numbers and reason about them.

Scaling to more devices

Adding a new device to the backup rotation means adding an entry to the configuration and ensuring SSH access from the Pi. The agent handles the rest. Borg and Restic both support multiple concurrent connections, though on a Pi you will want to limit concurrency to two or three simultaneous backup jobs to avoid saturating the network or overwhelming the SSD with random writes.

For networks with more than 10 devices, consider running Restic's rest-server on the Pi. This provides an HTTP-based backup endpoint that clients can push to directly, rather than the Pi pulling via SSH. The rest-server approach reduces SSH overhead and lets each client manage its own backup schedule while the agent monitors the shared repository.

If your backup needs outgrow a single Pi, the architecture scales horizontally. A second Pi handles a different set of devices, and both agents report to the same Fastio workspace. The shared workspace becomes the single pane of glass for your entire backup infrastructure, with Intelligence Mode letting you query across all reports from all agents.