On Fri, 5 May 2006, Constantin Gonzalez wrote:
> Hi,
>
> (apologies if this has been discussed before, I hope not)
>
> while setting up a script at home to do automatic snapshots, a number of
> wishes popped into my mind:
>
> The basic problem with regular snapshotting is that you end up managing
> so many of them. Wouldn't it be nice if you could assign an expiration date
> to a snapshot?
>
> For instance:
>
> zfs snapshot -e 3d tank/[EMAIL PROTECTED]
>
> would create a regular snapshot with an expiration date of 3 days from the
> date it was created.
1) But is this something that belongs in ZFS or is this a backup/restore
type tool that is simply a "user" of zfs?
> You could then change the expiration date with zfs set if you want to keep
> it longer. "0" would mean no expiration date and so on.
With zfs or with your backup/restore tool?
> Then, ZFS would be free to destroy the snapshot to free up space, but only if
> it must: Just like the yogurt in your fridge, you may or may not be able to
> eat
> it after the best before date, but you are guaranteed to be able to eat it
> (or sue the yogurt company) if it's inside the best before date.
See 1) above
> Another property could control the rigidness of this policy: Hard expiration
> would destroy the snapshot as soon as the expiry time arrives, soft
> expiration would work like the yogurt example above.
See 1) above
> The benefits of this approach would be ease of complexity: Imagine you do
> a snapshot every week, then you'll have 52 snapshots by the end of one year.
> This means that sysadmins will start writing scripts to automatically
> delete snapshots they don't need (I'm about to do just that) at the risk
> of deleting the wrong snapshot. Or, they won't because it takes too much
> thinking (you really want to make that script really robust).
>
> Another set of expiration related properties could allow for more complex
> snapshot management:
>
> - Multiple layers of snapshots: Keep one Yearly, one monthly, one weekly
> and the snapshot from yesterday always available.
>
> - Multiple priorities: Assign priorities to snapshots so less important
> ones get destroyed first.
>
> - Specify date ranges to destroy/modify attributes on multiple snapshots at
> once.
Again - this looks like an operational backup/restore policy. Not a ZFS
function.
> Is this something we're already looking at or should we start looking at
> this as an RFE?
>
> Thinking further, ZFS could start doing automatic snapshots (invisible from
> the user) by just keeping every uber-block at each interval. Then, when the
> admin panics, ZFS could say "hmm, here's a couple of leftover snapshots
> that happen to still exist because you had a lot space left on the disks
> that you may find useful".
Now you're describing a form of filesystem snapshotting function that
might have to be closely integrated with zfs. This is in addition to the
other data replication features that are already in the pipeline for zfs.
> The basic idea behind this whole thinking is to maximize utilization of free
> blocks. If your disk utilization is only 50%, why not use the other 50% for
> snapshots by default, that could save your life?
IMHO the majority of the functionality you're describing belongs in a
backup/restore tool that is simply a consumer of zfs functionality. And
this functionality could be easily scripted using your scripting tool of
choice.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
