Thanks. Here's what I ended up doing yesterday to resolve this issue.
First, I identified all the save set ids for
the subsequent incrementals that ran to the usual nightly pool and were
also backed up prior to the test pool. There
were not that many save sets and none of these was that large but to
reiterate, there were 2 sets:
The first ones ran before I could remove that test pool volume, and the
second I manually ran after I had removed the volume.
And no, I don't know why I did that since that just made things worse,
but whatever....
I then ran 'nsrmm -d -S ssid' for each one of those save sets to remove
the information from both the media database and
the affected client indexes. This put the indexes back to where they had
been before I backed up anything to that
test pool or rather, the part of the indexes that had this information
for those particular NSR client resource.
I then reran the incrementals. I knew these would not take that long to
run since these incrementals are usually
not that big. The numbers all looked good. Of course, in most cases,
more data was captured this time than would have been
otherwise since those subsequent index entries had been removed with the
nsrmm command.
This was simply the most expeditious method I could think of to solve
this issue. Now, if it had been more than just a day or
so, I may have used a different solution, but typically most hosts skip
backups on weekends, so this didn't put us behind
by an unacceptable amount.
Here are some other things I considered:
1. Run a level full or numeric on the affected save sets.
This would have worked but has the disadvantage in that it would have
taken longer than I had time to mess with and
those previous incrementals might still be dependent on the volume I
removed, so it's still always possible someone
could try to use those, not knowing to use the full or numeric instead,
unless, of course, you remove those save sets,
but then why not just do what I did.
2. Go to the affected clients and run manual incrementals and specify a
time before the subsequent incrementals were
run and just after the ones were run to the test pool.
I see no reason this would not have worked, but you still might have the
dependency problem noted above.
3. Maybe same as 2 but do this from the server by specifying the group name?
4. Recover an older version of the client index from before the backups
to the test pool were run.
Getting the index off tape would be reasonably quick, but the problem is
that once the index is recovered, NetWorker then
begins that long process of all the goofy assimilation and meta merging
or whatever it does which can take a long time
on a big index. Actually, come to think of it, I could have just removed
the client index all together and recovered the
last copy, but then it has to get the previous full and merge, and oh,
.... not worth it in this case.
Dave Mussulman wrote:
On Fri, Mar 16, 2007 at 09:26:49PM -0400, George Sinclair wrote:
I was running some level full backups from several clients in order to
test backup speed to a new tape drive. The tape was labeled
into a test pool and not the normal pools I use, but indexing was not
turned off for the pool. I cancelled the backup after
a while, but some of the fulls completed. I then relabeled the tape but
not before some nightly incremental backups ran and
completed on those same clients. I then re-ran those incremental backups.
I assume that some of the later incrementals based their backups on what
had changed since those same file systems completed fulls
in the earlier test, but now with the full volume gone, what do I do? Do
I need to do anything?
George,
My gutshot is that with the full removed, with dangling dependencies,
Networker would remove the orphaned incrementals the next time it did
its index cleanup. That means any future incrementals would base
themselves off whatever the last good previous state was. But please
don't take my word for it; test it first. I've found the unix nwadmin
Index view to the best, fastest way to see backup dependencies. (You
can kind of generate it from mminfo, but not as quickly and it doesn't
do the indenting.)
In any case, I would probably run some true leveled backup (a full or
numbered backup) to reset the future incrementals to a good state. If
possible, scheduling a full to proper media is probably the best idea.
Dave
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
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
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
|
