raspiBackup keeps several versions of a running Raspberry Pi without shutting it down

Backups of a running system, not of a powered-off one

raspiBackup exists to create and keep multiple backup versions of your running Raspberries, and the first feature on the list is the one that defines it. Unattended full or incremental system backup with no shutdown of the system.

That constraint is what separates it from the usual advice for a single board computer, which is to shut down, take an image, and start again. A Raspberry Pi in a home lab, running a DNS server or a camera system, is often the one machine that is always on, and an unattended backup that never interrupts it is the entire point.

The tool is a shell script. The repository has raspiBackup.sh at the top level, an installation/ directory, a properties/ directory for the configuration, a config/ directory, an extensions/ directory, a helper/ directory, a test/ directory, a docker/ directory and a scripts/ directory. The primary language recorded for the project is Shell, and the licence is GPL-3.0.

It is not a general purpose backup tool. The Support section restricts it to RaspberryOS and Ubuntu, and to Raspberry hardware, and says that while it runs successfully on other Raspberry compatible hardware and other Linux distributions, any support request on those environments will be rejected. Support is also given only for raspiBackup specific issues, and the project points general Linux questions elsewhere.

Three backup types with different properties

The backup types are the core choice, and they are the standard Linux tools used directly.

rsync produces incremental backups. The readme explains the mechanism: dd and tar are full backups, and rsync uses hardlinks for incremental backups. A hardlinked incremental backup is fast and cheap on the wire, because unchanged files are links rather than copies, but it depends on the backup space being a filesystem that supports hardlinks, which rules out some network mounts.

tar produces an archive, and it can be compressed with bzip2, gzip, lzip, lzma, lzop, xz or zstd. That is a per file archive rather than a per block image, so it can be restored onto a different size of card, but it cannot be mounted as a filesystem.

dd produces a block level copy, and it is the one that has a specific property: dd backups can be restored with Windows tools. For a Pi that boots from an SD card, a dd image is the closest thing to a clone of the card, and being readable by standard tools on another operating system is a real advantage when the only machine you have available after a failure is a Windows laptop.

The choice is therefore about the recovery scenario rather than about speed. A dd image is a clone you can write to a card. A tar archive is a set of files you can restore. An rsync tree is the smallest thing to keep and the fastest to update.

Installation is one command and a menu

The installer is described as menu driven, using menus, checklists and radio lists similar to raspi-config, and it installs and configures raspiBackup with all the major options so that the first backup can be created in five minutes.

The installation itself starts with a single command.

curl -o install -L https://raw.githubusercontent.com/framps/raspiBackup/master/installation/install.sh; sudo bash ./install

The repository has an installation/ directory holding install.sh and raspiBackupInstallUI.sh, and the Makefile lists both of those alongside raspiBackup.sh and the properties file as the package files. It also lists the sample extensions archive and the config directory as a package file collection, and it names the files to sign, which is the signing step for a release.

Two things about this flow are worth calling out. The first is that it fetches a shell script over the network and runs it with sudo, which is the standard way to install software on a Pi and also the kind of step a careful operator reads before running rather than after.

The second is the split between the installer and the configuration file. The installer sets up the major options through menus, and the readme says much more can be configured in a configuration file. That is the right split for a tool that runs unattended for months, and it is also why the properties/ directory exists as a separate top level entry.

systemd timers, stopped services, and extension points

The scheduling mechanism is a systemd timer, and the readme is specific about the intent. No manual intervention is required, because backups are created via systemd timer over night.

A timer rather than a cron entry is a deliberate choice on a modern Raspberry OS, since it survives better across restarts and gives you the same status and journal output as the rest of the system.

The services detail is the part that shows real-world thinking. Important services can be stopped before starting the backup and will be restarted when the backup finished. On a Pi that is running a database or a file server, copying files out from under a live writer is exactly how you get a corrupt backup, so a short stop window is the difference between a backup you can rely on and one that restores with errors.

The extension mechanism is described as allowing any additional logic to be added at various steps in the backup and restore process via extension points. There are two directories for them, extensions/ for what ships with the project and extensions_userprovided/ for what you add, and the Makefile expects extension files named with a raspiBackup_ prefix.

