File-based backups, like borgbackup, aren’t complete bare-metal backup solutions since before restoring files, the operating system needs to be installed, disk layout re-made, any encryption/luks re-created, etc. Plus the UUIDs probably won’t match on the restored system, so there might be more manual work to fix that.
Relax-and-Recover solves this problem, by creating a bootable recovery image specific to a system so that it can recreate the layout, partitions, encryption, etc and then optionally also integrate with one of many backup solutions to completely restore a system. The hardware might be identical, or with some effort could be changed.
rear is included in the default repositories of RedHat (Fedora), openSUSE, etc. It is recommended and even has an entire chapter in their documentation.
Having said that, it seems to be “brittle” software that requires regular testing to be sure it actually works, and to make sure to know what to do manually in case it doesn’t. rear is written (apparently extremely well) entirely in bash which has the benefit of having essentially no dependencies. An admin can read and modify individual scripts as needed. The downside is if anything goes unexpectedly, which is to be expected in a disaster, having deeper knowledge of rear is probably required. It also depends on dozens of variables, and understanding what they are and their effects.
So, in the end, is it worth the effort, particularly for users of individual systems (as opposed to admins managing dozens or hundreds of systems)? Is anyone using rear?
I’m going to do something on that actually. I also plan to address the shortcomings of restic in comparison to rear as well, since rear seems like a cool concept but fuck if I don’t like the efficiency of restic.
I can’t speak on this directly since I’m only a backup admin (TSM / SP), but our Linux guys have used ReaR in conjunction with TSM to deploy images before, and they liked it. But it was more of a test experiment I think, and they moved to a more enterprise-level solution shortly afterward. But it worked well, integrated nicely with TSM, and considering it’s a free tool, you can’t beat the price.
i"ve been using rear for about a year for ISO backups. Never had any issues on it, and the config is pretty straight forward. It is built with rsync, which if you can’t trust I don’t know what you can trust.
Have you used rear with borg? My thought was to have a bootable external HDD to be used in a USB dock, and use rear mkbackup to generate the system recovery and backup simultaneously.
I read about rear from borg's documentation, but even the main borg developer hasn’t actually used rear. I don’t really feel like being the first to try the combination…
Crazy when this happens: I’m looking for solution X to a problem I have, and I can’t really find anything that tickles my fancy. Log into Level1Techs and, boom, exactly what I was looking for.
Great find. Great thread! I’ve been using rsync and cron to replicate data between several servers, but I don’t have any “actual” backup solutions. Will definitely give this a go.
Love the “4 minutes, no cheating” video in the top link. 10/10
I have not used borg. I looked at it a while ago, but stuck with rear. My use case is ISO backups over NFS on Debian. I just wanted easy set and forget, and the ISO restores work fine, so never looked further or more into it than that.
Note that rear is mostly focused on making a recovery image specific to a system. It can also make backups with tar or rsync, or integrate with a list of other backup software, but that’s not so much its focus.
It works pretty well for that. There is a feature when restoring the iso to adapt to new hardware (such a differently sized disk) so that would help. It will resize partitions.
Yeah, after checking it out, rear is a bit… Well it seems like a complete shitshow as far as stability and project direction, but the concept is good, so there’s that.
Yeah… It seems to me that when it works, it’s great. But it may very well not work right away, in which case an admin has a lot of flexibility to iteratively fix things because it’s made entirely of bash and config files. So some trial and error might get things working in the end.
The question is, do I want to invest the time to learn its quirks? And even if I do, will I remember when shit goes down? The developer, in a talk, emphasized the importance of testing…continually. Sounds like good practice, but who has time for that?
On the other hand, the cost to using rear is negligible. i.e. it costs nothing to have a recovery image ready, and if it doesn’t work, you’re no worse off than before. So, there’s no reason not to do dnf install rear and rear -v mkrescue even if nothing else.
