On Wed, Sep 27, 2006 at 11:56:54AM +0100, Davina Treiber wrote:
> William M. Fennell wrote:
> >We're thinking of doing full backups once yearly,
> >level 1 monthly, level 5 weekly and level 9 nightly.
> >Are there any Networker gotchas that would present a problem with this
> >scheme?
>
> From a NetWorker point of view, your scheme would work. You might also
> want to consider assigning different retention periods for these level
> backups, and putting them in pools that correspond to the different
> retention period. Suddenly your config has got a whole lot more complicated.
We did something close to that: full quarterly, level 3 monthly (to the
same pool,) with 6 month retentions and level 5 weekly and incremental
daily (to a same pool, but different than the first) with 30 day
retentions. Two client instances. The only trick was switching the
Quarterly/Full group from Full to level 3 and back when necessary (but
these were manual events anyway, not to mention the media handling.)
As for side effects, because of the long dependency chains, I found my
browse times were sometimes longer than I expected (and probably took up
more index space,) but since I had the disk space for the indexes, it
wasn't a big deal.
> From a practical point of view, I would NEVER do this. If I was your
> boss I would fire you for this. ;-) You would be placing a huge
> reliance on one full backup. If a tape goes bad from your full backup
> you have lost the capability to restore all your backups for up to a
> year. I get jittery about having full backups less frequently than
> weekly, but on problem clients (such as perhaps those backing up over
> slow WAN links) I might consider a schedule with a monthly full and a
> weekly level 5 or similar. I would never risk anything less than a
> monthly full. Most companies' data is far too precious.
I don't think this scheme puts data at too much risk, and in many cases
where the data takes a long time to backup and is mostly static, it can
be very useful. If your environment was 90% cold data and 10% hot, as
mine is, and you're comfortable with the concept that hot data is much
more important than cold data*, you have lots more copies of hot data (in
level 3, 5 and incremental tapes.) Losing a full might mean going back
to a previous full/monthly, but you would have most of the changed data
since then anyway. If you can frame your work in that environment, the
system "protects" hot data while not burning resources on redundant
copies of cold data.
Besides, there's cloning and other methods of making sure the full is
safe. I agree that a year is a long time. Quarterly worked well for
us. For our shorter rentention time clients, we swapped out the
Full/Quarterly for monthly fulls, but those recycle much faster than our
Quarter/Monthly setup.
Dave
>
* Yeah, I'm generalizing, but in my university environment, the
researchers really care most about what's immediately in front of them,
and not as much on what they were doing last year. (Call it the
"oooh shiney" factor.) I could see where different environments
(banking, healthcare, etc.) would have different requirements. YMMV.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
