Recovering rman data from Networker

Have you restored the index files for the backups that you are trying to recover ?

Since this is backed up using NMO/NMDA you will not be able to restore the savesets usinng saveset recovery.

I suggest you restore the data using index, ensure that the file that backup file that you are trying to access is present in the backups. You could confirm this using nsrorainfo - if you are using NMDA or incase you had backed this up using NMO use nsrinfo to get the information on the files that were backed up under this saveset.

From what I see you have E state so I assume all backup pieces are expired.  You need to bring them back to be available for restore meaning extend browse and retention and then restore index before you can move on to RMAN restore.

What is your-f261187dc7?  Do you use DHCP?  If not, check DNS/hosts to make sure name resolution is in place.

Thanks for your responses.

As far as I know I have to mark saveset as notrecyclable before I can extend browse/retention times. When I tried to do that I got an error:

# /usr/sbin/nsr/nsrmm -S 1237518202/1704121005 -s bdlbackup -o notrecyclable

Mark save set copy 1237518202/1704121005 as not recyclable? y

Permission denied, user 'root' on 'sd1-bak' does not have 'Operate NetWorker' privilege to perform this operation.

The same error occurs for nsrinfo.

When trying to give administrator privileges to root@sd1-bak the following error occurs:

root@bdlbackup # nsraddadmin -u root@sd1-bak

39078:nsraddadmin: RAP error: Host name your-f261187dc7 is not valid

What does it mean?

In meanwhile I wanted to try recovery procedure on more current saveset.

nsrinfo -vV -s bdlbkp sdbkp

scanning client `sdbkp' for all savetimes from the backup namespace on server bdlbkp

0 objects found

nsrinfo -vV -n oracle -s bdlbkp sdbkp

scanning client `sdbkp' for all savetimes from the backup namespace on server bdlbkp

UNIX file `c-2891241567-20160126-03' size=55838552, off=0, app=oracle(25), date=1453810756 Tue Jan 26 13:19:16 2016, (unknown fid), file size = 0

...

scanning client `sdbkp' for all savetimes from the backup namespace on server bdlbkp

UNIX file `db_SDDB_213567_802561214' size=262328, off=0, app=oracle(25), date=1453426280 Fri Jan 22 05:18:00 2016, (unknown fid), file size = 0

...

Is seems RMAN backups are in index of oracle namespace.

Now when I try to do:

/usr/sbin/nsr/recover -s bdlbkp -x oracle

I got:

39584:recover: No files have been backed up for this client. No index was found on the server for the path / on this client.

I tried also:

/usr/sbin/nsr/recover -a -s bdlbkp -x oracle -d /tmp db_SDDB_213567_802561214

Nothing to recover

When I do:

/usr/sbin/nsr/recover -s bdlbkp

It works:

Current working directory is /

recover> ls

(it prints contents of / directory)

How to extract this RMAN backup from tape?

RMAN backup can only be restored by RMAN restore.  If you never did it, you are not DBA.  In that case I suggest you talk to DBAs - they can easily make RMAN restore script and run it.

That's the problem - RMAN is no longer aware about those backups existence.

An Oracle guy in my company suggested restoring them from tape to disk and then registering their copies on disk in RMAN catalog. That would allow RMAN restore from data on disk.

As far as I understand now:

* There is no way to do that (extract RMAN data from tape to disk without using RMAN, i.e. with networker commands alone).

* I have to extend browse/retention date of those backups, change their state to notrecyclable, and then restore online file index for those backups (by nsrck -L7 -t ...) . Then I can try to register them in RMAN catalog and perform RMAN recovery from tape. If that doesn't work there is nothing more I can do.

Is that correct?

Hi,

it is not possible to extend browse or retention policy of expired SSID. You have to load tape with needed SSID to drive and use command scanner for rebuild of media DB entries and indexes . See more details in man page of scanner command...

You will need to restore control file, which contains data about your needed backups. I hope that you have enabled autobackup of control file in your backup RMAN script.

Hello this is not true of course, you can do it always… Not sure with exact steps, but first of all you have to extend retention time, than set SS to recoverable state, than extend browse time??, than run nsrck –L7 which will reset all extended SS to browsable state. You always has to work with ssid/cloneid format when working with SS.

nsrmm –e 05302016 –S SSID/CLONEID – extend retention time

nsrmm –o notrecyclable –S SSID/cloneid

nsrmm –w 05302016 –S SSID/CLONEID – extend browse time – not sure if this step is possible

nsrck –t 30112015 –L7 client name – this has to be date close after index backup for backup you want to restore it will add old backup to you index databes – it is save…

regards

Lukas Slabihoudek

+420773748000

One more question then: is level 7 nsrck 'safe'? I.e. if I run it the current content of index will not be erased, modified or overwritten? (That's how I understand the documentation: 'Note that it will not overwrite existing files in the client file index', 'Note that recovering the index to a specific time adds the entire contents of the index as of that time to the current index contents'.)

Thanks for your help anyway.

tolejniczak wrote: One more question then: is level 7 nsrck 'safe'? I.e. if I run it the current content of index will not be erased, modified or overwritten? (That's how I understand the documentation: 'Note that it will not overwrite existing files in the client file index', 'Note that recovering the index to a specific time adds the entire contents of the index as of that time to the current index contents'.) Thanks for your help anyway.

It is safe.  Records are merged with existing ones.  If you check structure under index, you will notice under db6 structure that there is folder for each each day and is each folder then contains specific data for backup sets of that day.

OK, I managed to restore index, but I don't know how to make savesets browsable.

For each saveset I want to recover I did:

nsrmm -S 4513442715/1441523008 -s bdlbkp -e "03/03/2016"

nsrmm -S 4513442715/1441523008 -s bdlbkp -o notrecyclable

Then I restored index backup the same way.

Then I did:

nsrck -L7 -t 1441537800 sdbkp

It seems the index was successfully restored:

nsrinfo -vV -n all -s bdlbkp sdbkp

...

UNIX file `c-2254432831-20150906-01', size=21496640, off=0, app=oracle(25), date=1441523007 Sun Sep 06 09:03:27 2015, (unknown fid), file size=0

