Bingo,
I don't think I am being imprecise, that's in your not at all humble opinion.
I do think, however, you didn't get the point, i.e. not to confuse the online
CFI with the special index:client_name savesets.
BTW. scanner doesn't "recover" any index (as mentioned some emails ahead of
this one), instead it "scans" (hence the name) the whole saveset and
recreates its index. That is, if the backup is right for that (NDMP savesets
are not).
jee
On Tuesday 20 September 2011 21:59:12 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'. <<<
>
> 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
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
|
