This is a very ambitious idea that sounds tempting at first glance (“One click, everything secure”), but involves massive technical pitfalls when you look at the details.
Short answer
BmuS is a file-based backup tool (rsync) . Backing up an entire running system actually requires an image-based tool (such as dd or partimage).
If you try to replicate this with rsync, you’re opening Pandora’s box.
The technical problems (why it’s difficult)
- The “open heart surgery” problem
You are backing up a system while it is running.
Inconsistency: While you are backing up /var/lib, an application is writing to a file. The backup is corrupt.
Stopping services: You would need to know which services are running. If you blindly stop them all, you might cut off your own SSH connection or the network stack that BmuS needs for the NAS mount.
- The infinite loop trap (excludes)
You can’t just do rsync -av / /mnt/backup.
You must exclude virtual file systems: /proc, /sys, /dev, /run, /tmp.
The killer: You must exclude /mnt and /media. If you don’t, BmuS will back up the NAS to the NAS to the NAS… until the disk bursts.
- The “restore nightmare” (the main argument against it)
Let’s assume the backup works. The SD card breaks. You buy a new one, installs a fresh Raspberry Pi OS, and restores your “full backup.”
UUID conflicts: /etc/fstab and /boot/cmdline.txt contain the UUIDs of the old partitions. The new SD card has different ones. The system no longer boots.
Kernel mix: The fresh OS has kernel 6.1, your backup has kernel 5.10 (or vice versa). You overwrite modules in /lib/modules. Kernel panic is inevitable.
User IDs: If the UIDs/GIDs don’t match, you’ll have a mess of permissions.
So: No. The sexiness of BmuS lies precisely in the fact that it is a system for backing up files—at intervals that you choose. If you want a complete backup, say once a month, and want to write it to an SD card, you need an SD image backup tool.