Borg Backup Raspberry Pi Setup That Works

Introduction

Backups you can restore. Sounds obvious, right? But let’s be honest, most people treat backups like a new year’s resolution: full of ambition, completely forgotten by February. The Raspberry Pi makes a perfect little backup node, but you’ve got to do it right. That’s where Borg steps in. It’s lean, deduplicates like a pro, and encrypts without giving you a migraine.

Prune policies? Those aren’t just digital diet plans. They decide whether your backups actually help you in a crisis or just hog space until they rot. I’ve seen folks pile up hundreds of archives and then realize they can’t find a single restorable version that matters. So in this article, I’ll walk you through setting up Borg on a Raspberry Pi, using prune policies that don’t backfire, and restoring files without losing hair—or your weekend.

Key Takeaways

Borg on Raspberry Pi works well with even modest hardware if set up correctly.
Deduplication, encryption, and compression are handled efficiently with Borg.
Prune policies protect storage while preserving important snapshots.
Automating backups with cron or systemd makes the system reliable over time.
Always test restores—don’t wait until failure to find out your backups are junk.
Remote backups via SSH or rclone provide offsite protection.
Maintenance like disk checks and borg check can prevent long-term issues.
Use logging and alerts to keep tabs on backup success or failure.
Avoid common mistakes like pruning before a failed backup.
Keep scripts clean, tested, and safe with proper permissions and paths.

Core Features of Borg That Actually Help

What Deduplication Really Means

Deduplication in Borg isn’t some buzzword tossed into a README. It actually identifies repeating chunks across your data and stores them once. That means if you’re backing up five Pi projects with nearly identical folder structures, Borg doesn’t copy the same code five times. Instead, it links to the same chunk. Less disk space used, faster backups. You’ll notice the savings especially with logs, configs, and cloned repos.

Encryption Without Adding Drama

Encryption is built-in with Borg and it doesn’t demand you go through GPG hell. You choose the mode, enter a passphrase once, and Borg handles the rest. It encrypts metadata and data. Perfect for remote backups where snooping might be an issue. Just don’t lose your key file. Seriously. No cloud reset, no support ticket—you’re locked out for good.

Compression That Saves Time and Space

Borg offers multiple compression algorithms: zlib, lz4, zstd. LZ4 is great for speed, zlib for space savings, and zstd sits somewhere in the middle. You can tweak this depending on what you’re backing up—source code, media files, logs. It’s not about choosing the best one universally, it’s about what works for your setup.

Why “Mounting Archives” Is a Game Changer

Mounting an archive is like time travel for your file system. Need a version of a file from last Tuesday? Mount that day’s archive and browse like it’s still there. No extraction needed. No tarballs. Just borg mount, and it appears like a regular folder. It’s the lazy, smart, and reliable way to check what’s been saved without unpacking a thing.

Building a Raspberry Pi Backup Setup That Won’t Fail

What Hardware Can Handle It

You don’t need a Pi 5 with liquid cooling and an LED case. Even a Pi 3 can handle Borg if you’re not pushing terabytes. The sweet spot is a Pi 4 with 2GB or more. It has enough RAM to compress, encrypt, and deduplicate without crawling. Use a heatsink and a fan if you’re running regular jobs or mounting external drives.

MicroSD vs SSD: Real Talk

Yes, SD cards wear out. No, you shouldn’t rely on them for backup storage. Use an SSD via USB 3.0 or even a spinning HDD if budget matters more than speed. MicroSD cards can still host the OS, but don’t trust them to hold weeks of archives. One power blip during a write and you’re toast.

How to Not Brick Your Pi During Backups

Avoid powering USB drives from the Pi directly. Use powered hubs or self-powered enclosures. Monitor your voltage with vcgencmd get_throttled—if you see throttling, you’re asking for corruption. Don’t schedule intensive jobs during boot or shutdown either. Use systemd to delay backups until the Pi is fully up.

Wiring and Power Tips Nobody Tells You

Cheap cables ruin everything. A flaky micro-USB or USB-C cable can make your Pi restart mid-backup. Use a good 3A+ PSU and a short, shielded USB cable. Label your wires. If you move the Pi or disconnect it and plug things back differently, your mount points might change and wreck the script. Use UUIDs, not /dev/sda1, if you like sleep.

Automating the Backup Without Breaking Stuff

Writing a Cron Job That Doesn’t Backfire

Cron is reliable but dumb. It doesn’t care if your Pi is halfway through booting or about to reboot. Schedule backups when the system’s idle and stable. Midnight might sound cool until you realize that’s also your weekly update time. Use absolute paths in your cron scripts and redirect output to log files so you can figure out what broke at 3 a.m.

Systemd Timers for the Brave and Bold

