Complete desktop system backup - how and what?

Based in the previous answers and my own knowledge on the subject, it's clear that there's no right answer in a way too strict sense.

I'm facing financial troubles and so far still unemployed. Still, even in a context five times better, I doubt I'd rely on too many more than snapshots and periodical dumps.

There are other, and better, ways. I just don't feel like doing it for a good while.

Maybe what I'm trying to say is: that's for you to decide yourself what to backup and how.
 
pkg prime-list and pkg prime-origins are convenient aliases.

Code:
prime-list           'query -e '%a = 0' '%n''
prime-origins        'query -e '%a = 0' '%o''
In case people wonder where these alias come from, they are in the file /usr/local/etc/pkg.conf.
It took me quite some time to find a valid response because I was certain to find it through the man pages. But nope there is nothing about it, I know it because I spent countless time searching the terms via unsuccessful command, haha.
The answer was just in the handbook, obviously:
 
I've preferred to keep my user data (home directory and shared space) on different devices from the OS, makes it easy to mirror user data or to upgrade OS by installing a new device and fresh install to it. I'll do this and leave the old OS devices in but unpowered/unplugged so if the upgrade doesn't work trivial to go back.

Definitely recommend putting /usr/home (or /home) on a separate dataset (or a separate partition if you use UFS). On some systems I even create a separate home directory dataset for each user account. Makes it a lot easier to backup the home directories.
How does one go about doing this - is it usually better to put the home directory (and such) on a different drive or a dataset? Is there something in the manual/other materials that describes this kind of a setup?
Backup like that:

Code:
# beadm list
BE Active Mountpoint Space Created
13.1 NR / 33.4G 2023-01-10 16:55
13.1.safe - - 2.1G 2023-01-20 17:09

# beadm export 13.1 | xz -9 > 13.1.BE.xz
I tried this and the resultant file was too small - when trying to import the backup on another system it complained about not being able to import it - guess I may have done something wrong. Or does this not copy the underlying filesystem contents and only the boot environment?
 
I tried this and the resultant file was too small - when trying to import the backup on another system it complained about not being able to import it - guess I may have done something wrong. Or does this not copy the underlying filesystem contents and only the boot environment?
It backups only the FreeBSD system Boot Environment. It does NOT backup your data.
 
As SirDice posted, it is most practical to only backup user home directories and system config files. My routine for the latter is that after changing them, I make a copy to a directory in my /home, so that I only need to backup my user files.
agree, and using rsync too can just add / copy over the changed files to an existing backup
 
It backups only the FreeBSD system Boot Environment. It does NOT backup your data.
I'm trying to understand the advantage of backing up the Boot Environment 🤔

Don't most boot managers like beadm already save the Boot Environment prior to update? How does backing this up separately help?
 
I'm trying to understand the advantage of backing up the Boot Environment 🤔

Don't most boot managers like beadm already save the Boot Environment prior to update? How does backing this up separately help?
A backed up BE isn't the same as a BE. The first one it is a exported and compressed BE (which is your whole system besides /home). The second one is a created or imported (from a backup) BE.
 
It backups only the FreeBSD system Boot Environment. It does NOT backup your data.

A backed up BE isn't the same as a BE. The first one it is a exported and compressed BE (which is your whole system besides /home). The second one is a created or imported (from a backup) BE.
Makes it more clear when I read both of these together - so basically a backed up BE is **everything** except /home contents? If I understood that correctly

Someone was suggesting to keep /home data on another dataset/partition/drive - so that it's easier to shift data - backing up BE and having home directory in a different place plays well together for this reason?
 
Someone was suggesting to keep /home data on another dataset/partition/drive - so that it's easier to shift data - backing up BE and having home directory in a different place plays well together for this reason?
Exactly.
Look at this example:
1680554354856.png


zroot-13.1-release-p7.xz is a backed up BE from my previous setup. Beneath, on doas beadm list output, there is 3 BE's, the first one was automagically created when I update the base system, the second one it is the default one (duh..) and the last one it is the BE from my previous setup that I imported to get some configs files.

A bit more detailed output:
1680554892620.png
 
Exactly.
Look at this example:
View attachment 15995

zroot-13.1-release-p7.xz is a backed up BE from my previous setup. Beneath, on doas beadm list output, there is 3 BE's, the first one was automagically created when I update the base system, the second one it is the default one (duh..) and the last one it is the BE from my previous setup that I imported to get some configs files.

A bit more detailed output:
View attachment 15996

on linux I have seperate root and home partitions makes it easer to reinstall system without having to worry about data loss in home . just adduser same name same UID GID then done
 
Interesting. I have a couple of questions if anyone can answer.

1. Does Bectl work the same as beadm in this regard (i.e is that what import/export commands are for)? Any limitations compared?
2. Bhyve zvol VMs. Is there a best practice? If they are on a separate dataset, they won't be included in BE backups, right? So treat like Home? zfs-send or other method? Otherwise they will be exported fine with BE?
3. Is there anything that you have to look out for when restoring? Like if the disk has changed; and is that a matter of just fixing fstab? Or is there something else that would need fixing? (Among other reasons, I've had a weird thing with my motherboard. After a firmware update, it swapped the order of the two M.2's, where nvd0 became nvd1 and vv)
 
Back
Top