Date: Fri, 1 Mar 2013 19:45:17 -0500 From: David Magda <dmagda@ee.ryerson.ca> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <4642A367-1404-4AD9-9EEF-7496006400CF@ee.ryerson.ca> In-Reply-To: <Pine.GSO.4.64.1303011209321.2046@sea.ntplx.net> References: <20130301165040.GA26251@anubis.morrow.me.uk> <Pine.GSO.4.64.1303011209321.2046@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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%.=20
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4642A367-1404-4AD9-9EEF-7496006400CF>