I’m running Fedora 43 (KDE) and I want to use Restic to back up my workstation’s two drives. The drive that contains my /home folder (a 4TB SATA SSD) will be a simple file-backup to an external drive (and to Backblaze B2), and I’m pretty sure I understand how to set that one up.
The main boot drive, though (a 2TB NVMe SSD) – that, I’m not quite certain how to do yet.
I have Snapper installed on my machine, and it makes regular snapshots of that boot-drive (yes, it’s BTRFS – both my drives are, actually) so I can reboot and select an old snapshot if an update borks my system. Can Restic simply back up one of those snapshots as an image? Or does Restic need to do its own snapshots?
My goal is to have a bare-metal recovery USB stick – with Fedora 43 and Restic installed on it – that will allow me to boot to that stick, run Restic to restore onto a new SSD, and have my machine back up and running in ~1 hour, should should my boot SSD fail.
Oh, and in that vein – how do I install Restic’s restore utilities onto a bootable Fedora 43 USB stick? dnf isn’t gonna work, because when you boot to a live USB stick, it’s a read-only filesystem. So how do I get Restic to write itself to that stick in the appropriate place?
Sorry for the potentially noob questions – I did search and couldn’t really find what I was looking for, at least not a recent post, anyway. Closest thing I found was way back in 2019, and there’s no way that’s still relevant 7 years later. LOL. And he didn’t really give step-by-step instructions – just said that he was able to do a bare-metal recovery and gave general steps, but I need something more specific, since I’m not really familiar with Restic.
Any help you can give will be appreciated. Thanks!
A simple and fast way to backup and restore linux file systems is to use fsarchiver (https://www.fsarchiver.org/) available in most distros and as part of the system rescue bootable iso package ( SystemRescue - System Rescue Homepage ). No need to exclude virtual filesystems such as /proc. Restore can be to smaller or larger partitions, BTRFS is supported, along with most other linux filesystems. Compression and encryption are options.
BTW, I’m a strong supporter and long-time user of restic, brilliant software, but I like to use the best tool for the job at hand.
The answer is a bit of both. You can read the output from btrfs send into restic using --stdin-from-command, which stores the btrfs snapshot as a single file in a restic snapshot:
The backup workflow looks a bit like this:
Create btrfs snapshot (you can skip this as snapper does it for you): sudo btrfs subvol snapshot -r /mnt/btrfs/my_subvol/ /mnt/btrfs_snaps/1
Note that the file that is the btrfs snapshot is just called “/stdin” by default. You could rename it if you wanted using the --stdin-filename flag when creating the restic snapshot, but you’ll need to take care to use the same filename when restoring.
Also note I used the special snapshot ID “latest” when restoring in the example above, you could select a specific snapshot to restore from as needed.
One downside to this approach is restic has to scan the entire snapshot each time, as it is a single large file. This could take a long time if the snapshot is large, and the system making the backup is not that powerful; anecdotally I saw about 15s backup time for 0.5Gb of snapshot data when doing some quick testing, and this doesn’t decrease for subsequent snapshots.
restic does deduplicate the btrfs snapshots very well though.
Note that by itself this isn’t a complete bare-metal recovery solution. E.g. you would need to re-install Fedora before restoring the snapshot to have something to restore the snapshot to.
“If you want to backup partition which are in use, the best thing to do is to make an LVM snapshot of the partition using lvcreate -s, which is part of the LVM userland tools.”
Is that the same as a Snapper snapshot? It doesn’t really say…
Should there be a space between the -- and the btrfs in that command there? And I’m guessing that /mnt/btrfs_snaps/1 should be replaced with the path to my most recent snapshot?
Ohh – I get it now. The btrfs send /mnt/btrfs_snaps/1 part is telling btrfs to send that snapshot to stdin, and the sudo restic -r /srv/restic-repo backup --stdin-from-command part is telling restic to backup stdin to the repo located at /srv/restic-repo. I assume I create the repo in the normal fashion, like any other repo, yes? And restic certainly doesn’t have a problem having two repos on the same NAS drive, right? As long as they’re in separate folders? Like /mnt/mynas/restic_home_repo and /mnt/mynas/restic_root_repo for example?
So, I just realized something… Backing up this way is only good for a full restore, yes? I can’t restore just a single file out of that snapshot, can I? It’s all or nothing, isn’t it?
Yes, as I understand it, the btrfs snapshot data you back up to restic isn’t readable/accessible by itself.
You have to btrfs receieve this snapshot data to a btrfs filesystem, which must be mounted in order to give you access to the files in that snapshot.
This is maybe a bit of a technical aside, but the data that btrfs send emits to stdout (and we store in the restic repository as a single file) is in btrfs stream format:
As far as I’m aware, you can’t do really anything with that data apart from read it using btrfs receive, which requires a btrfs filesystem as the receiving target. Also, as it is stored as a single file, there isn’t really a way to “get it out” from the restic snapshot without restoring the entire file anyway.
If restoring individual files is a priority for you, why not also back up your files directly? Keep the btrfs snapshot backups for restoring after a full system or hard drive loss, and use the regular file backups for if you want to restore an older copy of a document or something similar.
My goal was to replicate the backup system I had under Windows 10 using Macrium Reflect 8. It did image backups – but also somehow managed to be single-file-restorable because you could mount an image as if it were a real drive and just copy files out as needed. Plus it had a bootable USB creator program – you could boot to that drive and write an image from your backup media directly to a new hard-drive. You didn’t have to install anything. Just “write this image to this drive” and go eat lunch. When you came back, the entire drive had been byte-for-byte restored, as if nothing ever happened. It would even let you shrink or grow partitions to match the size of the new drive if it wasn’t the exact same size as the old one.
But what you didn’t have to do is have two backups – one “image” based and one “file” based. It was one backup that did both things. And it could do full, differential, and incremental backups. It just managed everything all automatically – best backup software I’ve ever used in my life, ever. And it’s the thing I regret most switching from Windows to Linux. I just haven’t found a replacement for it, and it doesn’t seem as if there is one.
I understand the frustration, switching from Windows to Linux involves a lot of forced change, and is something I went through myself a few years ago.
I think unfortunately you have hit the nail on the head there.
I’m happy to help workshop potential solutions to your problems, but getting a complete 1:1 replacement for macrium reflect doesn’t sound like it will be possible using a single program, given the features you’re looking for anyway.
You may already be well aware of this, but just to make sure we’re both on the same page (and for the benefit of anyone else following along), a btrfs snapshot of “/” alone is not a complete bare-metal recovery solution, assuming you’re using the default fedora subvolume layout.
By default, fedora sets up multiple btrfs subvolumes, and snapshots are subvolume specific. For example, my machine has /home, /, and /var all as separate subvolumes.
Taking a snapshot of the “/” subvolume does not snapshot any subvolumes mounted under /, eg: /home, /var, etc.
This is why when you select an older snapshot to boot into, your data under /home remains unchanged.
tldr; btrfs snapshots don’t cross subvolume (or partition) boundaries, you can’t perform a recursive snapshot of all subvolumes in a btrfs filesystem.
Anyway, if your requirement is specifically “I need a full image of my system disk that I can load onto a replacement disk in the event of a full disk loss”, something like fsarchiver as rustycanb mentioned before sounds like the correct tool for the job. Clonezilla is another tool I’ve seen mentioned often in relation to linux bare metal restores.
However neither clonezilla nor fsarchiver seem to allow browsing the files inside the disk image.
As an aside, this wikipedia comparison page might be a good starting point for further research into disk cloning software, maybe there is something in there that more closely matches your needs.
On the other hand, if a btrfs snapshot does meet your requirements, then using a second btrfs filesystem as the backup target instead of restic would allow you to access the files inside the snapshot on-demand, without needing to do a full restore (assuming you can mount the second filesystem in the location you want to access the files from).
Btrbk is a tool designed primarily around this workflow: btrbk - README
Restic could work well alongside btrbk here as “longer term offline storage”, for egressing btrfs snapshots into S3-compatible storage or similar using the workflow we discussed before.
Right – I have several subvolumes as well. /cache, /log, /spool, /tmp, /.snapshots – they’re all on their own subvolumes. (And /home is on a completely separate drive, but I mentioned that in my original post). But those subvolumes on the boot drive, I just have to recreate them, then restore the backup to root. The subvolumes are all things that you don’t want included in a backup anyway. As long as they exist when the system boots, it doesn’t matter that they’re empty. Allegedly…
Yes, it’s another step to recovery, but at this point I guess it can’t be helped.
Or – I could back up an image of the entire boot drive using, say, Clonezilla, but that requires booting from a USB stick in order to make the backup, so it can’t happen automatically on a nightly basis. And it involves a second backup method, which I’d hoped to avoid.
Do the SELinux permissions and user ownerships and other file permissions all get copied by Restic when it does a file backup? Since I’m going to have to re-create all the non-backed-up subvolumes anyway, maybe a file-backup of the / folder isn’t such a bad thing after all – assuming I can just tell Restic to restore onto the / of a new drive and it’ll put everything in there with the proper permissions and such…
I’d still pay real money for Macrium Reflect, Linux version.
I haven’t been following this discussion, but can the thread author please mark one of the replies as the solution (the little checkmark icon), if you feel the questions have been answered?
Although there were many very helpful answers, I don’t feel like there’s any single answer that I can point to and call it the solution to my original post, unfortunately.
I also asked more questions as the topic went on, and we kind of came to the consensus that the solution I was looking for simply isn’t available on Linux, whether using Restic or not.
Since you summed it up so nicely, I marked your latest post as the answer 