Today I was doing my usual snapshots to store @ and @home on an external disk, using the incremental snapshot method. The first part--updating the @ subvolume--went fine, but when I tried to do the same with the @home subvolume, I kept getting an error message: ERROR: cannot find parent subvolume. I tried retracing my steps, thinking maybe btrfs wasn't looking hard enough, but the same message keeps popping up. Why can't it find my parent subvolume? What is my parent subvolume? Where might it be? Given the size of my @home subvolume, I'd hate to have to give up on incremental backups. Any help out there?
-
-
Windows no longer obstructs my view.
Using Kubuntu Linux since March 23, 2007.
"It is a capital mistake to theorize before one has data." - Sherlock Holmes -
To do incremental btrfs backups, the previous snapshots must still be there on both the send and receive side. So say there's a snapshot of @home called @home-2021-11-20, that was sent on the 20th; incremental send receive sends the changes since the 20th to the receive side, and there those changes are applied to the @home-2021-11-20 it finds there to make a new snapshot. This is done at a low level, below the file system hierarchy as seen by a user; so if there's any changes made to the previous snapshot on either end, an incremental send/receive is invalidated. Normally they're read-only snapshots, so changes are usually just moving them around or renaming them. I've run afoul of this occasionally.
You don't say how you're performing these backups; I use btrfs command line with the -p switch to specify the previous snapshot. Maybe you've used a tool like snapper to generate the snapshots, and that tool has dropped the parent as part of it's clean up strategy. This can be different from time to time because things like upgrades can generate extra snapshots, and the tool's criteria for cleaning up can be triggered. For example, snapper has a parameter limiting the space taken up by its snapshots.
Now, incremental backups don't have to be be "given up". You just have to do a fresh non-incremental to get back on track. Note that it's only the immediate parent that must be present; further "ancestors" are not needed, so after an incremental send/receive the now "grandparent" can be deleted, but often there's not much point, as recent snapshots don't take up much space if older ones are kept. (For example, if there's a sequence of snapshots A - B - C - D, keeping B and C doesn't take up much extra space if A is kept.) Every few months I review all the snapshots and do a purge manually. I have monthly (roughly) backups going back to 2016, taking up far less space than 5 (years) times 12 (months) times the size of the data.
I occasionally also have this trouble because I use a bunch of backup drives connected by a nifty SATA to USB cable, and the previous snapshot for the incrementals on each drive has to be still available to do an incremental backup. It's easy to delete an old snapshot that's needed for an incremental to a drive that's been off-site; I now keep a careful log of the backups, in fact two (or three if you count my command logs) independent ones, sent off site.Regards, John LittleComment
-
Well, I buggered it up and accidentally deleted the previous subvolume, and thus obviously got the same error message when I tried to do the incremental backup again (using the -p switch). But I think the answer might be that the last incremental I did on the external HD went so fast that maybe it didn't get done right. So now I'm just sending the new @home subvolume directly to the HD and will try the incremental business in a couple of days to see if it works now. Thanks for the help, I think I get it now.Comment
-
Comment