Unable to change recoverable saveset into browsable

Gregoire_Perrenoud,

Unfortunately for NDMP backups scanner does not generate the index files for the respective saveset. and Since you dont have the index backups the nsrck -L7 is pretty much useless.

  You might have to go for a saveset restore.

I don't get you guys... We are doing NDMP Backup on a Data Domain Device 8non NDMP Device), and we have an index for these Backup. In my case, we don't have an index anymore cause the saveset is too old...

I m loosing myself

Greg

NDMP backups are not so easy - I personally have not touched it for years (but I am about to dig into it again).

So my last experiences data back to NW 7.6.x

What you achieve depends on a lot of issues like ...

  -  the NDMP capabilites on the filer

  -  which NDMP version is in use (you may even select that for compatibility reasons

  -  NDMP support capabilities of the backup software

  -  the backup options you have setup in NW of the NDMP client

Just to name the major ones.

So without knowing your exact configuration we just can guess what restore capabilities are available for your specific NDMP client. That's why I must be so generic.

It is the nature of NDMP not to even generate an index. Such is an additional step at the end of the backup process.

Also, NDMP uses its own data format with no embedded CFI info. This is why scanner will not work.

To avoid such problems in the future you may want to consider DSA (Data Service Agent) which has been available for NetWorker for about 10 years. It 'converts' the NDMP data stream in a way that it is compatible with any other NetWorker save stream.

Just to name some benefits:

  -  Backup to any NW device (not just a NDMP device)

        B2D is possible

  -  Mix NW and NDMP save sets on the same media

  -  Multiple save streams

  -  Cloning works the same way (nsrclone instead of nsrndmp_clone)

  -  Embedded metadata (scanner is possible)

And it is for free. Try it. No extra software to install - just one more option to the backup command.

Hello Wallace,

Backup Command: nsrndmp_save -M -T dump -P [Storage Node]

Application information: DIRECT=y; HIST=y; DSA=y; UPDATE=y; SNAPSURE=y

mminfo -avot -q ssid=xxxxx

mminfo -avot -q ssid=XXX -p

nsrck -L7 -t 03/06/18 [client Name]

nsrck: checking index for '[client Name]'

9343:nsrck: The file index for client '[client Name]' will be recovered.9433:nsrck: Recovering index savesets of '[client Name]' from '[Networker Server]'

Recover start time: 04/06/18 2:28:56 PM

Requesting 2 recover session(s) from server.

Recover completion time: 04/06/18 2:30:13 PM

I have selected 03/06/18 cause i don't find a date closer from my ssid save time

Hope it will help you to help me :-)

Cheers

Greg

Hi Bingo,

we have try that with scanner -i -S SSID, but unfortunately, it seem that scanner cannot be used with NDMP backup

Side 347 of Administration guide

Is that what you mean?

Greg

  -  "nsrndmpsave ... -M ..." in fact indicates that you use DSA

  -  "DSA=y" also indicates that

  -  the save set flags "Ns" tell you that this is an NDMP backup 'wrapped' by DSA.

So I assume that you need to recover ssid 2085148985.

Instead of recovering the CFI backups, why don't you just scan that specific save set?

Hello Greg...

Thank you for that information.  What concerns me is the elapsed time between the index backup in 4/28/17 (level full), then next one is a level=9 on 3/6/18.   Where are the index backups between 4/28/17 and 3/6/18?

From this output:

mminfo -avot -q ssid=xxxxx

volume  type   client      date time    size ssid fl   lvl name

FSGIA.01 Data Domain [client name] 12/31/17 1:33:00 PM 7399 GB 2085148985 crNs  full  [Name]

mminfo -avot -q ssid=XXX -p

  date browse   retent ssid client name                      vm_name

12/31/17 01/31/18 10/03/18 2085148985 [client Name] [Saveset name]

This tells us that the backup for this  ssid=2085148985  would have been browsable between 12/31/17 and 01/31/18, and that the client's CFI would have contained the browsable info during this time.  This again is assuming that the index metadata was committed to the CFI during backups.

To try and make ssid=2085148985 browsable again, we needed to find and recover any index backup for this client between 12/31/17 and 01/31/18.  Unfortunately your mminfo output of the index backups shows that there are none. So using nsrck -L7 to recover an existing index will not make the saveset browsable.

Therefore, your only recourse now is to perform a saveset recovery, using the nsrndmp_recover command

Gregoire_Perrenoud,

You are correct, the information on the screenshot is what I am referring to,

> nsrndmp_save -M -T dump -P [Storage Node]

This backup command shows that:

1. -M : you are backing up to a non NDMP device...  i.e.  the Data Domain device
2. -P : you are using a proxy host that will run the actual nsrndmp_save command.  This is described as "immediate save".  See NetWorker NDMP User Guide for further details.

> FSGIA.01 Data Domain [client name] 12/31/17 1:33:00 PM 7399 GB 2085148985 crNs  full  [Name]

> the save set flags "Ns" tell you that this is an NDMP backup 'wrapped' by DSA.

Actually   The save set flags :

     - N : this is a NDMP backup
     - s : indicates whether an NDMP save set was backed up, via nsrndmp_save, to a NetWorker storage node device

The storage node is the s/n that is specified in the backup command at time of backup.

Hi Greg,

with NW you must be very careful with the terms and terminology. This is especially true for the scanner command.

Actually scanner has at least 2 funtionalities:

  -  Extracting the metadata from a save set/volume

  -  Restoring the data itself (scanner -S | uasm -rv).

       Nobody would really use such command (today) if not absolute necessary.

       Here is the appropriate part of Legato's Technical Bulletin 0001 (even before NDMP appeared):

