Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Restoration is Failing when we try to restore files on an existing Filesystem

Created: 05 Mar 2013 | 11 comments
Varma Chiluvuri's picture

03/04/2013 14:13:05 - begin Restore
03/04/2013 14:13:10 - number of images required: 1
03/04/2013 14:13:10 - media needed: I00472
03/04/2013 14:13:41 - restoring from image sapf6sv-nb_1361895855
03/04/2013 14:13:42 - Info bpbrm (pid=17498174) sapf6sv-nb is the host to restore to
03/04/2013 14:13:42 - Info bpbrm (pid=17498174) telling media manager to start restore on client
03/04/2013 14:13:43 - Info bpbrm (pid=17498174) spawning a brm child process
03/04/2013 14:13:43 - Info bpbrm (pid=17498174) child pid: 15138998
03/04/2013 14:13:43 - connecting
03/04/2013 14:13:43 - Info bpbrm (pid=15138998) start tar on client
03/04/2013 14:13:44 - Info tar (pid=0) Restore started.
03/04/2013 14:13:44 - connected; connect time: 0:00:00
03/04/2013 14:13:44 - requesting resource I00472
03/04/2013 14:15:09 - started process bptm (pid=16056320)
03/04/2013 14:15:09 - mounting I00472
03/04/2013 14:15:09 - granted resource  I00472
03/04/2013 14:15:09 - granted resource  STK.T10000A.073
03/04/2013 14:15:10 - Info bptm (pid=16056320) INF - Waiting for mount of media id I00472 on server nbu-media-grv-nb for reading.
03/04/2013 14:15:48 - mounted I00472; mount time: 0:00:39
03/04/2013 14:15:48 - Info bptm (pid=16056320) I00472
03/04/2013 14:15:49 - positioning I00472 to file 18
03/04/2013 14:16:59 - positioned I00472; position time: 0:01:10
03/04/2013 14:16:59 - begin reading
03/04/2013 14:28:02 - Info tar (pid=0) done. status: 0
03/04/2013 14:28:02 - end reading; read time: 0:11:03
03/04/2013 14:28:02 - Info tar (pid=0) done. status: 5 - the restore failed to recover the requested files
03/04/2013 14:28:02 - Info bpbrm (pid=17498174) sending message to media manager: STOP RESTORE sapf6sv-nb_1361895855
03/04/2013 14:28:02 - Info bpbrm (pid=17498174) media manager for backup id sapf6sv-nb_1361895855 exited with status 0: the requested operation was successfully completed

03/04/2013 14:28:02 - restored from image sapf6sv-nb_1361895855; restore time: 0:14:21
03/04/2013 14:28:03 - Warning bprd (pid=38273254) Restore must be resumed prior to first image expiration on Thu May 30 12:24:15 EDT 2013
03/04/2013 14:28:03 - end Restore; elapsed time 0:14:58
Failed to get status code information (2850)

Operating Systems:

Comments 11 CommentsJump to latest comment

Varma Chiluvuri's picture

Restoration 1

I tried to restore files and directories from a OS full backup to /usr/sap/F6S.

Source : /usr/sap/F6S     Destination : /usr/sap/F6S    

I am getting the above error, the restoration size is 44226304 kb.

Restoration 2

After that I have changed the restoration destination to /varma which is empty.

Source : /usr/sap/F6S     Destination : /varma

Now the restoration without any errors and the status code is 0. But the size of the restoration is same as previous restoration 44226304 kb.

Can someone please help me to know why the Restoration 1 is throwing error ?

Does destination should be empty while restoring the files and directories ?

Thanks & Regards

Varma

RamNagalla's picture

hi,

could you post the restore log, that could give some more detail info about the error.

if you trigger restore from master server GUI , and did not chage the default resotre log. you can fidn the restore log in below path

/usr/openv/netbackup/logs/user_ops/<user id> /logs/<log file>

Varma Chiluvuri's picture

@Gautier I have restored the data to a empty filesystem using same tape and it completed successfully. I have selected fullbackup only.

@Nagalla /usr/sap/F6S has new files created after Feb 26th. I am trying to restore from F6b 26th Full OS backup, will this be an issue ?

Thanks & Regards

Varma

RamNagalla's picture

should not be a issue...

post the restore logs and also tar logs as suggested by Marianne.

Marianne's picture

In addition to restore log requested by Nagalla, we also need tar log on the client. If the tar log folder does not exist, please create it and retry restore to original folder.
Please post tar log (rename to tar.txt) as File attachment after the failure.

There is no problem with restoring to same filesystem, but what were your options with regards to overwrite?
Were any processes running using that filesystem? Hopefully the logs will tell us.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Mark_Solutions's picture

Looks like two possible issues here ..

1. What looks to be a timeout between wrting the files and getting acknowledgement (12 minutes) so maybe a client read / client connect timeout needs increasing

2. The first restore goes to the original location so presumably the original files are already there and need to be overwritten. This could take longer to do than simply writing to an empty location and hence the timeouts but also of note is that the directory structure is already there.

Why this is important is that a restore is based on two things, the size of the restore (are you have the same value for both in your example) but also the number of files to restore.

My guess is that the number of files restored in Restore 1 is less than that for Restore 2 - this is because it classes directories (folders) as files.

As the first does not have to create the folders then these are "skipped" and hence the possiblke status 1

If i am right you will find that the full restore logs shows that all of the "files" were restored but the "folders" were skipped - hence the same size of the restore but, again if i am right, a different number of what NetBackup calls "files"

Hope this makes some sort of sense!

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Varma Chiluvuri's picture

@Marianne I have selected overwrite option while restoring. I can't retry the restore because I have copied the files from the empty filesystem and we don't have approval to retry the restore.

@Mark Restore1 and Restore2 have same number of files and directories.

    Already timeout parameters in Media server are as below.

CLIENT_READ_TIMEOUT = 3000
CLIENT_CONNECT_TIMEOUT = 600

Thanks & Regards

Varma

Mark_Solutions's picture

Then we need to examine the tar / restore log file to see exactly what the first backup skipped or failed on if you can provide it please

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Burpythehippo's picture

I have found a very similar result if I am restoring to a user location, but during the process of the restore we hit the volume quota limit based on file ownership. 

Marianne's picture

Seems we will never now if any processes were running in original filesystem? Open files (running binaries) will probably not allow overwrite.

See if you can reproduce the problem. Do you still have the contents of the /varma folder?

If so, back it up, then restore back to same location. Check that tar log folder exists before you start the restore.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links