cancel
Showing results for 
Search instead for 
Did you mean: 

bprestore doesn't rename restored file

MisterX
Level 3

Hello

I've been banging my head on this one yesterday. Im on W2K8R2 using NBU 7.5.06, im restoring files that were renamed/changed paths to their new paths. I have hundreds of these, hence the need to script this.

Im restoring UNC paths from the media server. Restoring any file over an old file without path change works no problem. When using the rename file, the restore works well but the rename file process just will not work. When using the rename file, i see the old path file restored but the new path retains the old file. I've tried deleting the new path file before the restore but doesn't change a thing - the file is still restored to the old path.

Im sure i have a CR after each line for both -f file and -R file, the proper case for each character is respected (otherwise it wont restore but i can restore a file, just not rename it). I see in the log that the file is restored but no error concerning why the file is not renamed/changed (and i have the proper rights on the files).

My command line is


bprestore -C <mediaserver> -L e:\restorelog.txt -en -R e:\restoreTolist.txt -f e:\restore_list.txt

I tried both methods for the rename file using 

change /\\UNCfilepath to /\\UNCnewfilepath<CR>

or

rename <size> UNColdpath <size> UNCnewpath<CR>

Can anyone help? I read ALL the articled concerning this, the manual 5 times, tried everything and cannot figure it out.

I edited the server names, ip, and file path with <UPCASEString>

Tar log

9:08:08.260 AM: [170020.215980] <8> T_tar_rename::BMRApply: Cleaning up the BMR IDRInProgress and IDRSystemData config entries.
9:08:08.260 AM: [170020.215980] <2> tar_base::V_Close: closing...
9:08:08.260 AM: [170020.215980] <8> T_tar_rename::BMRApply: Cleaning up the BMR IDRInProgress and IDRSystemData config entries.
9:08:08.261 AM: [170020.125744] <2> ov_log::V_GlobalLog: INF - BEDS_Term(): enter - InitFlags:0x00000001
9:08:08.265 AM: [170020.215980] <8> T_tar_rename::BMRApply: Cleaning up the BMR IDRInProgress and IDRSystemData config entries.
9:08:08.265 AM: [170020.215980] <8> T_tar_rename::BMRApply: Cleaning up the BMR IDRInProgress and IDRSystemData config entries.

bprestore log

09:04:18.412 [68752.52716] <2> logparams: -C <mediaserver> -L e:\restorelog.txt -en -f e:\restore_list.txt -R e:\restoreTolist.txt
09:04:18.416 [68752.52716] <2> OV_SendProcessInfo2BPCD: Information - thread access token does not exist
09:04:18.416 [68752.52716] <2> OV_SendProcessInfo2BPCD: Information - About to write 7722 bytes to named pipe
09:04:18.563 [68752.52716] <2> OV_SendProcessInfo2BPCD: Information - successfully wrote information to named pipe
09:04:18.566 [68752.52716] <2> logconnections: BPRD CONNECT FROM <IP> TO <IP> fd = 432
09:04:18.566 [68752.52716] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:871] Ignoring VxSS authentication 2 0x2
09:04:18.709 [68752.52716] <2> bprestore: (utf8_client_type) before MultiByteToWideChar ><OLDPATH><
09:04:18.709 [68752.52716] <2> bprestore: after  OVNameUnicode2UTF >/<OLDPATH><

Restore log


09:05:03 (233399.001) Restoring from copy 1 of image created 10/4/2014 11:57:04 AM
09:05:08 (233399.001) INF - If Media id 2031JC is not in a robotic library administrative interaction may be required to satisfy this mount request.
09:05:12 (233399.001) INF - TAR STARTED 170020
09:06:34 (233399.001) INF - Waiting for mount of media id 2031JC on server <MEDIASRV> for reading.
09:06:59 (233399.001) INF - Waiting for positioning of media id 2031JC on server <MEDIASRV> for reading.
09:08:04 (233399.001) INF - Beginning restore from server munch3.oa.pnrad.net to client <MASTERSRV>.
09:08:07 (233399.001) TAR - <OLDPATH>
09:08:08 (233399.001) INF - TAR EXITING WITH STATUS = 0
09:08:08 (233399.001) INF - TAR RESTORED 1 OF 1 FILES SUCCESSFULLY
09:08:08 (233399.001) INF - TAR KEPT 0 EXISTING FILES
09:08:08 (233399.001) INF - TAR PARTIALLY RESTORED 0 FILES
09:08:08 (233399.001) Status of restore from copy 1 of image created 10/4/2014 11:57:04 AM = the requested operation was successfully completed

09:08:09 (233399.xxx) INF - Status = the requested operation was successfully completed.

 

Thanks in advance for any clue!

2 REPLIES 2

sdo
Moderator
Moderator
Partner    VIP    Certified

Do you have a Linux/Unix box that you can test the same contructs on?  Does it work on there?  If so, maybe your issue is because Windows tends to place <CR><LF> in text files.  Try finding a utility that will replace <CR><LF> with just <LF> - I think I saw some tools once, called "dos2unix" and "unix2dos" - which do this.

MisterX
Level 3

I checked my files and indeed i had a linefeed - my bad because the IDE i use converts CR's to CRLF when files are saved on win32 platforms (fixed). I removed them from the two files, tried again my restore manually and still no go, only the old file is restored to it's original location.

Kind of lame not to accept line breaks of one or the other platform... But so be it...