I have a dual boot machine containing fedora 35 and windows that failed. I installed fedora 37 on a new single boot machine and want to restore the root backup of my previous machine using an external hard drive where my restic repository is located.
I’m not sure how to proceed with correctly restoring a root backup to a new installation of fedora.
Should I have restored the root backup inside the live USB instead of trying to restore the root back to a new installation of fedora that has a new user?
If I have to restore root in a live CD does the target partition have to be empty?
Does restoring from fedora on a dual boot BIOS machine to a UEFI machine running fedora as its only operating system make any difference?
If you have any recommendations I’d really appreciate it.
Just a note my backup used an exclude file that replicates what one-file-system does
Restoring a full fedora 35 backup over a fedora 37 installation probably won’t work. If possible restore the full system to a temporary location and then move the still useful data over to the new installation.
You’ll end up with a mix of existing and restored files if the target partition is not empty.
It will likely make a difference regarding which bootloader to use and how to (re-)install it. Besides that there shouldn’t be much of a difference.
Why wouldn’t it work? I was under the impression that restic would replace any existing files and directories.
What type of data do you mean? The point of doing a full system backup is to be able to restore it to a new machine if the old machine breaks. I’d like to know how to do this?
Depending on what exactly you backed up, you might replace system libraries or programs with older versions. Which can’t deal with other stuff not yet replaced or not in the old backup.
Also state might be incompatible, let’s say a postgres DB was backed up under version X and the new system runs X+1, those database files are not compatible, you need to follow a certain upgrade path.
@NobbZ okay, so what’s the best way to restore a root backup?
I’m thinking of just mounting the root snapshot and copying individual directories, /home, maybe /usr/ etc. to the new machine. However I’m doing extra work that a restoration of the root snapshot would could do in one step.
I’ve used restic for individual directory and file backups but never for a full system backup until now. It shouldn’t be this hard.
You think I can just restore / as long as - - target is also fedora 35, what about all those posts that talk about grub2-install, grub2-mkconfig, dracut -f, and changing the UUID using fstab?
Restoring is usually massively easier when the running system and the backed up system are the same.
Indeed though, I would exclude /boot, I probably hadn’t backed up that at all.
Also I do not use grub, therefore I can’t say much about it.
/etc/fstab is also something you have to be careful with of course. As it has to mirror the state of the current system, not the back up. Thats why I use /dev/disk-by/label rather than /dev/disk-by/uuid, as I can control the label when setting up the disks.
Last but not least, I wouldn’t use restic for a full system backup, this decission is probably driven by the fact that NixOS works differently… Though even back when I used Arch Linux, full system backups always felt wrong to me.
Programs can be easily re-installed, but I need to backup their config (/etc) and state (/var/lib), and of course the users homes (/home).
I never have seen much sense in backing up anything else.
Thanks. I believe this is what I will do. It’s nice to know what /etc and /var/lib store. Apart from those three directories you mentioned, are there any other directories that should be backed up, what about /usr?
Also, why not backup the whole /var directory?
You’re right that programs can easily be installed. I’ll have to rethink whether a full system backup is necessary now that I know the best directories to backup in order to preserve only program state and configuration.
My /usr is empty. Not sure what lives there on regular linuxes.
Similarly I have my configs written in a way that there is only /var/log besides /var/lib holding any relevant data.
Everything else is ephemeral anyway.
If things are different on your system you need to figure out on your own. NixOS is different enough to not draw any conclusion from my system to yours.
I usually create a full system backup, but only restore what I need on the new system. Most data will be located in the already mentioned folder. But there will probably be some exceptions to those rules. In those cases its better to have a full system backup just in case.
@NobbZ@MichaelEischer I want to confirm how to restore specific paths from a full system backup. Do you restore specific paths using the --include option instead of the --path option? I believe --include restores a specific path where as --path restores a snapshot of a path if --path matches the path of a snapshot in the snapshot list. Am I right?
Also i know I can just mount the repository and use rsync to copy what I need on the new system. Are there any differences between restoring using restore with --include compared to restoring using mount and rsync?
Yes, --path is used when determining which snapshot is the latest. And --include the determines what is restored.
The main difference is performance, restore will likely be a lot faster (like 5-10 times), especially for small files. And, hardlinks are currently only restorable using restore.
I guess that was a bit too compact, it sort of says the same as your quote. The long form is the following. When specifying latest instead of a snapshot id , then you can use --path to filter for snapshots from that host. This implicitly also means that --path is not used at all unless you specify latest as snapshot id.
Good question. Hard links aren’t used too much. A few possible uses are (docker) containers / flatpacks / steam runtimes and maybe git repositories when cloning local repositories.
It tries to overwrite the existing files, although it won’t work in all cases (e.g. whole directory trees which are marked as read-only). restore also currently does not offer a method to delete existing files.
Do you mean that restic restore will not work if the destination directory is read only? For example:
restic restore 12244 - -target / - - include /var/lib
will fail to restore if /var/lib in the target (i.e. /) is read only?
Does this mean that if restic restore cannot overwrite existing files due to them being marked as readonly, then restic won’t delete that file since it does not possess that functionality?
In the above code if /var/lib exists in the target and does not have write permission then restic restore will not overwrite /var/lib with the one in the snapshot? If so, does restic warn you about that path not being restored?
If the directory /var/lib already exists at the target, then restic currently doesn’t reset its permissions during a restore. And consequently it won’t be able to create new files in that directory. If the target is empty, then it will create the directory with default permissions and only mark it as readonly once everything was restored.
Yes, you’ll get a warning for every file which couldn’t be restored properly.