Raspberry Pi Backup: SD Card, rsync, and Automated Methods

A Raspberry Pi backup strategy needs at least two things: a full system copy that lets you restore a dead SD card, and an automated file-level backup that runs without manual intervention. rpi-clone handles the full SD clone while the system is live. rsync handles incremental file backup to a local drive or remote server. rclone adds cloud backup for off-site copies. This guide covers all three with working commands, cron automation, and how to verify backups actually restore. For BorgBackup with retention policies and deduplication, see BorgBackup Raspberry Pi Prune Policies: Complete Setup Guide. For rclone cloud sync, see Rclone Raspberry Pi: Encrypt, Sync, and Cloud Setup Guide.

Last tested: Raspberry Pi OS Bookworm Lite 64-bit | May 2025 | Raspberry Pi 4 Model B (4GB) | rpi-clone 2.0.27, rsync 3.2.7, rclone 1.66, BorgBackup 1.2.8

Full Raspberry Pi Backup with rpi-clone

rpi-clone clones the Pi’s running SD card to a USB drive or second SD card while the system is live. No shutdown required. It copies the boot partition and root filesystem, resizes the root partition to fit the target device, and produces a bootable clone. Install it:

sudo apt update && sudo apt install -y git
git clone https://github.com/billw2/rpi-clone.git
cd rpi-clone
sudo cp rpi-clone /usr/local/sbin/

Connect a USB drive as the backup target. Identify the device name:

lsblk

The SD card is typically /dev/mmcblk0. The USB drive is typically /dev/sda. Run the clone:

sudo rpi-clone sda

rpi-clone prompts for confirmation before writing. It shows the source and target sizes. If the target is smaller than the source, rpi-clone automatically shrinks the filesystem to fit. The clone takes 5 to 20 minutes depending on SD card size and USB speed.

Expected result: rpi-clone reports “Cloning done” at completion. The USB drive is now bootable. To verify, remove the SD card, insert the USB drive, and boot the Pi. If the Pi boots and the system functions correctly, the backup is valid. If the target USB drive cannot boot the Pi, check that the Pi’s boot order includes USB and that the USB drive is fully seated.

For a full SD card image using dd (useful when the Pi is shut down or when the exact binary image is needed):

# Run from another Linux machine with the SD card inserted:
sudo dd if=/dev/sdX of=~/pi-backup-$(date +%Y%m%d).img bs=4M status=progress conv=fsync

Replace /dev/sdX with the SD card device. The status=progress flag shows transfer rate and progress. Without it, dd runs silently for the entire clone duration with no output. Restore with dd if=pi-backup.img of=/dev/sdX bs=4M status=progress or Raspberry Pi Imager’s “Use custom” option.

File-Level Raspberry Pi Backup with rsync

rsync copies only changed files since the last run, making it fast for frequent incremental backups of specific directories. It is the right tool for backing up a home directory, project files, configuration directories, or a database dump folder rather than the entire OS.

Back up the Pi’s home directory to a USB drive:

sudo rsync -avz --delete /home/youruser/ /mnt/backup/home-youruser/

The flags: -a preserves permissions, timestamps, symlinks, and ownership. -v shows each file being transferred. -z compresses data during transfer (useful over SSH, marginal benefit to local drives). --delete removes files from the destination that no longer exist in the source, keeping the backup an exact mirror.

Back up to a remote machine over SSH:

rsync -avz --delete -e ssh /home/youruser/ remoteuser@192.168.1.50:/backups/pi-home/

For SSH rsync to run unattended in a cron job, set up SSH key authentication first so the backup does not prompt for a password:

ssh-keygen -t ed25519 -C "pi-backup" -N "" -f ~/.ssh/backup_key
ssh-copy-id -i ~/.ssh/backup_key.pub remoteuser@192.168.1.50

Then use the key explicitly in the rsync command:

