Can't locate files in backup snapshot directory #138
Comments
In general, re: ZFS, we have tried to do this via the Re: btrfs, auto-discovery of such pools may not be possible because of how you sent (or copied, which, if you see my next comment, is a no-no!) the datasets. If it were me, I'd first try to be as close as possible to the ZFS topology and see if you can't use
Here, it seems See below, |
|
@bshor very much appreciate you filing a bug report. Especially the included detail. However, if I am to keep this issue open, I'm going to need you to confirm whether my supposition is correct, that is -- you copied rather than sent the sub-volumes to a new location, or for you to tell me whether perhaps something else is going on. Again -- I'm very pleased to discuss further, but will need a response from you. Thanks! |
|
I apologize for the late response, work has been hectic. I will respond in detail in the next 12 hours (replacing this response). |
|
Ok, back on! I'll be much quicker to respond now. I appreciate the very close attention you are giving me!
Unfortunately the -a flag doesn't seem to work.
Ok, so /btrbk is definitely the TARGET of send operations which is executed by btrbk. The whole point of btrbk is to unify taking snapshots and to send them to a backup location (here, /btrbk). Here's my btrbk configuration (/etc/btrbk/btrbk.conf):
Hmmm. While I don't fully understand this debug output, I'm trying to express that /data is my live data, and that /snapshots is where snapshots of /data go, while /btrbk is where backup snapshots are sent to. Those backup snapshots are very useful because they live a lot longer than in /snapshots. I guess what I'm confused by is why don't we see entries that look like Just to show you, here's the contents of /btrbk:
And the contents of /snapshots:
Thank you again for your attention and patience! |
Yes, as noted, you would first need to rearrange your snapshots to be in the form of a ZFS snapshot topology. For now, I am supposing this is not possible for you (you're using btrbk, and this is how btrbk does things), and we will move on. You will need to, in this case, to use
I am no expert in The question is then: Why doesn't So -- I would check It is possible that even after btrfs sends a backup it still relates that backup with the same sub-volume, and never re-associates it with a new dataset, like ZFS. To the extent btrfs is just weird, and the behavior is not well-defined, it may be hard to help you, but maybe this is logical in btrfs world where a snapshots is sent to a new dataset on the same machine? It's also possible your "backups" are privileged, whereas your "snapshots" are not, and you simply need to use
|
|
Thank you again for writing. I feel bad for taking so much of your time for something that appears to be a BTRFS idiosyncracy -- but since you want your tool to work in BTRFS and btrbk is VERY common for BTRFS file system enthusiasts, maybe it's a useful exercise. I'd love to try --map-aliases but as you can see above I tried my best and couldn't figure it out. subvolume list -s /btrbk shows (clipping a bunch for being concise: sudo btrfs subvolume show /btrbk shows: Misc points:
|
This means it is possible to at least list those volumes! I'll start thinking about how best to allow with
This is some btrfs weirdness where the snapshots are transferred but then not re-associated with any mount. It may just be that I'm more comfortable with ZFS (which is true!). But I also think the way btrfs handles snapshots is leaky implementation detail, where virtually all the functionality one could implement is permissible in btrfs. This is fine for users who want configurability, but it makes certain things impossible, like: Writing a snapshot tool, that works with all other snapshot tools, and which can write to custom btrfs snapshot locations safely. This is just another layer of the btrfs onion and I will try to patch it up as best I know how, but it's simply btrfs wildness that makes it harder for |
|
Thank you for your amazing brainchild! I really, really hope you don't abandon BTRFS functionality -- and I'm unhappy I may have inadvertantly pushed you in that direction. httm is AMAZING! It's ridiculous to have to manually much about directory trees to restore an older version of a file which is what I did before httm. Now I can just quickly say which file I want to lookup and restore the desired snapshotted version in seconds. So cool. This is merely a wished-for feature ... httm works really well AS IS, and if there were no easy support for backup snapshot restoring, I would 100% fine with what we have. Really, really, please stay! ps When I said the subreddit, I mean I'd try to do the legwork, but I think since I see you there sometimes, I'm afraid of creating more work for you, so I'm ok with status quo. |
I'm using httm 0.43.2 on a Debian 12 system, with a BTRFS file system and btrbk for creating snapshots. It works perfectly for showing the older versions living in my snapshots directory, which is located at
@snapshotsand mounted on /snapshots. My data is located at@dataand mounted on /data. On a separate drive, I have@btrbkmounted on /btrbk. This is where I send "backup" snapshots.For my local drive, these are both top-level subvolumes:
For my backup drive it is as well:
ID 257 gen 16551 top level 5 path @btrbkHere's an example of it working as expected using snapshots in /snapshots.
But I can't seem to get httm to look at /btrbk on the other drive.
I tried map-aliases but no luck:
/snapshots and /btrbk look the same... a long list of snapshots.
I'm guessing that httm is trying to look in obvious places for snapshots, and doesn't think to look in some other place for them. Which is fine -- but is there a way to tell it to look there?
Here's the debug output. Interesting that it appears to believe /btrbk is a live subvolume that might have its own snapshots.
The text was updated successfully, but these errors were encountered: