>>106905072
I've always wondered how the larger archivers are handling thin provisioning or if they even are. I've actually pulled several companies off of tape backup solutions in the last few years because with modern file systems you can transfer and manage retention of thin provisioned snapshots
The cost wound up being a lot lower even paying rsync.net's markups because there's no clean way to do that with tape short of having tapes of various differential dumps, and that makes pruning stale snapshots impossible without either sending extra data and having major periodic bookmarks, or sending extra data on full images periodically. It also means restores require combining all the iterative snapshots, which adds a lot of time.
Meanwhile in ZFS land it's as simple as
>zfs destroy (snapshot)
and it automatically does that for you in the background. Need a document that was deleted a month ago and a snapshot right before then happens to still be on the live server? You can fetch it in seconds. If the snapshot isn't on the live server, but an older one is, you can do a diff from that old snapshot to the one with the file and send it from the backup. Alternatively, just mount the backup read only and pull the file. At no point do you ever have to do a full restore unless you're actually doing a full restore, and at no point does a full restore require you to send 37 weekly diffs to reassemble because your last full backup was the turn of the year.
I'm not questioning the need for tape, but I've never gotten a straight answer for how complex retention policies are implemented beyond "wow that's going to be really expensive."
