3

I have a BTRFS backup system where I take daily snapshots (btrfs subvolume snapshot) and serialize them into incremental change files based off the previous days backup (btrfs send -f backup.date volume -p backup.date-1).

Unfortunately this means I have to keep every serialized volume forever, because I need every serialized snapshot in the chain.

I've tried deserializing (btrfs receive) these incremental snapshots and deleting intermediate volumes, but the subsequent volumes are assigned new IDs. Incremental volumes refer to their parent volumes by ID, so this breaks the chain.

Thus I have backup.Jun01.daily and backup.Jun01.monthly where the latter is pruned and has a different ID. These two files effectively contain all the same data.

Is there any way to change the ID on backup.Jun01.monthly so that backup.Jun02.daily can refer to it, whereas it did refer to backup.Jun01.daily?

Improve this question

2 Answers 2

Reset to default
0

I've taken a somewhat different and perhaps incompatible approach to yours. Rather than save the btrfs send stream with -f, I always btrfs receive to reproduce the snapshot on the backup media (also a btrfs filesystem).

Additionally, all snapshots are indistinguishable from each other - there is no difference between monthlies, daylies, hourlies etc. - they are simply named according to an isodate of the form YYYY-MM-DDTHHMMSS+hhmm. Pruning snapshots on the original host and pruning snapshots on the backup media separately hasn't so far caused me issues with incrementals but it's still early days.

What started out as a github gist has turned into something bigger, so I've named it snazzer - see https://github.com/csirac2/snazzer

I wrote what I hoped was a generically useful pruning script, or rather, a script which emits the paths of snapshots which should be candidates for pruning. See https://github.com/csirac2/snazzer/blob/master/doc/snazzer-prune-candidates.md - see the synopsis with this example:

find /some/.snapshotz -maxdepth 1 -mindepth 1 -type d | \
    snazzer-prune-candidates | xargs btrfs subvolume delete

Sadly this won't work for you, because it relies on the snapshot names having iso dates. If you get a chance to have a look at snazzer, snazzer-receive or any other bits, please do give me feedback - I'm not quite ready to release to the world (I only just added the ability today to receive snapshots from a local filesystem rather than ssh), but any feedback at all would be most welcome.

P.S. If you're initially repulsed at the fact I've chosen POSIX shell and perl for this first version, it's because I'm on a zero-dependencies rampage - I'll be adding python implementations in coming months :D

Improve this answer
0

a very simple solution would be

cd /whever/.shapshots
btrfs subvolume delete *

Since the snapshots are stored in the .snapshots folder, the command would list them (hence the * parameter) and then remove all the snapshots.

Improve this answer
3
  • 2
    if you could edit your answer to include information as to what do the commands do?
    – Tshilidzi Mudau
    Jan 11, 2017 at 9:25
  • @TshilidziMudau: I think it's rather obvious to anyone who uses btrfs subvolume snapshot what btrfs subvolume delete does. However, I'm not convinced this will work in OP's case.
    – David Foerster
    Jan 11, 2017 at 11:19
  • This won't allow me to delete intermediate snapshots without destroyed the entire chain of backups.
    – Sophit
    Jan 19, 2017 at 23:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .