It would be also nice that if you have many snapshoots and you do run out of
space that the oldest snapshoot would be automatically removed untill space is
freed up. I did setup this snashoot that is beiing made every minute, then every
hour, day and a month, and I finally got to the point where I did run out of
space, olders snashoots were not removed space was gone and server could not be
used. I was just testing this backup and no harm was done but I think haveing
space is the most important, snapshoots are not as critical as beeing able to
write to a disk... but hey. just a suggestion.
Chris
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.
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.
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.
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.
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.
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".
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?
Best regards,
Constantin
--
Constantin Gonzalez Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions http://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
!DSPAM:122,445b13fd55112750596!
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