Systemd timers are smarter than cron. You can set dependencies so backups only run after networking is up or a drive is mounted. Want it to run ten minutes after boot? Use OnBootSec=10min. Want it daily at a certain time? Use OnCalendar=daily. But don’t forget the Persistent=true setting, or missed timers won’t get retried later.

Logging to Know If Anything Even Worked

Your backup ran. Or did it? You’ll never know unless you log it. Redirect stdout and stderr to a log file in /var/log/borg-backup.log. Better yet, use logger to push messages to syslog. Add alerts if the return code isn’t 0. You don’t need Grafana dashboards. Just enough info to tell if you’re safe or hosed.

Using Scripts to Prune Without Panic

Backups are useless if they bloat and fail silently. Prune your archives right after a successful backup. Tie both commands in one script, and only prune if the backup completed. Use Borg’s --keep-daily, --keep-weekly, --keep-monthly options, and test the script with dry-run mode first. Because the only thing worse than no backups is wiping them all with a typo.

Using Prune Policies Like a Human, Not a Robot

Translating Daily/Weekly/Monthly into Real Use

Borg’s prune options aren’t just numbers—they’re your memory timeline. --keep-daily=7 means a week’s worth of snapshots. --keep-weekly=4 adds a month. --keep-monthly=6 gives you a half-year window. That’s usually enough to roll back from most disasters. Don’t go crazy unless you have storage to burn.

Keeping Just Enough Without Losing History

Too many backups clog up space and waste CPU during checks. Too few and you can’t recover a file you didn’t know you needed. Think of your workflow: If you change things daily, keep more dailies. If it’s a media server that doesn’t change much, keep more weeklies. Balance frequency with retention so your drive doesn’t scream every time it runs borg check.

How to Avoid Deleting the One Good Backup

Don’t prune before a backup. Always run it after. Why? Because if your new backup fails, and you’ve already deleted the old ones, you’re left with nothing. Tie pruning to successful backups only. Run it with --dry-run first so you can see what it plans to kill. Consider using --keep-within=30d if you want flexible time-based control.

Sample Policy Config That Works

Here’s one that fits most setups:

borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1

It covers one week of detail, one month of trends, half a year of snapshots, and a year of “oh right, that thing I deleted last winter.” Works for Raspberry Pis running code, media boxes, or homelab gear.

Restoring a Backup Before It’s Too Late

Mounting Archives to Browse What’s Inside

Instead of guessing what’s in an archive, just mount it. Use borg mount /path/to/repo::archive-name /mnt/restore and it shows up like a regular folder. You can browse it with your file manager or ls. No unpacking, no waiting. Great for checking that the backup actually contains what you expect before wasting time extracting.

How to Pull a Single File Out Like a Pro

If you just need one config file or photo, no need to unzip the whole archive. Use borg extract with the path to the file:

borg extract /repo::archive-name etc/nginx/nginx.conf

Boom, just that file. Keep your paths clean and always double-check what you’re extracting with borg list first.

Restoring Full Systems Without Headaches

Restoring an entire system? Mount the archive, rsync it to your target, and fix bootloader stuff manually. Don’t just overwrite a running OS. That’s asking for a bad day. For SD card systems, restore onto another card and test it before switching. For USB boot setups, you might need to fix fstab or re-run grub-install.

Testing Your Restore Before Disaster Hits

Run test restores. Seriously. Once a month, restore something to a temp folder. If you wait until a crash to find out your backups are junk, you’ve already lost. Automate a mini-restore test and have it email or log success. Trust is earned, even from your own scripts.

Remote Backups and Offsite Options

Using SSH for More Than Just Login

SSH isn’t just for logging into the Pi. It’s the backbone of remote backups. Borg can write directly over SSH to a remote server:

borg init user@host:/backup/repo

Then back up like it’s local. Use key-based auth, not passwords, and lock it down with a dedicated user that can only run Borg.

Rclone to Push to the Cloud

If you’re set on cloud backups, combine Borg with rclone. Back up locally with Borg, then use rclone to sync the repository to Backblaze B2, Wasabi, or any other cheap blob storage. It’s not elegant, but it works. Use rclone sync or rclone copy depending on how paranoid you are about deletions.

Securing Backups in Transit and at Rest

Use encryption. Always. Even if it’s just going across your home network. You never know who’s sniffing packets. Borg handles encryption at the repo level, so even if someone steals the whole archive, it’s just gibberish. Also, use rsync over SSH or Borg’s native transport, not open SMB shares.

Storing to a NAS from the Pi Without Rage

Want to send backups to a NAS? Mount it with NFS or CIFS, but watch for disconnects and permissions. Use systemd mounts with retry options. Make sure your Borg repo isn’t corrupt after a failed network transfer. If you’re serious, test by pulling the plug mid-backup and checking if the repo survives.

Maintenance Tips So You Don’t Regret Skipping Them

