Q: Local snaphosts

[grishy]

Hi,
Thanks for your idea on how to back up 😄.
I want to ask you about the local backup required for this.

In btrfs, when you are creating a snapshot, you specify from where to calculate the delta. So, in that case, to have a delta from the beginning of the year, you would need to have a snapshot from the start of the year.

Is it a good backup strategy to store backups locally and not be able to clean btrfs because of a snapshot in December?
WDYT @sbrudenell ?

[sbrudenell]

good question.

I haven't written anything in the docs about choosing a backup strategy. I should do that.

(I've never been a "real" sysadmin (just a self-hoster who really cares about not losing data), so my thoughts aren't expert thoughts)

I'd say there's a difference between retaining "essential" data to restore a broken system to a good state, versus retaining data for "historical"/auditing reasons. if it's essential data, consider that local snapshots provide random access. btrfs send archives must be completely restored to access any file. snapshots are also cheap: local disk is cheaper than remote disk, and they're more deduplicated than a differential tree can be.

it's also worth considering (and measuring) how frequently your data is overwritten. if it's append-only (like a photo archive), then snapshots don't cost anything in terms of disk usage. if it's overwritten once a day, then excess snapshots will cost a lot.

so, those are two dimensions where keeping more local snapshots may be a good idea or not. and the dimensions interact with each other, and there's certainly more I haven't thought of.

currently btrfs2s3 retains local snapshots one-to-one with remote backups. this is because it was simple to write it this way, not because I'm convinced it covers all cases well (#33 would expand it to cover "historical" backups better). I'm especially eager for anecdotes and cases where this strategy breaks down so I can figure out what's useful to write.