|
Re: [Networker] Directive question?
2011-12-16 12:30:41
On 2011-12-16 04:52, Frank Swasey wrote:
On 12/15/11 2:54 PM, bingo wrote:
I would never use null. Why would you create an index entry or a file
that you can't recover later?
There might be a good reason for using null but i can't really see it.
You have a client with a large filesystem that you break up into
multiple save sets for performance. Then you create a second client
definition for that same client and use "ALL" as the save set with a
directive that uses "null" to not backup all the save sets you know
about from the first client a second time. If you don't use "null" in
that second client, to actually recover the data you backed up with
the first client you have to specify at time after the first client
ran and before the second client ran to be able to recover the data at
all!
This is usually the methodology that I've employed to deal with these
scenarios. Sometimes, I have a save set for non-static data, e.g.
/data/dir1 that's listed for one NSR client resource and then maybe
another one (possibly several) like /data/dir1/specific for the static
data (may be very large), used by another NSR client resource (same
client). If I don't see any incremental changes for the static save
set(s) then I won't run another full every month on it; otherwise, I
will or maybe a numeric if the changes were small, depending on
frequency. But I always keep it on incrementals just in case. But I use
the +null directive for the first save set to avoid this area and
capture the residual. I found the idea of 'forget' with a .nsr file
intriguing, though, because it could possibly allow me to do this with
one NSR client instance, but I found the documentation for nsr (5) not
so clear. I could, of course, play around with it and test it but didn't
really want to spend all that time, so that's why I posted -
particularly for any gotchas or pitfalls that you guys might know about
that might not be documented. But trying to get that to work sounds
suspect, so I think I'll just leave things as I've done them before.
Using "skip" in that instance is just being nasty to your customers...
oh, wait. I've got a couple customers that think 100TB is small...
Maybe, I just found a Christmas present for them <bwahahaha> ...
oops... bad sysadmin sneaking out again ;-)
There are some areas that we do use skip on because our users tell us
not to back those areas up ever. But, yes, I have found that if you need
to recover data that was later skipped (or maybe it always is by another
resource), then you do have to be certain to set the time properly;
otherwise, it won't show up. I always use mminfo to get the exact time
in that case. Of course, one also has to be careful to set the time zone
correctly (e.g. UTC versus, say, EST/EDT, etc.). So I'll run mminfo on
one machine, using EST, to get the time, and then I'll run recover on
some other client, but using UTC, and then I don't see anything when I
set the same time, and then finally ... Eureka! Duh! Sheesh! That's hit
me several times ... sigh ...
George
Frank
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
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
|
|
|