rsync -avz --delete -e "ssh -i ~/.ssh/backup_key" /home/youruser/ remoteuser@192.168.1.50:/backups/pi-home/

Expected result: rsync prints each transferred file and a summary at the end showing bytes transferred and transfer rate. On subsequent runs, only changed files are copied; a run with no changes outputs only the summary with zero bytes transferred. If rsync exits with an error, check the SSH connection manually with ssh -i ~/.ssh/backup_key remoteuser@192.168.1.50 before debugging the rsync command.

Cloud Backup for Raspberry Pi with rclone

rclone syncs files to over 40 cloud storage providers including Backblaze B2, AWS S3, Google Drive, and OneDrive. It supports client-side encryption so files are encrypted before leaving the Pi. For the complete rclone setup with encryption and cron scheduling, see Rclone Raspberry Pi: Encrypt, Sync, and Cloud Setup Guide. The summary here covers the core workflow.

Install rclone:

sudo apt install -y rclone

Configure a remote (interactive wizard):

rclone config

Follow the prompts to add a remote named b2 (Backblaze B2) or gdrive (Google Drive). After configuration, sync a directory to the remote:

rclone sync /home/youruser/ b2:your-bucket-name/pi-home/ --progress

rclone sync makes the destination match the source including deletions. Use rclone copy instead to add files without deleting anything from the destination.

Expected result: rclone reports files transferred and total data sent. On the cloud provider’s dashboard, the files appear in the configured bucket or folder. Subsequent runs transfer only changed files. If authentication fails, re-run rclone config to refresh the credentials for the affected remote.

Automating Raspberry Pi Backups with Cron

Both rsync and rclone run unattended in cron jobs. Add entries to the user crontab with crontab -e. Use full paths to binaries because cron’s PATH is minimal.

A practical automated backup schedule:

# Daily rsync to USB drive at 2am
0 2 * * * /usr/bin/rsync -az --delete /home/youruser/ /mnt/backup/home/ >> /home/youruser/backup.log 2>&1

# Weekly rclone cloud sync on Sunday at 3am
0 3 * * 0 /usr/bin/rclone sync /home/youruser/ b2:your-bucket/pi-home/ --log-file=/home/youruser/rclone.log

Always redirect both stdout and stderr to a log file (>> logfile 2>&1). Without this, cron silently swallows errors and you have no record of whether the backup ran or failed. Check the log file periodically to confirm backups are completing successfully.

For rpi-clone automation, run it weekly rather than daily because it writes the entire filesystem each time:

# Weekly rpi-clone to USB drive on Saturday at 4am
0 4 * * 6 /usr/local/sbin/rpi-clone -U sda >> /home/youruser/rpi-clone.log 2>&1

The -U flag runs rpi-clone unattended without confirmation prompts. Only use it after confirming the target device name is correct. An incorrect device name with -U will overwrite without asking.

Expected result: Cron fires at the scheduled times. Check that jobs are running by examining the log files the morning after the first scheduled run. If the log file is empty or absent, check systemctl status cron and verify the crontab entry was saved correctly with crontab -l.

Restoring and Testing Your Raspberry Pi Backup

A backup that has never been tested is an assumption. The restore test is the only confirmation that the backup is valid.

Testing an rpi-clone backup: Insert the clone target USB drive into the Pi, set the boot order to try USB first (via sudo raspi-config or sudo rpi-eeprom-config --edit), and reboot. If the Pi boots from the USB clone and the system functions normally, the backup is valid. Remove the USB drive and boot normally from the SD card when done.

Restoring a dd image: Use Raspberry Pi Imager on a desktop machine. Select “Use custom” and point it to the .img file. Flash to a new SD card. Insert and boot. Alternatively, use dd from a Linux machine:

sudo dd if=pi-backup-20260501.img of=/dev/sdX bs=4M status=progress conv=fsync

Restoring files with rsync: Reverse the source and destination to restore from backup to the Pi:

