What is the most important is to back up your user data so encrypted passwords (password manager), email, photo’s, document, spreadsheets etc. etc. I made sure all that data is under /home/marel so I am backing up that.
As I like to know wat is done I use rsync to back up the data to an external SSD. After the backup is done I can just browse the backup data and that is what I like.
I do a backup about once a week and every month I swap the SSD with a similar one I have at my office. Both SSD’s are encrypted. Doing so I can also just restore one file or a directory including that of ~ 1 month ago.
Recently did a reinstall and that worked out pretty good. Additional things needed were enabling some additional zypper Repo’s and some tweaks I did (locale, secure DNS, special installs etc). For those tweaks I have a document where I did write things down, commands executed with minimal text and some links.
One advice: Whatever you chose, test you solution. Just create for example a Leap install or a secondary Tumbleweed install and try to restore the data.
jon@localhost:~> sudo btrfs send /.snapshots/1/snapshot/ | btrfs receive /mnt/backup/test
Absolute path to ‘btrfs’ is ‘/usr/sbin/btrfs’, so running it may require superuser privileges (eg. root).
[sudo] password for root:
ERROR: subvolume /.snapshots/1/snapshot is not read-only
jon@localhost:~>
Looking in YaST, the snapshots go up to 638. Either I’m doing the commands wrong, or because I upgraded from Leap to Tumbleweed, something else is the cause.
Another quick question is, if this did work, would cause it problems later restoring it to a new drive as the UUID would be different?
How did you move the passwords into /home ? I thought they were stored in /etc?
I did a test run of rsync and it seemed to go quite well. How did you do the reinstall? Was it just using the installation media to recreate the system and then use the rescue system to overlay the backup on top of it?
Please, when using a Unix/Linux system it is of utmost importance that you understand that it is a multi-user, multi-session operating system. That means that each user has her/his own environment separated and protected from the same of other users and certainly from the system. When you understand this you also will understand that the passwords of user mrjawn, when stored using a password manager (like Kwallet) are stored within the storage area dedicated to user mrjawn and thus in her/his home directory (in our example /home/mrjawn and never in a system directory like /etc.
Thus @marel does not mean the the passwords are moved inside /home. The personal passwords of all users are in /home already. And thus by making backups of all in /home they will be backed up. When, on the contrary, only files like documents, pictures, videos, etc., in short all files the user himherelf considers as usefull are saved, these password files and a lot of other personal configuration files, can easily be forgotten.
So backup ALL in /home, and do not skip files where the file name starts with a . (a dot, they are often called “hidden files”, though that is an misnomer used by those who used MS-DOS and friends).
I backup all in /home (for obvious reasons), /etc (then I have a reference to system configuration files when restoring the system), /boot (for the grub, etc. config files) and a few others because I run a LAMP server.
The system itself is not saved, because a fresh install (maybe needed on new hardware when the system burned out) might be faster.
And mentioning the burned out hardware. Making a backup strategy starts with asking yourself against what disaster you want to arm yourself. That can range from:
restoring a user file (e.g. a letter to your mom) that was utterly malformed after a stupid action in LO;
a user deleted by incident part or whole of his home directory;
disk broken;
burned out system;
burned out house (including the backup media).
That is just the starting point of making a backup/restore policy.
It depends on expectations. It is most certainly expected if you understand how btrfs send/receive works and layout of btrfs subvolumes used by openSUSE.
There was one single step - attempt to btrfs send current writable system root.
Good question, a backup is nothing worth without knowing how to restore it and preferably testing that.
The setup I am using is to have /home being a separate mount/partition. I am the only user so that is equivalent to /home/marel.
With a re-install I have that /home partition already restored and in the partitioner I mount it as /home and run the install. When the computer is restarted after the install you will see that the desktop icons from you backup are already there, Firefox does remember it’s settings and if you for example use Thunderbird for your email, you will see that after installing Thunderbird all email is back as it was.
That is also an easy way to get from a “corrupted install” that is working sub-optimal to a new fresh install, in that case you do not have to restore the backup but just mount the /home from the “corrupted install”. This is something I learned by doing it.
It is slow but I like to connect an external drive to my computer and use the dd command.
It’s a very dangerous command if used incorrectly which is why i’m hesitant to post an example but it does the job.
DO NOT COPY PASTE! I use something like this
dd if=/dev/nvem0n1p8 of=/dev/media/backup.img
if equals the source and of equals the output.
You can easily erase all your data with the dd command so -be cautious.
Thanks for all the replies. Seems this was the best time to find out ways to do this, while trying different things I found that the filesystem did have problems. I couldn’t delete older snapshots from before the upgrade to Tumbleweed and there were a few other inconsistencies.
I managed to rsync as much as possible and export a list of installed programs and repos. I then did a fresh install of Tumbleweed preserving the users, copied the old home data back across, reimported the repos and program list, let it do it’s thing, rebooted and it all looks to be back to how it was.
Next is working out to script all this to do it automagically on a schedule, so I’ll probably have a new thread at some point asking basic things about doing that. Also, Paragon now sees the btrfs partition properly again so there’s always that option.
Because there are a number of options (not just for backup, but other operations), it can be intimidating … so best to sit back and ask for options.
And yes, you could create a “cron job” to run rsync (or something else) every now and then. Nice thing about rsync is it only copies changed data on each run, which makes it a quick process.
Personally, I don’t use rsync with cron … I do a quick manual rsync of /home every few days. (my /home is in its own separate partition).
If there’s a catastrophic failure of / (root partition) and BTRFS isn’t helpful, a fresh install is easy enough.
