We have the following policy: "snap sched 2 6 12", 2 weeklies, 6 nightlys, and 12 hourlies.

Since the data on our toasters is being edited interactively there is a high probability that lost or corrupted data will be discovered the day it occurs. By using 12 without the @ I can get back to good data to within an hour of when it was messed up on the day of occurrence. This has worked out well for us.

NOTE: I am using up 20 snapshots which is the limit. If you are doing a dump (which creates its own snapshot) you should leave off 1 snapshot from the schedule. We are backing up toasters using nfs mounts and OpenVision Netbackup software.

regards, Steve Gremban gremban@ti.com

------------- Begin Forwarded Message -------------

From madhatta@turing.mathworks.com Mon Mar 31 16:43:31 1997

From: sterling@netapp.com (Bruce Sterling Woodcock) Subject: How do *you* manage snapshots? To: gremban@msp.sc.ti.com (Steve Gremban) Date: Mon, 31 Mar 1997 14:41:50 -0800 (PST) Cc: toasters@mathworks.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit

We have the following policy: "snap sched 2 6 12", 2 weeklies, 6 nightlys, and 12 hourlies.

Interesting. I use "snap sched 1 6 7@8,10,12,14,16,18,20". This tends to translate to about a 10 - 20% snapshot reserve depending on our filer's usage pattern... I like to keep that snapshot reserve 50 - 75% full most of the time so I have a buffer to handle large deletes gracefully when they occur. What snap reserve do you use? I am curious to hear from other admins on this issue as well.

Someone else mentioned that when both the filesystem and snapshots are full, it can be very tricky and may require manually deleteing snapshots. This is quite true. As I think the manual mentions, "preventing" a snapshot from growing could lead to strange behavior (i.e. rm *failing* due to lack of disk space). The only real workaround is to keep a snap reserve large enough for your desired schedule. If you need to, buy more disk. :)

Bruce