On Mar 1, 2013, at 12:23, Daniel Eischen wrote:
> dump (and ufsdump for our Solaris boxes) _just work_, and we
> can go back many many years and they will still work. If we
> convert to ZFS, I'm guessing we'll have to do nightly
> incrementals with 'tar' instead of 'dump' as well as doing
> ZFS snapshots for fulls.
Keep some snapshots, and send stuff to tape after a certain amount of time.
Most (though not all) restores are usually within "x" weeks, where "x" is a
different value for each organization. (Things will be generally asymptotic
though.)
So if you keep 1 week worth of snapshots, you'll probably end being able to
service (say) 25% of restore requests: the file can be grabbed usually from
yesterday's snapshot. If you keep 2 weeks' worth of snapshots, probably catch
50% of requests. 4 weeks will give you 80%; 6 weeks, 90%; 8 weeks, 95%.
Of course the more snapshots, the more spinning disk you need (using power and
generating heat).
Most articles describing backup/restore best practices I've read in the last
few years have stated you want to use disk first (snapshots, VTLs, etc.), and
then clone to tape after a certain amount of time ("x" weeks). Or rather: disk
AND tape, then clone to another tape (so you have two) and purge the disk copy
after "x".
So in this instance, keep snapshots around for a little while, and keep doing
your tape backups for long-term storage. Also inform people about the
.snapshot/ directory so they can possibly do some "self service" in case they
fat finger something (quicker for them, and less hassle for help desk/IT).
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