# Restore from USB backup to home directory:
rsync -avz /mnt/backup/home-youruser/ /home/youruser/

Do not use --delete on a restore unless you explicitly want files on the Pi that are not in the backup to be deleted. For partial restores, specify the individual file or directory path rather than the entire backup source.

Expected result: The restored Pi boots and all expected files and configurations are intact. Services that were running before the backup incident start correctly. If a service fails to start after restore, check its log with journalctl -u servicename -n 50 for the specific error.

For deduplication-based backups with configurable retention policies (keep daily backups for 7 days, weekly for 4 weeks, monthly for 6 months), BorgBackup is the correct tool. See BorgBackup Raspberry Pi Prune Policies: Complete Setup Guide. For protecting against SD card corruption on an always-on Pi, see Raspberry Pi Read-Only Root Filesystem Setup.

FAQ

What is the best way to back up a Raspberry Pi?

A two-layer approach: weekly rpi-clone to a USB drive for a full bootable system copy, plus daily rsync to a separate location for incremental file backup. If off-site backup is a priority, add rclone to sync the rsync destination to a cloud provider weekly. For long-running homelab Pis with significant data, BorgBackup adds deduplication and retention policy management on top of this. The specific combination depends on how much data is involved and how much downtime is acceptable.

Can I back up a Raspberry Pi while it is running?

Yes, with rpi-clone. It clones the live running system to a USB drive without requiring shutdown. Files written during the clone may not be captured if they change mid-copy, but for most Pi applications this is acceptable. rsync also runs on a live system and handles changed files gracefully. The only backup method that requires the Pi to be shut down is the dd raw image approach, which should be done with the SD card inserted in another machine.

How much space does a Raspberry Pi backup need?

A full rpi-clone or dd image is the same size as your SD card’s used space, compressed. A 32GB SD card with 8GB used produces roughly 8-10GB. rsync backups of the home directory are typically a few hundred megabytes to a few gigabytes depending on project files. For cloud backup, Backblaze B2 costs $6 per TB per month. A year of daily incremental backups for a typical Pi homelab is under $1 per year in storage costs.

How do I automate Raspberry Pi backups?

Use crontab -e to add cron entries for rsync and rclone at your chosen schedule. Always use full paths to binaries and redirect output to a log file. A practical schedule: rsync daily at 2am, rclone cloud sync weekly at 3am Sunday, rpi-clone weekly at 4am Saturday. Check the log files the following morning to confirm the first scheduled run completed without errors.

How do I restore a Raspberry Pi from backup?

For a full system restore from an rpi-clone backup: insert the USB clone, set the Pi to boot from USB via raspi-config or EEPROM boot order, then reboot. For a dd image: flash the .img file to a new SD card using Raspberry Pi Imager or dd from a Linux machine. For a file-level rsync restore: reverse the rsync command with source and destination swapped, omitting --delete for a partial restore. Test the restore before you need it. Do a trial boot from the clone at least once after the first backup.

References:

• rpi-clone GitHub: github.com/billw2/rpi-clone
• rsync documentation: rsync.samba.org/documentation
• rclone documentation: rclone.org/docs
• BorgBackup documentation: borgbackup.readthedocs.io
• Raspberry Pi Imager: raspberrypi.com/software

---

About the Author

Chuck Wilson has been programming and building with computers since the Tandy 1000 era. His professional background includes CAD drafting, manufacturing line programming, and custom computer design. He runs PidiyLab in retirement, documenting Raspberry Pi and homelab projects that he actually deploys and maintains on real hardware. Every article on this site reflects hands-on testing on specific hardware and OS versions, not theoretical walkthroughs.

Last tested hardware: Raspberry Pi 4 Model B (4GB). Last tested OS: Raspberry Pi OS Bookworm Lite 64-bit. rpi-clone 2.0.27, rsync 3.2.7, rclone 1.66, BorgBackup 1.2.8.