Disk Space Checks You Should Automate

A full drive during backup? That’s how you get corrupt archives. Use df -h or du -sh to keep tabs on free space. Better yet, script it and alert yourself when space drops below a threshold. Don’t trust your instincts—set a limit like 80 percent and stick to it.

How Often to Run Borg Check

You don’t need to run borg check every day, but don’t wait six months either. Once a week is a good rule for active systems. It checks the integrity of your archives and repo structure. Add --verify-data occasionally if you’ve got time and CPU to spare. That dives deeper and reads every chunk.

Fixing Locked Repos Without Losing Your Mind

Repo locked? It happens if a previous run crashed or the Pi rebooted mid-task. Use borg break-lock to clear it, but only if you’re sure no other process is running. You can check with ps aux | grep borg. If you break a lock while another backup is writing, you could trash everything.

Verifying Archives Like a Rational Human

Verifying isn’t just about file counts. Mount your archive, check for real data, try opening a document, booting a restored image. Trust, but verify. Automate a restore into a temporary folder once a month and log the success. It’s boring, yes. But so is rebuilding everything from scratch.

Things That Go Wrong and How to Handle Them

SD Card Dies Mid-Backup: What Now?

If your SD card kicks the bucket mid-backup, you’re probably left with a half-written archive and a locked repo. Boot from another card, mount the damaged one read-only, and salvage what you can. Avoid writing anything. If your Borg repo is intact, borg check --repair might rescue it. Otherwise, time to test that offsite backup.

Permissions Nightmares and How to Avoid Them

Borg hates permission mismatches. If it can’t read a file or write to the repo, it bails. Use a dedicated backup user with read-only access to important folders and write access to the repo. Always test your script as that user, not root. sudo might mask real issues until it fails under cron.

SSH Key Woes and Lockouts

SSH keys expire, get renamed, or just vanish. Don’t hard-code paths. Use ~/.ssh/config with named hosts and key paths. Rotate keys occasionally and test logins manually. Lock down authorized keys with command="borg serve" to stop them from being used for anything else.

Corruption and Recovery Steps That Actually Work

If a backup archive is corrupt, delete just that one using borg delete and re-run the backup. Don’t delete the whole repo unless you’ve completely lost control. If multiple archives are failing, run borg check --repair and read every line of output like it’s a treasure map. The good news? Borg usually isolates damage pretty well.

Scripts and Commands You’ll Reuse All the Time

Backup Script Template

A basic backup script might look like this:

#!/bin/bash
export BORG_REPO=/mnt/backup/borg
export BORG_PASSPHRASE='yourpassphrase'

borg create --stats $BORG_REPO::'{hostname}-{now}' /etc /home /var/log

if [ $? -eq 0 ]; then
  borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6
else
  echo "Backup failed" | logger
fi

Prune and Retention Template

Use this after a successful backup only:

borg prune --list $BORG_REPO   --keep-daily=7   --keep-weekly=4   --keep-monthly=6   --keep-yearly=1

Restore and Mount Commands

To browse an archive:

borg mount $BORG_REPO::archive-name /mnt/restore

To extract everything:

borg extract $BORG_REPO::archive-name

Logging That Makes Sense Later

Log both stdout and stderr to a file:

/path/to/backup.sh >> /var/log/borg-backup.log 2>&1

Or send important output to syslog with:

logger "Borg backup completed successfully"

Test these scripts before scheduling them. One wrong variable and you could back up nothing for weeks.

FAQ

How often should I run a backup with Borg?
Daily is a good default. If you’re changing files more often, consider twice a day. For static setups, weekly might be enough.

Can I back up multiple Raspberry Pis to the same Borg repo?
Yes, but use different archive names or prefixes to avoid confusion. Tag each archive with the hostname.

What happens if I forget my Borg encryption passphrase?
You’re done. No recovery. No customer service. Keep your key safe, and store a copy in a password manager.

Does pruning delete all my backups?
No, unless you tell it to. Use --dry-run to preview what gets removed before you commit.

Can I back up to Google Drive or Dropbox?
Not directly. Use rclone to sync your Borg repo after the backup. It’s slow but works in a pinch.

How do I restore just one file?
Use borg extract with the file path. Mounting the archive works too if you prefer browsing.

Do I need root to run backups?
Not always. Depends on what you’re backing up. Some system files may need elevated access.

What’s the difference between Borg and rsync?
Borg is smarter: deduplication, encryption, compression, and versioned archives. rsync is simpler but more manual.

How big will my backups get?
Depends on your data. Borg’s deduplication and compression help keep it small, but logs and media can still grow fast.

Is Borg overkill for a Raspberry Pi?
Not at all. It’s lightweight enough for a Pi and powerful enough to scale if your needs grow.

References

Was this helpful?

Yes

Thanks for your feedback!