reovery of out of browse period file index 1

[cadencep45]

All,

I am looking to recover a file index on a backup of a filer which is outside of the browse period.

I have run mminfo to determine the correct tapes I require.

I have then run scanner -i /dev/rmt/4ubn

to scan the volume.

However I cannot see the file index for this volume following this.

Looking at the man page, it suggests running;

nsrck -L7 -t "date" client

This requests the associated index tape to recover the index. I am trying to recover this browse period by rebuilding the file index for this date rather than through recovery.

is there an additional step required following the scanner command ?

Tks.

 

[Chapter11]

include "-S ${SSID}" on the command line for scanner for the particular savesets you need to recover from.

 

[cadencep45]

I have run this;

scanner -i -S 3769786113 /dev/rmt/4ubn

this seems to process correctly. However when I check the
clients history, details of this saveset are missing and
I cannot browse back to this date. Is there something I am missing following this step ?

 

[605]

If scanner was running fine, you most likely use the wrong browse time.

 

[cadencep45]

I could believe that, however when I check the client index, there are no reference to the SSID in the list of browseable savesets. ( How I did this was -From NT legato administrator, click on indexe tab, right client on client and click on show save sets).

I also tried looking at the volume and could see the saveset, but it was status recoverable rather than browseable ).

 

[605]

That would then explain why you do not see your files in the index.

And btw, there are no references to the ssid in the file
index - the savetime is all NW needs.

However, be aware that sometimes there are mismatches between the GUI and the command line - i always use the command line for index queries and management.

So please check for the status again from the command line.
You may also read the file index for that client and check
the filename (of course you must know it):

nsrinfo client | grep filename

 

[cadencep45]

Thanks for the responce.


>And btw, there are no references to the ssid in the file
>index - the savetime is all NW needs.

So how can I verify that a particular saveset of browseable - I though what I did was fairly accurate.


>So please check for the status again from the command line.
>You may also read the file index for that client and check
>the filename (of course you must know it):

nsrinfo client | grep filename

unfortunatly I do not know the filename ( if I did I could simply do a restore directly without needing to browse - and as the saveset is approx 11 GB, I really do not want to have to restore the entire thing to get access to a few K of files ).

As the saveset is from 2002, I tried the following;

nsrinfo client | grep 2002

( client being obviously replaced with the proper client name ).

The result is no matches for year 2002

Any pointers at this stage would be appreciated.

 

[Chapter11]

do this:

mminfo -v -q ssid=${SSID}

The "Flags" column is either cr or cb. If it's cr, then it's just recoverable. If it's cb, it should be browsable, provided you set the date right in your recover command.

 

[605]

The status info about a save set status is in the media db. As chapter11 pointed out, the command you need to run is mminfo.

BTW, "cE" would mean recyclable. In fact there are 2 infos in the "sumflags" field. As mentioned already, the right letter represents
the save set status. The left letter represent the save set completenes:
c - save set is completely stored on this media
h - the begin of this save set is stored on this media
m - a middle part of this save set is stored on this media
t - the end of this save set is stored on this media

 

[cadencep45]

Thanks for the feedback,

I have run this, and I get the following ( cut from output )

mminfo -v -q ssid=3769786113

size ssid fl lvl n
6620 MB 3769786113 hEN full

4665 MB 3769786113 tEN full

As per the previous responce, this means;

hEN The beginning of this save set is stored on this media
tEN The end of this save set is stored on this media.

However, this merely tells me that the save set is on the media, but does not give me further info regarding the browsable status ?

The E means that the volume is Eligibal for recycling.

The N means NDMP generated ( which is correct ).

Regarding the E flag, from the mminfo man page

"The second flag indicates the status of the save set. A b
indicates that the save set is in the on-line index and is
browsable via the recover(1m) command. An r indicates that
the save set is not in the on-line index and is recoverable
via the scanner(1m) command. An E indicates that the save
set has been marked eligible for recycling and may be over-
written at any time. a indicates that the save was aborted
before completion. Aborted save sets are removed from the
on-line file index by nsrck(1m). An i indicates that the
save is still in progress."

So, how do I go about converting the status from E or b - I though running this;

scanner -i -S 3769786113 /dev/rmt/4ubn

I was doing this ?

 

[Chapter11]

When I've had [chmt]E savesets, I've had to delete them and rescan them before they show up as "b" or "r".

If after deleting and rescanning, they show anything but b or r (usually "a", sometimes "i", sometimes "E" again), the saveset is toast - delete it for it and forget about it 'cause it's not recoverable in any way.

(It would be really nice in future versions of Networker if munged savesets could still have what data is available to be recoverable).

 

[605]

Correct, "E" reports a recyclable save set.


"NDMP" is the key issue - you can not recover client file index info with scanner on NDMP backups. Why? Because it is not there!

NDMP save sets are block level backups - the filer is actually defining the format, not NetWorker. And as this save stream data does not contain embedded client file index info like NetWorker's Open Tape Format, there is nothing to recover. (However, scanner -m will work).

So i think the best is to recover the backup to a temp location and recover your files from there.

 

[cadencep45]

Ah, makes sense.

( Trying to avoid a full recovery, and to further understand the split between file indexes and media ).

Whe I backup the filer, I split the backup into two areas.

Part 1 is the actual data, ie the tapes I have run the scanner on.

Part 2 however are the indexes generated by the backup, which are saved to a tape attached to the backup server, as these indexes need to exist to allow a browse period to exist for filer backups.

So, if I run the following command;

nsrck -L7 -t "date" client

This should prompt for a volume written as part 2. So my question is, do I still need to blow away the existing records for this date, before appending this file info to the database ?

Explaination of my tortured thinking.

Currently when I run this command;

mminfo -v -q ssid=3769786113

size ssid fl lvl n
6620 MB 3769786113 hEN full

4665 MB 3769786113 tEN full

It tells me that the save set exists, and is spread over two
volumes. Do I need to blow this info away, using

nsrck -X -R -date 'date' client

to ensure that there are no records for this date before I run this command;


nsrck -L7 -t "date" client

Thanks.

ps. I know the short answer is try it, but its a production server, so I would like to be as informed as possible before I do so.

 

[605]

No you do not need to delete existing CFI data as this data is actually independent from each save set.

And the data in the media db (mminfo) does not change just due to the fact that you recover.