Re: [Networker] Why cant I change the browse time on this CFI?
2011-09-20 19:41:40
On 2011-09-20 16:59, bingo wrote:
Hi Jee,
in principle, you are right. However, if you want to explain it precisely, you
must be very precise . So let me please make some corrections.
--------------------------------------------------------
The CFI is an online db. It contains file information about your savesets on
your media.
A saveset is browsable as long as the relevant index records are is still
online (i.e. on the server under /nsr/index by default)
When the browse retention of a regular saveset (e.g. " /home") expires, then
the associated index records are removed from the server and you cannot
browse the /home files from that saveset anymore (unless you can recover
those records)
This is the correct sequence:
1. Depending on your policy settings, the save set will be set to recoverable
or directly to recyclable.
2. In the next step, the CFI db instance for the save setS will be removed.
I use the plural because usually you have dependent save sets and you can
only delete a whole backup cycle.
I point this out because if you manipulate, you always address the save set
(via nsrmm).
You can not delete a CFI instance.
<<<
Even if your saveset retention has not expired you can still do a saveset
recovery.
In fact, you can still recover even a recyclable save set. The only exception
is that for an (A)FTD volume, such will be removed from disk immediately or
with the next nsrim process.
<<<
However if you want to be able to browse that saveset and perform a
file recovery, then you will have to recover the client file index first
(that is, if you have a recoverable saveset with the relevant client file
index records -- i.e. from that savetime).
Changing the retention of the index saveset will not put those records back on
the server magically. You need to recover the index using nsrck -L7 (or scan
the saveset -- note: scanner won't recover the index of some savesets -- like
NDMP).
Correct. NDMP uses another (its own) data format which does not include the
metadat within the data. And as it is not there, you can not retrieve it).
<<<
Note: The data saveset doesn't have to be browsable to recover the index. If
it is already browsable why would you want to recover the index? It was the
nsrck -L7 of a recoverable index saveset what did the trick. The retention of
the index saveset could have been any date as long as it was in the future.
The retentions of the index saveset and regular saveset are irrelevant as long
as they have not expired. If they have, then nsrmm can be used to set the
retention "back to the future" Wink.
Also note: It is possible to configure NW not to backup the index of some
client and yet set an "infinite" browse policy for that client.
I do not understand this statement. You can of course carry your index forever
without having it ever backed up. These are total independent issues.
You can set the option "no index save" but be careful - it is misleading. It is
not that the index will not be backed up - it will not even be generated!
The difference is important:
- It sounds that the index info is written to the CFI but not backed up.
- However, the CFI info is neither written to the CFI nor embedded within
the save stream.
- Consequently, there is no CFI info what you could retrieve with 'scanner'.
I think I'm confused here. When I have the "No index save" option turned
on for a group (store index entries is checked for the pool), and I run
a backup, the index does get updated, but no save set is entered in the
media database for the client index. I confirmed that the index is
getting updated by running nsrinfo and passing it the nsavetime value
returned from mminfo. I see the data there. Also, I can see that new
entries have been added to /nsr/index/client that were not there before.
Their time values agree with the save set time.
So you're talking about the information pertaining to the actual CFI
itself and not the files that make up the CFI? Where does that get
written to? Anywhere? If so, what is that information exactly?
I've used scanner to recover indexes (when the "No index save" option
was not checked). It works, but I never did anything with the recovered
index. I was just testing.
George
<<<
jee
+----------------------------------------------------------------------
|This was sent by carsten_reinfeld AT avus-cr DOT de via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
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
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. -
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
|
|
|