Back Up & Restore Raspberry Pi Services and Data

This guide shows you how to back up the data and services running on your Raspberry Pi, and how to restore them when something goes wrong. You’ll learn both a full-system image backup (a complete snapshot of the SD card) and a targeted backup of specific files and service configurations. By the end, you’ll be able to recover your Pi after a corrupted SD card, a failed update, or an accidental deletion.

What You’ll Need

• A Raspberry Pi (any model) running Raspberry Pi OS or a similar Debian-based Linux distribution.
• An external storage device (USB drive, external SSD, or network share) with enough free space to hold the backup. For a full image, this is at least the size of your SD card’s used space, but ideally the full card capacity.
• For full-image backups: a computer with an SD card reader (or a USB adapter) and a tool like dd (Linux/macOS), Win32DiskImager (Windows), or the built-in SD Card Copier tool on Raspberry Pi OS.
• For file-level backups: a working network connection and a destination like an external drive, a NAS, or a cloud service.
• Basic familiarity with the Raspberry Pi terminal (command line).

Step-by-Step

Method 1: Full System Image Backup (Recommended for Safety)

1. Shut down the Pi cleanly: Run sudo shutdown now in the terminal and wait for the LED to stop blinking, then unplug the power. This ensures the file system is consistent.
2. Remove the SD card from the Pi and insert it into your computer’s SD card reader.
3. Identify the SD card device name:
   • On Linux/macOS: run lsblk or diskutil list (macOS) to find the device (e.g., /dev/sdb or /dev/disk2). Make sure you pick the correct one—it’s usually the one that matches your SD card size.
   • On Windows: open Disk Management and note the disk number (e.g., Disk 1).
4. Create a full image:
   • Linux/macOS: use sudo dd if=/dev/sdb of=~/pi-backup.img bs=4M status=progress (replace /dev/sdb with your device). This creates a raw image of the entire card.
   • Windows: use Win32DiskImager. Select the device (e.g., \\.\PhysicalDrive1), choose an output file, and click “Readâ€�.
   • Alternatively, on Raspberry Pi OS desktop, use the “SD Card Copierâ€� application to clone the card to another SD card or to an image file (if you have a second card reader).
5. Verify the image size: The image file will be as large as the full SD card capacity (e.g., 32 GB), even if only 5 GB is used. To save space, you can compress it: gzip pi-backup.img or use dd | gzip directly.
6. Store the image safely: Move the image file to an external drive or cloud storage. Keep it in a place you can access later.

Method 2: File-Level Backup of Services and Data

1. Identify what to back up: Common locations include:
   • Configuration files: /etc/ (e.g., /etc/nginx/, /etc/mosquitto/)
   • Home directories: /home/pi/ (Python scripts, Node.js apps, etc.)
   • Databases: MySQL/MariaDB dump (mysqldump), SQLite files (usually in /home/pi/ or /var/lib/)
   • Service unit files: /etc/systemd/system/ (custom services)
2. Stop running services (optional but recommended): For consistency, stop services that write data during backup. For example: sudo systemctl stop myapp
3. Back up configuration and data files: Use rsync or tar to copy files to an external drive or network share. Example using rsync:

   sudo rsync -av /etc/nginx /home/pi/myapp /media/backup/

   Or create a compressed archive:

   sudo tar -czf /media/backup/pi-backup-$(date +%Y%m%d).tar.gz /etc/nginx /home/pi/myapp

4. Back up databases:
   • MySQL/MariaDB: mysqldump -u root -p --all-databases > /media/backup/db.sql
   • SQLite: simply copy the .db file, but stop the service first to avoid corruption.
5. List installed packages (optional): Create a list of installed software so you can reinstall easily: dpkg --get-selections > /media/backup/packages.txt
6. Eject the backup drive safely: Run sync and then unmount the drive.

Restoring from a Full Image

1. Prepare a new SD card: It should be at least as large as the original. Insert it into your computer.
2. Write the image to the card:
   • Linux/macOS: sudo dd if=pi-backup.img of=/dev/sdb bs=4M status=progress (replace /dev/sdb with your new card).
   • Windows: use Win32DiskImager, select the image file and the device, then click “Writeâ€�.
