Tim Foster stated: < Hey Constantin, < < On Mon, 2006-05-08 at 11:37 +0200, Constantin Gonzalez wrote: < > I took the liberty of renaming the thread to $SUBJECT because I think that what < > we really are looking for is an ability for ZFS to automatically manage snapshot < > after they have been created. < < Wow, nice summary of the problem! < < I thought I'd add a few ideas into the fray. < < Here's what I was thinking could be fairly quick to implement, which < administrators could build upon if necessary. < < I believe we certainly should provide a way for users to schedule < automatic snapshots, but probably not build it into the filesystem < itself (imho - ZFS is a filesystem dammit Jim, not a backup solution!) < < This could be easily implemented via a set of SMF instances which < create/destroy cron jobs which would themselves call a simple script < responsible for taking the snapshots. < < Of course, this isn't as flexible as an administrator writing their own < scripts, but it could be enough for most users, with those that want < more functionality being able to build on this functionality. < < So, it's not as intelligent as the daemon Bill was suggesting, we < wouldn't poll the FS to reap snapshots when space is limited. For that < functionality, I'd hope for an as-yet-nonexistent ZFS FMA event to < report that some pools are getting short on space, which could be the < trigger for deleting these auto-snapshots if necessary (I'd also < imagine lots of other things would be interested in keying off such an < event as well...) < < < The service that we could have for taking auto snapshots could be called < < /system/filesystem/zfs/auto-snapshot < < We'd have one instance per set of automatic snapshots taken. Which isn't < to say we need one instance per filesystem, as we could define instances < that snapshot all child filesystems contained this top level filesystem. < < /system/filesystem/zfs/auto-snapshot:[fs-name] < < The properties we'd have for each instance are: < < - interval = minutes | hours | days | months | years < - period = take snapshots every how many [interval]s < - keep = number of snapshots to keep before rolling over < (delete the oldest when we hit the limit) < - offset = # seconds into the start of the period < at which we take the snapshot ( < period * interval) < - snapshot-children = true | false < < Here's some examples of SMF instances that would implement < auto-snapshots. < < The following instance takes a snapshot every 4 days, at 01:00, keeping < 30 snapshots into the past : < < /system/filesystem/zfs/auto-snapshot:tank < interval = days < period = 4 < keep = 30 < offset = (60 * 60) < snapshot-children = false < < < This instance takes a weekly snapshot, keeping the last two, and will < snapshot all children of export/home/timf[1] : < < /system/filesystem/zfs/auto-snapshot:export/home/timf < interval = days < period = 7 < keep = 2 < offset = 0 < snapshot-children = true < < < Essentially, I'm really just suggesting a glorified interface to cron, < so why not just use cron ? Well, I suspect having a service like this < would be easier to manage than a heap of cron jobs : at a glance, I can < tell which auto-snapshots are being taken, when and how. I also like the < idea of tieing into SMF, since that means other options, like the GUI < interfaces in the Visual Panels project, may become available in the < future.
Thats just so sweet (as in cool, but cute).. This can also be easily be extended to include Bill and Al's properties and user defined tag/values pairs. Just store them within the service instance. SMF can then be called upon to react to any errors or the like from these snapshot instances. That or FMA. This could tie a good few solaris features all together in a really nice way. < < Anyway, that's what I was thinking of (and it wouldn't be too hard to < implement) I've no doubt this could be refined - but does anyone think < this is the right direction to go in ? Theres no new API to be written, its easily extended and customisable, builds on features already there.. < < cheers, < tim < < [1] I'm not yet sure if SMF instance names are allowed '/' chars, sorry < [2] http://blogs.sun.com/roller/page/dep?entry=visual_panels_debut < < _______________________________________________ < zfs-discuss mailing list < zfs-discuss@opensolaris.org < http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Sean. . _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
