Open ghost opened 5 years ago
Thanks for the suggestion, added "enhancement" label.
I'm not sure if this is worth the effort: this adds redundancy, and implies a new framework for checking these symlink, and keeping them up-to-date might not be trivial (note that the latest transferred backup is not always the latest by date, e.g. on "btrbk resume").
Also, it's very easy to do this in a shell script, using something like:
ls -d /mnt/bootvol/boot\.* | tail -n1
btrbk list latest /mnt/bootvol/boot --format=raw
Of course, people have different needs, so this needs to be configurable.
Which is probably the strongest argument why not implement it in btrbk directly, but rather in helper scripts.
I would highly appreciate a current and previous symlink. Why should keeping this up-to-date not be trivial? If btrbk is the master of the snapshots, it could reset the symlink after every new snapshot.
Trying that btrbk list latest
it returns the same count of lines, just with a different set of columns.
btrbk list has:
source_subvol snapshot_path snapshot_name target_path
btrbk list latest has:
source_subvol snapshot_subvol status target_subvol
How is the logic behind this? At least I can determine the latest snapshot like this:
$ btrbk list latest /mnt/usb/mobiledata/snapshots/gentoo-mb/home/ --format=raw |sed 's/.*target_path="\([^"]*\)".*/\1/g'
/mnt/usb/mobiledata/snapshots/gentoo-mb/home/home.20190926T071000+0200
But often I need to use paths from command line for vimdiff, rsync or cp for restoring parts of the backup. There I would need to use some "$(getlatestsnapfrom mobiledata desktop-home home)"
(modelling the path structure of device, machine, sub that is already there), while just having a current and previous symlink would probably lead to the snapshot I need.
I'm also interested in this feature. I think I have also found an argument for implementing it in btrbk which I have explained at the end (but I'm still unsure if it's a good idea, simply because of the added complexity mentioned by @digint).
First I want to note that determining the latest snapshot is not trivial when taking different timzones and daylight saving time into account. Furthermore, to be able to calculate it from the filenames, it is necessary to have them in long-iso
format - but they still won't sort correctly when simply listing them in lexicographical order.
Example: Germany has DST and this year, of the following two timestamps the first will be 50 min earlier (in physical time) than the second one:
20221030T023000+0200
20221030T022000+0100 <- 50 min later in physical time
But when listing them in lexicographical order, the later timestamp (in physical time) comes actually first:
20221030T022000+0100 <- 50 min later in physical time
20221030T023000+0200
Since we are talking about backups, IMO it's not acceptable to have it fail regularly, even if it's just a one-hour window per year...
I guess an alternative could be to try to determine the latest snapshot using some btrfs subvol list -r -s -o --sort=+gen <path>
(or so) command, but as far as I can see one would still have to filter out the desired snapshots by pattern matching, since there might be snapshots of several different subvolumes in one snapshot_dir
or target
...
For btrbk it would be probably easier to link to the latest snapshot than for a script. Not because it can determine it easier than, say a bash script (I think the logic for that will be roughly the same), but because it's easier for btrbk to update the links: In each run, btrbk knows which subvolumes/targets/etc. it touched, and thus where the links need to be checked and possibly updated. If the link logic would be implemented in a separate script, it would have to check all possible places for changes that are configured in btrbk, despite the fact that btrbk might have updated a subset of them. Also, access to remotes is already configured via btrbk - that would have to be replicated in the script, if it would update the links also on the remotes.
Since it's unlikely to have that implemented in btrbk soon, even if that feature were to be accepted, and since one probably does not need "latest snapshot" links on every target/archive, but maybe even only in the local snapshot_dir
, I'd say let's create a separate script for now. If it's solid, maybe it could even be added into contrib/tools
.
Hi, I started a script that adds a "latest ->" symlink in all target directories. I run this after each btrbk cronjob for different btrbk.conf files.
Could we add that to contrib/tools?
update_snapshotlinks
Please adapt the title and replace "last" by "latest".
My current workaround script: update_snapshotlinks
My default cron-job looks like
btrbk -c /etc/btrbk/btrbk.conf run cron && update_snapshotlinks -c /etc/btrbk/btrbk.conf /mnt/local/data/archive/*/*
However remote targets are currently not managed by this: For instance I also send snapshots to remote ssh targets which I don't re-link with this script. Local cron-jobs there do the re-linking.
I still think, btrbk could be easily set the symlink after every successfull snapshot creating on whatever target.
@Massimo-B this script looks great! I think I will give it a go.
To add my own bit of colour to the debate of if this should be part of btrbk…
I am currently working out if I will use this tool for my scheduled backups or use buttervolume. Having a latest
directory so that I can rsync that to a remote is needed for either of my avenues. It would be cool if btrfs-progs offered this support so that both of these tools could have this functionality.
As mentioned by @Massimo-B on https://github.com/digint/btrbk/issues/283#issuecomment-509572074 I think it is a good idea if Btrbk would create a symlink to the last snapshot in the source volume. This should of course be configurable as the where the symlink is placed and what it is called.
For example if we have this setup:
A symlink could be placed in
/mnt/rootvol/snapshots/
linke thisAnother option
Third option
Of course, people have different needs, so this needs to be configurable.