The obvious consequences are:

  -  you cannot do the restore (as the doc mentions, because data is still in NDMP format)

  -  but you should be able to retrieve the metadata.

As I said, NDMP can be tricky.

And do not forget that you must run scanner on the storage node which controls the device.

But you are lucky - I even have my old doc with me which I wrote 11 years ago. Here you can see that a "scanner -m" is possible on a disk device (FTD in this case), containing both, NDMP and non-NDMP backups (for example the NW 'bootstrap' SS). And yes, this is allowed but not best practice due to the limitations below:

C:\>scanner -nmv Z:\BU_DEV1

scanner: Reading the file label

scanner: scanning file disk best2003_disk.001 on Z:\BU_DEV1

scanner: volume id 4054732398 record size 32768

  created  1/17/07 17:27:26 expires  1/16/09 17:27:26

scanner: file disk best2003_disk.001 already exists in the media index

scanner: scanning file 4021178525, record 0

scanner: ssid 4021178525: found beginning of netapp:/vol/test/windows

scanner: scanning file 4021178525, record 100

scanner: scanning file 4021178525, record 200

scanner: scanning file 4021178525, record 300

scanner: scanning file 4021178525, record 400

scanner: scanning file 4021178525, record 500

scanner: scanning file 4021178525, record 600

scanner: scanning file 4021178525, record 700

  .....

scanner: scanning file 4021178525, record 31100

scanner: scanning file 4021178525, record 31200

scanner: scanning file 4021178525, record 31300

scanner: scanning file 4021178525, record 31400

scanner: scanning file 4021178525, record 31500

scanner: scanning file 4021178525, record 31600

scanner: scanning file 4021178525, record 31700

scanner: ssid 4021178525: scan complete

scanner: ssid 4021178525: 1009 MB, 10001 file(s)

scanner: scanning file 4004401519, record 0

scanner: ssid 4004401519: found beginning of best2003:  //

  index:a9165a08-00000004-45adff55-45ae1516-00020000-c3d64b66

scanner: ssid 4004401519: 1125 KB, 1 file(s)

scanner: ssid 4004401519: scan complete

scanner: ssid 4004401519: 1126 KB, 4 file(s)

scanner: scanning file 3987624419, record 0

scanner: ssid 3987624419: found beginning of best2003:bootstrap

scanner: ssid 3987624419: scan complete

scanner: ssid 3987624419: 195 KB, 250 file(s)

scanner: done with file disk best2003_disk.001

C:\>

Unfortunately, "scanner -i" is NOT possible - sorry for setting wrong expectations:

C:\>scanner -niv Z:\BU_DEV1

scanner: Reading the file label

scanner: scanning file disk best2003_disk.001 on Z:\BU_DEV1

scanner: volume id 4054732398 record size 32768

  created  1/17/07 17:27:26 expires  1/16/09 17:27:26

scanner: file disk best2003_disk.001 already exists in the media index

scanner: scanning file 4021178525, record 0

scanner: ssid 4021178525: found beginning of netapp:/vol/test/windows

scanner: save_xdr: bad magic number 0x45ae48f7scanner: resynchronizing ...scanner: scanning file 4021178525, record 100

scanner: scanning file 4021178525, record 200

scanner: scanning file 4021178525, record 300

scanner: scanning file 4021178525, record 400

scanner: scanning file 4021178525, record 500

scanner: scanning file 4021178525, record 600

scanner: scanning file 4021178525, record 700

scanner: scanning file 4021178525, record 800

scanner: scanning file 4021178525, record 900

scanner: scanning file 4021178525, record 1000

scanner: scanning file 4021178525, record 1100

  .....

scanner: scanning file 4021178525, record 31000

scanner: scanning file 4021178525, record 31100

scanner: scanning file 4021178525, record 31200

scanner: scanning file 4021178525, record 31300

scanner: scanning file 4021178525, record 31400

scanner: scanning file 4021178525, record 31500

scanner: scanning file 4021178525, record 31600

scanner: scanning file 4021178525, record 31700

scanner: ssid 4021178525: scan complete

scanner: ssid 4021178525: 1009 MB, 10001 file(s)

scanner: couldn't decode magic variable

scanner: (ssid 4021178525) error decoding save stream

scanner: (ssid 4021178525) would have added 0 new file index entries

scanner: scanning file 4004401519, record 0

scanner: ssid 4004401519: found beginning of best2003:index:a9165a08-00000004-45adff55-45ae1516-00020000-c3d64b66

scanner: ssid 4004401519: 1125 KB, 1 file(s)

scanner: ssid 4004401519: scan complete

scanner: ssid 4004401519: 1126 KB, 4 file(s)

scanner: scanning file 3987624419, record 0

scanner: ssid 3987624419: found beginning of best2003:bootstrap

scanner: ssid 3987624419: scan complete

scanner: ssid 3987624419: 195 KB, 250 file(s)

scanner: done with file disk best2003_disk.001

C:\>

Thinking about it, the reason is obvious: NDMP still controls the format of the backed up data but NetWorker reads OFT (Open Tape Format). Sorry for the confusion - mea maxima culpa.

So if you cannot get the file index back for whatever reason - restore the save set to a temp location and get your files from here. In your case it is most likely the the easiest method.

And do not forget: "NDMP backups can be tricky."

Thanks everybody for these very complete answers.

We have now changed our retention time for backup of index to have the same retention time time as for the backup of the client himself and everything should be fine now.

Thanks again to all.

Cheers.

Greg