A clone is an exact duplicate, so if you keep the B_clone the third incremental
will be taken from that point.
Using a non-indexed pool is unlikely to get you any performance improvement,
unless your server is backing up more than 1000 clients and the storage your
indexes reside on is very slow. You will also make recovers much more
difficult. Have you taken a look at the NetWorker Performance Tuning Guide?
Slow client backups are generally caused by incorrectly configured NICs or very
dense file systems. Both these can be addressed in better ways.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of NETWORKER automatic digest system
Sent: 08 August 2012 05:00
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: NETWORKER Digest - 2 Aug 2012 to 7 Aug 2012 (#2012-55)
There is 1 message totaling 92 lines in this issue.
Topics of the day:
1. Effect on incremental if clone remains but original removed?
----------------------------------------------------------------------
Date: Tue, 7 Aug 2012 12:28:04 -0400
From: George Sinclair <george.sinclair AT NOAA DOT GOV>
Subject: Effect on incremental if clone remains but original removed?
Hi,
Please excuse the long winded question, but I want to be clear on what
I'm asking.
Question here about whether or not a clone save set that remains in the
media database will affect a subsequent incremental backup if the
original counterpart save set is removed?
My understanding is that NW uses the last valid media database entry for
the given save set to determine the timestamp to base the next
incremental for that same save set, assuming, of course, that the
database entry for the previous one is valid (e.g. not aborted). The
indexes are not used to determine what to back up, only for recovery
when doing browsable recovers. Moreover, indexing is turned off on clone
pools. But I'm unclear on how clone entries affect subsequent
incrementals in cases where the original counterpart has been removed.
Let's suppose you run an incremental (incremental 1) to an indexed pool
(pool=A), cloning is enabled (clone pool=A_clone). The next day, you run
a second incremental (incremental 2) but this time to a non-indexed pool
(pool=B). You then clone that second incremental, but to a different
clone pool (clone pool=B_clone). You then remove the media database and
index entries for that second incremental as:
nsrmm -d -S ssid/cloneid_from_original
but you keep the clone entry (from clone pool B_clone); it stays in the
media database.
On the third day, you run a third incremental (incremental 3) but this
time back to the original pool (pool=A). That's automatically cloned
(clone pool=A_clone). If that's successful you then remove the clone
entry from the second incremental (incremental 2).
QUESTION: Will NW base the third incremental on what's changed since
incremental 1? I would think that it wouldn't have any choice given that
you removed the media database entry from the second incremental, right?
In other words, the third incremental should back up exactly what it
would have done if you had never taken that second incremental, but
there is a concern here as noted below.
CONCERN: The problem here, though, is that in this case you've not
removed the clone entry (clone pool=B_clone) from that second
incremental before taking the third, so will NW still see that ssid
(clone) entry and base the third incremental on the timestamp for that
remaining clone entry (clone pool=B_clone), or will it instead base it
on the first incremental since the original for the second incremental
was removed, never mind the fact that its clone entry still exists?
BTW: This question comes up because we want to run a test to see how
much faster a given save set can be backed up with indexing turned off,
but we don't want to actually turn it off on that pool since we have a
lot of other clients/save sets that write their data to that same pool
wherein we do desire index entries. So our plan is to create a test pool
with indexing turned off, and a corresponding test clone pool, and then
switch the affected client' s NSR resource group to use the test pool
instead, then run an incremental, analyze the results/speed, remove that
incremental save set entry and then switch the resource back to using
the original pool, continuing (we hope) where we previously left off
before we ran the test.
Clearly, this would work if we either didn't make a test clone or we
removed both the test clone entry and its original counterpart before
taking the third incremental, but will it still work if we make that
clone and we don't first remove it before the third incremental is run?
The reason for keeping the clone copy from the second (test) incremental
is just to have something to fall back to in case the third (normal)
incremental failed, and we needed to recover something before we could
get another good back up. The test pools could then be recycled.
Thanks.
George
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
------------------------------
End of NETWORKER Digest - 2 Aug 2012 to 7 Aug 2012 (#2012-55)
*************************************************************
|