3. Eject the card, insert it into the Pi, and boot. The Pi should start exactly as it was when the backup was taken.

Restoring Files and Configurations

1. Reinstall the OS if needed: If the Pi won’t boot, install a fresh copy of Raspberry Pi OS on a new SD card.
2. Copy back your files: Use rsync or tar to restore the backup. For example: sudo tar -xzf pi-backup.tar.gz -C / (be careful with paths).
3. Restore databases: For MySQL, run mysql -u root -p < db.sql. For SQLite, copy the .db file back to its original location.
4. Reinstall packages: If you saved a package list, you can reinstall with sudo apt update && sudo apt install $(cat packages.txt) (this may not be perfect if package names have changed).
5. Start services: Use sudo systemctl enable --now myapp to re-enable and start your services.

Common Mistakes

• Backing up the wrong device: Using dd on the wrong disk can overwrite your computer’s hard drive. Always double-check the device name with lsblk.
• Not shutting down the Pi before a full image: Taking a raw image while the Pi is running can produce a corrupted backup because files are being written.
• Ignoring database consistency: Copying a SQLite database file while the service is writing to it can corrupt the backup. Always stop the service first.
• Forgetting to include service files: If you only back up your home folder, you lose custom systemd service definitions in /etc/systemd/system/.
• Assuming the image is compressed: A full image is a raw copy of the SD card; it takes as much space as the card’s capacity. Plan storage accordingly.

Tips

• Automate backups: Use cron to run a nightly rsync of important files to a network drive. For example, add a cron job: 0 2 * * * rsync -av /home/pi /media/backup/.
• Use a dedicated backup drive: Keep a USB SSD or a NAS mounted at /media/backup and always back up to that location.
• Test your backups: Periodically restore a backup to a spare SD card to ensure it works. A backup you’ve never tested is not a backup.
• Keep multiple versions: Use timestamped filenames (e.g., pi-backup-2025-03-01.img) so you can roll back to an earlier state if needed.
• Use rsync with --delete carefully: If you mirror a directory, --delete will remove files on the destination that no longer exist on the source. Only use it if you want an exact mirror.

Troubleshooting

• The Pi won’t boot after restore: Ensure the SD card is properly seated and that the image was written to the correct device. If the image was taken from a larger card and written to a smaller one, it may fail. Use a card at least as large as the original.
• Backup file is too large: Compress the image with gzip or use a tool like PiShrink (a script that shrinks the image) to reduce size.
• rsync fails with permission errors: Use sudo when reading system files like /etc.
• MySQL restore fails with “access deniedâ€�: Ensure you’re using the correct root password and that the database user has privileges.
• Services don’t start after restore: Check the service status with systemctl status myservice and look at logs with journalctl -u myservice. Often the issue is a missing dependency or a changed file path.

Frequently Asked Questions

Can I back up a running Pi without shutting it down?

Yes, you can use rsync to copy files while the system is running, but for a full image backup, it’s safer to shut down. For file-level backups, stopping services that write data is enough.

How often should I back up my Pi?

It depends on how often your data changes. For a home server with daily logs, a daily file-level backup is reasonable. A full image backup can be done weekly or monthly, or before major updates.

Can I restore a full image to a different model of Raspberry Pi?

Usually yes, but some configurations (like device tree overlays) may need adjustment. It’s best to test the restored image on the target hardware.

What’s the difference between a full image and a file-level backup?

A full image is a bit-for-bit copy of the entire SD card, including the OS and all files. It’s the easiest to restore but takes more space. A file-level backup copies only selected files and folders, giving you more control but requiring a fresh OS install if the card fails.

Can I back up to a network drive?

Yes, mount a network share (e.g., NFS or Samba) and use rsync or tar to write to it. This is convenient for automated backups.

How do I restore a single file from a full image?

You can mount the image file on a Linux computer using losetup and mount, then copy the file out. Alternatively, extract it with 7z if the image is compressed.

Related

• Crimson Desert DLC Explained: Charting the Unknown
• Phone Battery Draining Fast After Changing a Setting
• Open Source vs Commercial AI Models: Which Is Better?