Re: [Networker] Turning off indexing on pools - need advice?
2008-07-22 15:16:00
Davina Treiber wrote:
George Sinclair wrote:
If you have indexing turned on for a given pool, and you later turn it
off, will this affect your ability to use nwrecover to recover data
that was backed up prior to turning it off? Can this setting be turned
on and off without affecting the information that was added to the
index when it was last on?
I wouldn't think so as this just determines whether or not the index
is updated on the server's disk, so the information would still be
there, assuming of course that you were still within the browse
policy, but any new data backed up to the pool would not be reflected
in the index, so this could only be recovered via save set recover.
But if the feature is then re-enabled later then subsequent backups
will again add information to the index. That right?
The reason I ask is because I have a special pool for very specific
one-time level full data sets, and I currently have indexing enabled
for the pool (the group, too, for that matter). I enabled indexing
because I wanted to be able to do a few browsable recovers to test
that the data was backed up correctly. The first and only save set
written thus far is 1.7 TB, so that's a lot of data to read through to
do a save set recover. I also made temporary clones, but my plan is to
recycle those clone volumes once the originals are off site. The
clones were only created to further ensure that the originals could be
read OK. In this regard, perhaps the indexing is moot, but seemed useful.
Unfortunately, these backups are one-time. There will be no further
backups of these save sets at any level. As a result, the information
in the index may never expire or get removed if there's never any more
backups, right? If that's the case, the index might grow bigger than
I'd like, so it might start to eat into available disk space. As a
result, it might be necessary to turn off indexing on the pool if I
start to notice appreciable disk shortage following subsequent backups
to this pool. I do have a *limited* number of save sets that will be
backed up to this pool (maybe 15 more at 1 TB or so each?), and then
I'm done, but not sure how much the index will grow as a result, and
I'm thinking that with no later backups, that space might just sit
there and never get truncated or freed up.
The particular NSR client resource that writes to this pool has a
browse policy of 6months and a retention policy of a Decade. There are
other NSR client resources for this same client that are members of
other groups and write to other pools, so it's not as if this is the
only client resource that updates the index.
I really don't need to keep the index entries around forever, but I
would like to be able to have the capability to perform a browsable
recovery at some point in the future. The only way I know to do that,
assuming the entries are no longer still on disk, would be to recover
an older backup of that index, but that's not possible if indexing is
turned off on the pool. But if it's turned on then I might end up
eating into more disk space than I want. Seems I'm damed if I do,
damned if I don't. Any advice?
Very long question with a short answer.
* With indexing turned on at time of backup: index is written for that
save set. Browse and retention for that save set is set at the time of
the backup.
* Pre-existing save sets are not affected by this setting.
That makes sense. Thanks for corroborating this, however.
* An index for a save set can easily be removed using "nsrmm -o
recoverable -S 123456789". You can trim down the indices for any
particular save set in this way. The index can be replaced later by
nsrck -L7 or by scanning.
It might be because we're using an older version of nsrmm (7.2.2), but I
don't see the 'recoverable' mode listed for '-o' in the man page for
nsrmm. I only see recyclable, read-only, full, manual, and suspect.
Perhaps this option is simply undocumented or was added later?
Otherwise, it looks like I'd run something like 'nsrmm -d -P -S
ssid/cloneid' wherein ssid/cloneid corresponds to the given index, and I
get the ssid/cloneid from mminfo. That sound right? Maybe this is
equivalent to running 'nsrmm -o recoverable -S ssid/cloneid' ?
I should note that if I run something like: 'mminfo -s server -q
'pool=pool_name' -r name,sumflags', I see the following for the client
index from that backup:
index:client_name cr
Seems that since the index is always recoverable, unlike the regular
save sets that are browsable (cb, hb, mb, or tb), then the nsrmm command
won't change the information that mminfo reports for the client index.
It will still report as 'cr', but the file index entries will be
removed, freeing up space, but the index will still list in the media
database, so I can always recover those index entries using scanner as
you said, correct?
What if instead, I just recovered the index itself (nsrck)? Wouldn't
that merge into the existing index and result in the same thing? Is
there a difference? Is one method preferred?
* A save set that was written without indexing on can never become
browsable unless you scan it. No other way.
Gotcha, and recovering that client index wouldn't help because that
index instance didn't have any of the file entries added to it since it
wasn't updated because indexing was turned off for the pool.
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 E/OC3 Room 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
|
|
|