...

But the savesets from 6th september are still not browsable:

...

RS56LT        sdbkp        09/06/15 09:03:27  20 MB 4513442715 cr full RMAN:/home/scripts/sddb_backup.rcv

...

When I tried:

nsrmm -S 4513442715 -s bdlbkp -w "03/02/2016"

I got:

Cannot exceed the browse time of a recoverable save set 4513442715.

How to extend the browse time?

You can always check status of ssid via

mminfo -avot -q ssid= -r name,group,client,savetime,ssbrowse,ssretent,ssflags,sumflag

in your case I do not see what mminfo shows for ssretent value now.  I see that second value is not the same.  So, so far you did something similar to what I did here:

# mminfo -q family=tape -q ssrecycle -r ssid

569194131

3659836964

4072470046

# mminfo -q ssid=569194131 -r savetime,ssbrowse,ssretent,ssflags,sumflags,cloneid

  date    browse   retent  ssflags fl   clone id

09/07/15 12/07/15 12/07/15 vrEF  cE  1441609363

# nsrmm -o notrecyclable -y -S 569194131/1441609363

# nsrmm -e 01/29/16 -S 569194131/1441609363

If this saveset has dependents with longer retention periods, the dependent savesets will not be browsable after the retention policy expiration date `Fri Jan 29 00:00:00 2016'.

Are you sure you want to change the retention policy expiration of this saveset to `Fri Jan 29 00:00:00 2016'? (yes/no)  [no] yes

# mminfo -q ssid=569194131 -r savetime,ssbrowse,ssretent,ssflags,sumflags

  date    browse   retent  ssflags fl

09/07/15 12/07/15 01/29/16 vrF   cr

Now, nsrck -L7 will apply original policy to current date so I would suggest to set ssretent to some higher value (you can always get that adjusted later).  In my case I can't do nsrck -L7 because I do not have indices from this ssid and the only reason why I have it in mdb is because volume hasn't been relabeled yet.

if this won't get you anyway, and you are in rush and have no time to have someone take closer look, you can always removed ssid from mdb if this is on tape (take mminfo for it before including position on tape) and then run scanner on it. scanner will ask you about position and ssid and will bring back record as if policy has been applied today.  But in general, this will take much longer.

I'm not sure what you mean by 'nsrck -L7 will apply original policy to current date so I would suggest to set ssretent to some higher value'.

ssretent is set to 3rd March (it was set before nsrck):

name                          group          client       date    browse   retent  ssflags fl

RMAN:/home/scripts/sddb_backup.rcv sdora_sddb sdbkp 09/06/15 10/18/15 03/03/16 vrF cr

nsrck did not change browse date - originally this ssid looked like that:

ssid         clone id name                                total  date   volume         state   retent   browse

4513442715  1441523008 RMAN:/home/scripts/sddb_backup.rcv 20 MB 09/06/15 RS56LT E  11/29/15 10/18/15