Re: [zfs-discuss] zfs-auto-snapshot default schedules
On 25 Sep 2008, at 17:14, Darren J Moffat wrote: > Chris Gerhard has a zfs_versions script that might help: > http://blogs.sun.com/chrisg/entry/that_there_is Ah. Cool. I will have to try this out. Jonathan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
Jonathan Hogg wrote:
> It would be great if there was some way to know if a snapshot contains
> blocks for a particular file, i.e., that snapshot contains an earlier
> version of the file than the next snapshot / now. If you could do that
> and make ls support it with an additional flag/column, it'd be a real
> time-saver.
>
> The current mechanism is especially hard as the auto-mount dirs can
> only be found at the top of the filesystem so you have to work with
> long path names. An fs trick to make .snapshot dirs of symbolic links
> appear automagically would rock, i.e.,
>
> % cd /foo/bar/baz
> % ls -l .snapshot
> [...] nightly.0 -> /foo/.zfs/snapshot/nightly.0/bar/baz
> % diff {,.snapshot/nightly.0/}importantfile
>
> Yes, I know this last command can just be written as:
>
> % diff /foo/{,.zfs/snapshot/nightly.0}/bar/baz/importantfile
>
> but this requires me to a) type more; and b) remember where the top of
> the filesystem is in order to split the path. This is obviously more
> of a pain if the path is 7 items deep, and the split means you can't
> just use $PWD.
Chris Gerhard has a zfs_versions script that might help:
http://blogs.sun.com/chrisg/entry/that_there_is
--
Darren J Moffat
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
[EMAIL PROTECTED] wrote on 09/25/2008 09:16:48 AM:
> On 25 Sep 2008, at 14:40, Ross wrote:
>
> > For a default setup, I would have thought a years worth of data
> > would be enough, something like:
>
> Given that this can presumably be configured to suit everyone's
> particular data retention plan, for a default setup, what was
> originally proposed seems obvious and sensible to me.
>
> Going slightly off-topic:
>
> All this auto-snapshot stuff is ace, but what's really missing, in my
> view, is some easy way to actually determine where the version of the
> file you want is. I typically find myself futzing about with diff
> across a dozen mounted snapshots trying to figure out when the last
> good version is.
>
> It would be great if there was some way to know if a snapshot contains
> blocks for a particular file, i.e., that snapshot contains an earlier
> version of the file than the next snapshot / now. If you could do that
> and make ls support it with an additional flag/column, it'd be a real
> time-saver.
>
> The current mechanism is especially hard as the auto-mount dirs can
> only be found at the top of the filesystem so you have to work with
> long path names. An fs trick to make .snapshot dirs of symbolic links
> appear automagically would rock, i.e.,
>
> % cd /foo/bar/baz
> % ls -l .snapshot
> [...] nightly.0 -> /foo/.zfs/snapshot/nightly.0/bar/baz
> % diff {,.snapshot/nightly.0/}importantfile
>
> Yes, I know this last command can just be written as:
>
> % diff /foo/{,.zfs/snapshot/nightly.0}/bar/baz/importantfile
>
> but this requires me to a) type more; and b) remember where the top of
> the filesystem is in order to split the path. This is obviously more
> of a pain if the path is 7 items deep, and the split means you can't
> just use $PWD.
>
I use a perl script that emulates ls, but in addition of listing the files
in the current directory looks at the timestamps of each zfs snap to see if
there are different versions and shows the FQ path and timestmp info for
each unique version. files that exist in the snapshot, but not in the
current list are shown last (with their timetamps). I suppose a
backup/restore like gui interface would be relatively simple to build with
the same principle.
My code is in horrible shape (wrote it as a one off, but it works). If
there is interest I can cleanup and post.
> [My choice of .snapshot/nightly.0 is a deliberate nod to the
> competition ;-)]
>
> Jonathan
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
I asked Tim something like that when he posted his last update and from his reply it looks like something is in the works: http://blogs.sun.com/timf/entry/zfs_automatic_snapshots_0_11 He was also blogging about this stuff in 2006 :) http://blogs.sun.com/timf/entry/zfs_on_your_desktop I've also been pestering the CIFS guys to get VSS support working, which then lets you use Microsoft's Shadow Copy Client from windows: http://mswhs.files.wordpress.com/2007/12/previous-versions.png. I'm told there's an internal build of that working now, but they have no idea when it will even be ready for inclusion in ON, so while it's in the works it's likely to be some time before we see it. Ross -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
On 25 Sep 2008, at 14:40, Ross wrote:
> For a default setup, I would have thought a years worth of data
> would be enough, something like:
Given that this can presumably be configured to suit everyone's
particular data retention plan, for a default setup, what was
originally proposed seems obvious and sensible to me.
Going slightly off-topic:
All this auto-snapshot stuff is ace, but what's really missing, in my
view, is some easy way to actually determine where the version of the
file you want is. I typically find myself futzing about with diff
across a dozen mounted snapshots trying to figure out when the last
good version is.
It would be great if there was some way to know if a snapshot contains
blocks for a particular file, i.e., that snapshot contains an earlier
version of the file than the next snapshot / now. If you could do that
and make ls support it with an additional flag/column, it'd be a real
time-saver.
The current mechanism is especially hard as the auto-mount dirs can
only be found at the top of the filesystem so you have to work with
long path names. An fs trick to make .snapshot dirs of symbolic links
appear automagically would rock, i.e.,
% cd /foo/bar/baz
% ls -l .snapshot
[...] nightly.0 -> /foo/.zfs/snapshot/nightly.0/bar/baz
% diff {,.snapshot/nightly.0/}importantfile
Yes, I know this last command can just be written as:
% diff /foo/{,.zfs/snapshot/nightly.0}/bar/baz/importantfile
but this requires me to a) type more; and b) remember where the top of
the filesystem is in order to split the path. This is obviously more
of a pain if the path is 7 items deep, and the split means you can't
just use $PWD.
[My choice of .snapshot/nightly.0 is a deliberate nod to the
competition ;-)]
Jonathan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
Almost exactly what I was planning to configure here Nils, with a couple of minor changes. I was planning on taking 10 weekly backups since you occasionally get 5 week months, and depending on storage capacity, we're also considering annual snapshots. I quite like Tim's idea of having 31 daily snapshots too. We already have that for some of our data, so it might be easier to just use that globaly. Our policy is likely to be: 15 mins: keep 8 hourly: keep 48 daily: keep 14 (or 31) weekly: keep 10 monthly: keep 24 yearly: keep 10 For a default setup, I would have thought a years worth of data would be enough, something like: 15 mins: keep 8 hourly: keep 48 daily: keep 31 weekly: keep 10 monthly: keep 12 Ross -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-auto-snapshot default schedules
Tim, > - Frequent snapshots, taken every 15 minutes, keeping the 4 most recent > - Hourly snapshots taken once every hour, keeping 24 > - Daily snapshots taken once every 24 hours, keeping 7 > - Weekly snapshots taken once every 7 days, keeping 4 > - Monthly snapshots taken on the first day of every month, keeping 12 I prefer the default number of snapshots kept to span twice the interval of the next period (? right wording?). to illustrate: frequent: keep 8 hourly: keep 48 daily: keep 14 weekly: keep 8 monthy: dont care, I use 48 I believe it is important keep as many snapshots as necessary to give the user a change to move a snapshot from a "finer class" to a "coarser class" to prevent snapshotted data from the time frame in question from expiring prematurely in case a "coarser" snapshot was not be taken. Nils ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
