Networker

[Networker] Why cant I change the browse time on this CFI?

2011-09-20 17:00:51
Subject: [Networker] Why cant I change the browse time on this CFI?
From: bingo <networker-forum AT BACKUPCENTRAL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 20 Sep 2011 13:59:12 -0700
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