The final promise in the feature list is the one that matters most in practice. Restored backup will boot immediately.

Smart recycle and manual snapshots

Keeping backups is easy. Keeping the right ones and deleting the rest is where most home backup setups go wrong, and raspiBackup has a strategy for it.

The number of backup versions to keep is configurable either for the sum of backups or on individual backup types, so you can keep many rsync copies and few dd images if that matches how you use it.

The smart recycle backup strategy is the interesting part. The readme describes it as saving backups of the last seven days, the last four weeks, the last twelve months and the last n years, and calls it the grandfather, father and son backup rotation principle. The algorithm was inspired by an article by Manuel Dewald on automating backups on a Raspberry Pi NAS.

The model is worth understanding because it is about the shape of your recovery options rather than about a count. A backup from three years ago and one from yesterday are both kept, and the middle of the distribution is thinned out. For a device that a household depends on, that means you keep a recent copy for a bad day and an old copy for a slow decay, without the storage cost of keeping everything.

On top of that, manual backups allow a kind of snapshot, called raspiBackup snapshots, of the system just before major updates are done. That is a separate mechanism from the rotation, so a snapshot you took on purpose is not a candidate for recycling.

Any Linux mountable device, and the clone trick

The backup space does not have to be a local disk. Any device mountable on Linux can be used, and the readme lists the kinds it has in mind: a local USB disk, a remote NFS drive, a remote Samba share, a remote SSH server using sshfs, a remote FTP server using curlftpfs, and a WebDAV drive using davfs.

The list is a good summary of what a small Linux system can be pointed at, and it explains why the storage decision matters more than the backup tool. A NAS over NFS is the classic case for a Pi, and the documentation has a page on using Synology as backup space over NFS.

The feature that changes the failure story is the clone device. If it is important to get the system up and running again immediately without any manual backup restore, raspiBackup can synchronize at the end of the backup run the just created backup with any device. The device then can be used immediately in the event of an unexpected system failure, to boot the system again.

So there are two recovery paths. A restore, which takes time and attention, and a clone, which is a card you write and plug in. The second is what turns a dead Pi into an afternoon rather than an evening, and it is the reason the tool supports synchronising to another device at the end of every run rather than only on demand.

The supported storage devices are listed too: SD card, eMMC, USB devices including hard drives, SSDs, flash drives and USB SD adapters, and NVMe.

Status messages, translations, and the GPL

The tool talks to you a lot, on purpose. More than 270 messages inform about backup progress, configuration mismatches, environment mismatches and runtime errors, and the documentation has a page mapping error messages to root causes and suggested actions.

That is a design decision for unattended software. A backup that fails silently at four in the morning is a backup you find out about when you need it, and 270 messages with a documented cause for each is the difference between a failed run and a mysterious one.

The messages are localised, and the readme lists English as the default along with German, Finnish, Chinese and French, crediting the translators by name and linking a page for adding more. There is a translated README for French as well.

The licence is GPL-3.0, and the Makefile carries the standard notice. The project also has a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a PULL_REQUEST_TEMPLATE.md, a.travis.yml, a publish.sh script and a published/ directory, and the documentation is published from the repository to a separate site with an English and a German version of every page.

The releases are regular on the 0.7 line, with v0.7.4 on 2026-08-03, v0.7.3.1 on 2026-08-01 and v0.7.3 on 2026-07-18, and the last push was on 2026-10-19. The project describes automated regression tests as the reason a new release will still backup and restore successfully, which is the claim that matters most for a tool whose output is a restore.

Editorial conclusion

Adopt raspiBackup when you run a Raspberry Pi in production and need several restorable versions of it without taking the machine offline, especially if you already keep the storage on an NFS or SMB share. Do not adopt it for a general purpose Linux server, because the project states that support requests on unsupported hardware and distributions are rejected. Verify first that your storage target is one of the mountable kinds it lists, that the backup space has room for the number of versions you intend to keep, and whether the clone device synchronisation is enabled, since a synchronised clone is what lets you boot after a total failure without a restore.

Frequently asked questions

Official sources

1. framps/raspiBackup on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases