Restoring snapshots just got easier for me

[jfabernathy]

Because I can't remember how I last restored from a snapshot when I need to do it, I have to research this forum each time. So in search of a more automatic way of doing it. None of the *buntu's have picked a way, but recently I evaluated the newly release Linux Mint 21 which is built on Ubuntu 22.04 plus their stuff, minus snapd.

I tried installing LM21 on my old Macbook Pro first with ext4 and next with btrfs, which only require that I "do something else" in the disk partitioning to select btrfs for the formating of root partition.

LM21 has Timeshift integrated into their Linux very well. I used timeshift to make a snapshot, then install some new software, and next I restored to the snapshot prior to installing that software. The restore causes you to reboot. On both ext4 and btrfs it worked the same except it takes a lot longer on ext4 as expected. Lastly I deleted the /etc directory which made the mac unbootable. I then booted the LM21 install USB key and from there I ran Timeshift and it found my snapshots and allowed me to restore one of them. After a reboot it was back to normal for the mac. The btrfs was instantaneous on all operations as expected but both worked.

So that leads me to my question. Has anyone tried any of this on Kubuntu? It sure is a lot easier than booting the install key and using terminal to manually move subvolumes around.

[claydoh]

Timeshift has been around quite a while now, and works well on any *buntu-like system, at the very least. I have used it from live sticks, though installing it every time on a non-mint live OS is a pita, as can be expected
Recovery from the command line is quite easy as even the cli interface is fairly informative, and has good good help/manpage info.
I don't move or manage snapshots at all, just use it to make scheduled snapshots for emergency recovery and rollbacks. I don't use it for 'backup' purposes, though it can be used for that somewhat. I use normal 3-2-1 file-based strategies for that, for my idea of a well-rounded backup/recovery system.
Oddly, I have seldom have had to use this. Since finally going whole hog into this (fairly recently) I seem to have stopped actually needing to recover stuff much

[jfabernathy]

I did an experiment this afternoon after my OP and I created a VM of Kubuntu 22.04 just like I did on LM21 with a btrfs root. I installed timeshift and created some snapshots, installed some apps that put things in the invisible files in /home and when I setup timeshift I checked the box for included home. I mostly care about those invisible /home files because all my real data goes on a NAS. Anyway, I played the adding, restoring and all that worked on Kubuntu the same as LM21, so nothing special appears to have been done by the LM folks vs. Kubuntu repository version. I also did the test of booting from the Live USB for Kubuntu and had to install timeshift, but that worked and then I could run it and restore it just like I did on LM21.

So other than having to install timeshift while booted to the Kubuntu USB install key, it worked just like my LM21 test.

[jlittle]

I use normal 3-2-1 file-based strategies for that, for my idea of a well-rounded backup/recovery system.

IMO 3-2-1 is weak compared to a proper backup schedule of dailies kept for a week, weeklies kept for a month, monthlies kept for a long time, as was typical with tape backups where the media were relatively cheap.

Using btrfs incremental backups, one can efficiently have backups that preserve the hourly, daily, weekly, and monthly state of the data. (Hourly for a few days, daily for a few weeks, and so on.) I do 3-2-1 (actually more like 6-2-1) in physical media but each backup volume has incremental snapshots going back to their first use. With my data usage, when they're full, it's feasible to replace them in the cycle with fresh hard drives, though I've only kept one such full really old volume, because I've only used this regime for a few years. Being able to see files as they were in some arbitrary week over a year ago has been surprisingly useful. It doesn't happen often, but when it has, it's been very good.

[jfabernathy]

A lot has changed since the couriers use to move the backup tapes from one storage facility to another to keep the 3-2-1 working. For me I have everything I need on a mirrored systems that the home uses as a NAS. That NAS is sync'ed every night to a Cloud system that I can browse by file anytime I loose any file. But unless I do something stupid, which has happened, the cloud copy is rarely used. But for that one time it's needed, it's good to have it for $100/ year.

My concern for BTRFS and snapshots is more academic than anything. Since all my important data is always on the NAS and it's backed to the cloud, Nothing but time is lost recreating the systems that get hosed, usually by me and not hardware failures. I recently blew away one of my systems and rebuilt it because it was >100 degrees outside and it was too early to start drinking. It only took me an hour to rebuild it under an completely new OS. Next week I'll probably do the same with another OS. Or is this the week I work with Raspberry Pi's

[jlittle]

Because I can't remember how I last restored from a snapshot when I need to do it, I have to research this forum each time.

I suggest keeping a manual log of stuff like this. The good people on this forum recommended this to me for years, and since I did it has proved it's worth. Also, one can get your shell to log every command you type; I often grep these logs for some dimly remembered command.

It sure is a lot easier than booting the install key and using terminal to manually move subvolumes around.

(On my desktop I keep at least two bootable subvolumes on the go, in the same btrfs, so no need for the install key.)

"Restoring" the whole install to some previous state seems to me like a very blunt tool. I haven't used Timeshift, but I suspect that it appeals to those from a Windows background, being like the Windows "System Restore". If you value your data, being familiar with your snapshots and mucking around with them is a good idea.

With btrfs the snapshots are branches in a tree, and one can jump between the branches, and access other branches from the one you've booted from. This is particularly useful for comparing various versions of files.

[claydoh]

IMO 3-2-1 is weak compared to a proper backup schedule of dailies kept for a week, weeklies kept for a month, monthlies kept for a long time, as was typical with tape backups where the media were relatively cheap.

Using btrfs incremental backups, one can efficiently have backups that preserve the hourly, daily, weekly, and monthly state of the data. (Hourly for a few days, daily for a few weeks, and so on.) I do 3-2-1 (actually more like 6-2-1) in physical media but each backup volume has incremental snapshots going back to their first use. With my data usage, when they're full, it's feasible to replace them in the cycle with fresh hard drives, though I've only kept one such full really old volume, because I've only used this regime for a few years. Being able to see files as they were in some arbitrary week over a year ago has been surprisingly useful. It doesn't happen often, but when it has, it's been very good.

Maybe 3-2-1 is not the correct nomenclature. I am sure I am getting it wrong.
,
I do have a combination of incremental backups and incremental snapshots. I just don't store snapshots outside of the drive they are on. I only have a fairly tame desktop PC, with nothing important in terms of the OS. And even my personal files mostly don't need anything so involved as to need more than daily/weekly and semi-monthly backups. I do have a small number of directories that I sync to my backup drive every few hours, in addition to being part of my normal incremental $HOME backups. I also sync those synced files to the cloud daily, as well as my $HOME backups. Minus the Steam directories, though

Probably a little overkill for my simpler use case, I imagine.

[jfabernathy]

With btrfs the snapshots are branches in a tree, and one can jump between the branches, and access other branches from the one you've booted from. This is particularly useful for comparing various versions of files.

Just remember the monkey principle. "Don't let go of one branch until you have a grip on the new one"

[GreyGeek]

I tested Timeshift extensively. One thing I learned was that BEFORE you delete Timeshift from your system be sure to FIRST delete ALL the snapshots it has stored. When I was testing it the snapshots were stored in /var/run and appeared to be a link to the actual subvolumes in rootfs. I had deleted Timeshift and then used "btrfs subvol delete -C /var/run/..." to delete the snapshots. When I deleted the snapshot of @ my system went down. Everything was gone. I had made snapshots to an external SSD so nothing was lost but that put me off of Timeshift. The other problem I had was that it had a feature that connected snapshots to grub, so that when you marked a snapshot to rollback as the next @ it was attached to grub and booted automatically when you rebooted. Unlike the manual procedure where you mv @ TO @OLD, "btrfs su snapshot /mnt/snapshot/@yyyymmddhhmm /mnt/@" and rebooted. With those caveats in mind Timeshift is a good tool.
Snapper is a good tool also, It works differently. You can pull individual folders or files out of a snapshot and restore it to your working snapshot. It also allows you to compare snapshots. It numbers snapshots and allows you to delete one or more snapshots that are between n and m. And, you can do the regular rollback of an entire @ or @home and reboot.

I agree with jlittle when he wrote "Using btrfs incremental backups, one can efficiently have backups that preserve the hourly, daily, weekly, and monthly state of the data. (Hourly for a few days, daily for a few weeks, and so on.) " My exception is concerning the number of snapshots of each subvolume. I communicated directly with the btrfs developers concerning how many snapshots a btrfs system can hold. I had read stories of folks making snapshots every 5,10, 15, 30 or 60 minutes, and one person was wondering about snapshots taken every minute. The dev said that he would not recommend taking more than 8 to a dozen snapshots per subvolume. The reasoning is easy to see. The longer a snapshot exists on the system the more it fills up until it is about the size of the system. So, if your @ is, say, 90GB, and you take the following snapshots (8X7 hourly, 7 daily, 7 weekly, and 7 monthly) you have 77 snapshots of and on one subvolume. If you are saving those snapshots under, say, /mnt/snapshots ( where the rootfs is mounted to /mnt) on a 1TB drive, when 9 of those snapshots eventually fill up your system will run out of disk space and halt, if it hasn't slowed down to molasses speed by then.

There is another problem that is encountered when rolling back to previous snapshots. Loss of data created or stored between the snapshot one is rolling back to and the present. That's why I use IMAP instead of POP3 for my email service. And, I regularly move the emails from the active directory folders into the archive or "local" folders. If you download your emails to your local drive and delete them off of your ISP's drive, which is what usually happens with POP3, and then you have some problem that requires you to roll back to a previous snapshot, all email downloaded after that snapshot is lost.

Similar to jlittle I back up in the evening each day, usually before I retire for the night, and keep the last 5 days. I create a new snapshot and then delete the oldest one on the stack. IF, during the middle of the day, a large number of updates are posted, or I am doing some experimenting, I create a snapshot with an identifying tag added to the yymmddhhmm label, and use it to roll back to if things go south.

IMO and experience, doing manual snapshotting and maintenance of btrfs is so simple I no longer use GUI apps. Besides, I've never found a GUI app for BTRFS that allow one to do a balance, or a scrub, etc.

[jfabernathy]

...Besides, I've never found a GUI app for BTRFS that allow one to do a balance, or a scrub, etc.

I've been playing with a new project working to solve the GUI BTRFS issue. Btrfs Assistant, https://gitlab.com/btrfs-assistant/btrfs-assistant. It seems to have some nice features for subvolumes in general, scrubbing, balancing but is helpful for snapper and timeshift.

Timeshift creates their snapshots at top level 5 one for root and one for home. Maybe there are other recent changes to Timeshift. I know there is talk about grub-btrfs not being compatible now with how Timeshift does some of it's mount containing PID in the name which breaks things. But I'm not using that. Too easy on a non booting system to boot the USB install key and run Timeshift from there to restore. I use timeshift for my play systems where I'm experimenting with new software or ideas. Those get rebuilt a lot but when your are working a project it's nice to restore to the work you were doing easily after a failed experiment.

On my critical server I always have an offline clonezilla image updated one or twice a year. That server rarely gets any system or program updates that are critical. The data portion is on a mirror and constantly updated to a cloud service. The btrfs snapshots scripts run every morning early and use incremental send/receive to another drive in the same box and could be used to restore from. I can recover from a failed boot drive with the conezilla image and then use the daily incremental backup to restore to current with a couple of commands.

[claydoh]

With btrfs the snapshots are branches in a tree, and one can jump between the branches, and access other branches from the one you've booted from. This is particularly useful for comparing various versions of files.

Timeshift (which is not specifically a btrfs utility) can do this. it is actually the feature I have used the most using this application so far. It supports both Rsync backups as well as btrfs snapshots, but as far as I can tell not both at the same time. Which is sort of a bummer.
I am hoping that now development of this program is being done by Linux Mint's dev team, that they can implement the highly-requested feature of remote storage of snapshots.

I have been using Kup/bup for both incremental backups and directory syncing to my backup drive, plus rclone to rsync these to The Cloud, I have only been running on btrfs for approx 6 months or so, when I had to replace my drive.
I imagine if I ever get a NAS or something, I would set this sort of thing up from scratch, manually now that I have been getting my toes wet.

[claydoh]

It would be interesting and informative to see the hows and whats of everyone's specific backup/snapshot setups and strategies (and how-tos, links, etc)
there are tons of pages on variouis backup methods, but most are copycats, and not very deep. Real-world settings, scripts, and ideas are hard to come by, for us mere mortals

This is probably why Mint has included and support such a tool

[jfabernathy]

It would be interesting and informative to see the hows and whats of everyone's specific backup/snapshot setups and strategies (and how-tos, links, etc)
there are tons of pages on variouis backup methods, but most are copycats, and not very deep. Real-world settings, scripts, and ideas are hard to come by, for us mere mortals

This is probably why Mint has included and support such a tool

I came to this sub-forum category to learn about BTRFS and the hows and whys of backing up and learned a lot. I've been using a method I documented here: https://www.kubuntuforums.net/forum/...ential-backups

This is very simple but uses the concepts of btrfs snapshots and the btrfs send/receive to put incremental backups on an external drive. It could be a USB always plugged in drive or in my case another hard drive in the box, as long as it's btrfs formatted drive.

[GreyGeek]

I've been playing with a new project working to solve the GUI BTRFS issue. Btrfs Assistant, https://gitlab.com/btrfs-assistant/btrfs-assistant. It seems to have some nice features for subvolumes in general, scrubbing, balancing but is helpful for snapper and timeshift....

I was looking for a btrfs GUI maintenance tool and tried out the one you suggested. It works OK with one exception: I have to mount the directory that I want to store the snapshot on before I can create it. In my case I mount /mnt/ as the rootfs and store my snapshots to /mnt/snapshots.
I guess I could write a bash script wrapper for the gui and prompt for my root password and mount /mnt before the assistant starts up, but ...
So close, and yet so far.

EDIT: BTW, I know "Dummy" and have often been called one, but you are no dummy!