I agree, there are conflicting priorities that have to be balanced to
get the most out of your system. Fortunately, our requirements make a
combination of staging and cloning work for us. We need to immediately
clone to tape to send copies of our backups off site. This is crucial
to any disaster recovery plan unless you can replicate your data and/or
backups directly to another location.
What we do is back up to disk, and clone later in the day to tape via
script (more efficient than automated savegroup cloning). Our clones
have a two-week retention period. Our backups have a 90-day retention,
and we keep them on disk as long as possible, using automated staging to
keep enough disk space free for additional backups. Tuning staging is
time consuming, but once you have it you won't need manual intervention
to free up disk space while keeping your backups on disk as long as
possible.
As an aside, realistically speaking you probably won't need to keep
backups on disk for quick restores beyond a certain period. Almost all
environments I've seen will see 80-90% or their restores being done with
one to two week old backups. Having to go back many weeks is fairly
rare, so you can give your staging a pretty wide margin if you don't
want to spend a lot of time tuning the staging policies.
Andy
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Davina Treiber
Sent: Monday, November 26, 2007 4:59 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Storage Node disk space is full
There is some merit in doing it this way. The way I see it, it boils
down to two questions:
(1) When do you want to have the data written to tape? Answer: As soon
as possible, in order to get it safer.
(2) When do you want to remove the save sets from disk? Answer: At the
last minute, right at the time when you want to make space for another
backup, so as to gain the maximum benefit from disk based devices.
Staging accomplishes neither of these. If you stage early you don't get
the benefit of fast access to data on disk devices. If you stage later
it might take too long and delay the next backup. So cloning it off as
early as possible followed by deleting using nsrmm and reclaiming space
is the optimum strategy. Problem is you need a good script to achieve
this.
It is easier at 7.3.x and above than it was at 7.2.x, but still not a
trivial task.
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 with 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
|
