Forum Discussion

bonovox73's avatar
bonovox73
Level 4
13 years ago

Problem with restore files after upgrade 7.5.0.1

Hi everyone,

After upgrade to 7.5.0.1 of my nbu environment I have problems to restore files.

Restore job terminate immediately and nothing done.

I collected all log:

From NBU admin console, job status:

10/05/2012 14:01:44 - begin Restore
10/05/2012 14:01:46 - restoring image GFILES1_1336269706
10/05/2012 14:01:46 - Info bprd(pid=3660) Restoring from copy 1 of image created 05/06/12 04:01:46    
10/05/2012 14:01:46 - requesting resource @aaaal
10/05/2012 14:01:46 - granted resource MediaID=@aaaal;DiskVolume=PureDiskVolume;DiskPool=arcadia_DP;Path=PureDiskVolume;StorageServer=arcadia;MediaServer=arcadia
10/05/2012 14:01:52 - end Restore; elapsed time: 00:00:08
VMware policy restore error(2820)

From BAR status:

14:01:44 10/05/2012: Restore Started

14:01:46 (138040.001) Restoring from copy 1 of image created 06/05/2012 04:01:46
14:01:52 (138040.001) Status of restore from copy 1 of image created 06/05/2012 04:01:46 = database system error

14:01:52 (138040.001) The following files/folders were not restored:
14:01:52 (138040.001) UTF - /K/Public/TECNOV/FM/comando.txt

14:01:52 (138040.xxx) INF - Status = VMware policy restore error.

From bprd log:

[...]

14:01:47.649 [3660.4392] <2> bpcr_get_platform_rqst: Server platform length = 7
14:01:47.649 [3660.4392] <4> get_destination_platform: received destenation platform = win_x64
14:01:47.649 [3660.4392] <4> bprd.sfr: sfr: using tmproot=C:\Program Files\Veritas\NetBackup/SFR_TMPDIR
14:01:47.649 [3660.4392] <4> bprd.sfr: sfr: using vm_opts=0(0)
14:01:47.649 [3660.4392] <2> ConnectionCache::connectAndCache: Acquiring new connection for host sirio, query type 79
14:01:47.664 [3660.4392] <2> logconnections: BPDBM CONNECT FROM 192.168.212.3.50568 TO 192.168.212.3.13721 fd = 856
14:01:47.664 [3660.4392] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:871] Ignoring VxSS authentication 2 0x2
14:01:49.836 [3660.4392] <2> get_long_base: (1) cannot read (byte 1) from network: An existing connection was forcibly closed by the remote host.
14:01:49.836 [3660.4392] <2> db_FLISTreceive: get_adaptable_string() failed: network read error. Errno = 10054: An existing connection was forcibly closed by the remote host.
14:01:49.836 [3660.4392] <4> bprd.sfr: get_rplist: expect receive buffer to be empty, however status was: socket read failed 23
14:01:49.836 [3660.4392] <2> ConnectionCache::connectAndCache: Acquiring new connection for host sirio, query type 79
14:01:49.852 [3660.4392] <2> logconnections: BPDBM CONNECT FROM 192.168.212.3.50569 TO 192.168.212.3.13721 fd = 856
14:01:49.852 [3660.4392] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:871] Ignoring VxSS authentication 2 0x2
14:01:52.024 [3660.4392] <2> get_long_base: (1) cannot read (byte 1) from network: An existing connection was forcibly closed by the remote host.
14:01:52.024 [3660.4392] <2> db_FLISTreceive: get_adaptable_string() failed: network read error. Errno = 10054: An existing connection was forcibly closed by the remote host.
14:01:52.024 [3660.4392] <16> bprd.sfr: dbm_cleanup: unexpected return value from db_FLISTreceive: socket read failed 23
14:01:52.024 [3660.4392] <32> bprd.sfr: get_rawp: couldn't get rplist
14:01:52.040 [3660.4392] <16> bprd.sfr: sfr: aborting entire restore:  error 220
14:01:52.040 [3660.4392] <4> bprd.sfr: sfr: Reached done, error: 220
14:01:52.040 [3660.4392] <2> jmcomm_ReleaseAllResourcesForJob: releaseAllResources returns [0]
14:01:52.040 [3660.4392] <2> jmcomm_ReleaseAllResourcesForJob: returning
14:01:52.040 [3660.4392] <2> restorefiles: Last attempt to restore from image = GFILES1_1336269706 failed (browse_client = gfiles1 destination_client = gfiles1 requesting_client = sirio user = root): database system error
14:01:52.040 [3660.4392] <2> mail_msg_and_set_exit_status: entered; status = 0
14:01:52.040 [3660.4392] <2> mail_msg_and_set_exit_status: client_type = 40
14:01:52.040 [3660.4392] <2> mail_msg_and_set_exit_status: Attempting to send mail to root on sirio
14:01:52.040 [3660.4392] <2> logconnections: BPCD CONNECT FROM 192.168.212.3.50570 TO 192.168.212.3.13782 fd = 500
14:01:52.087 [3660.4392] <2> mail_msg_and_set_exit_status: CLIENT_CMD_SOCK from bpcr = 500
14:01:52.087 [3660.4392] <2> mail_msg_and_set_exit_status: CLIENT_STAT_SOCK from bpcr = 856
14:01:52.087 [3660.4392] <2> bpcr_get_version_rqst: bpcd version: 07500000
14:01:52.087 [3660.4392] <2> bpcr_get_version_rqst: bpcd version: 07500000
14:01:52.087 [3660.4392] <2> bpcr_get_version_rqst: bpcd version: 07500000
14:01:52.102 [3660.4392] <2> mail_msg_and_set_exit_status: RESTORE EXIT STATUS = 2820
14:01:52.102 [3660.4392] <2> logconnections: BPCD CONNECT FROM 192.168.212.3.50572 TO 192.168.212.3.13782 fd = 856
14:01:52.165 [3660.4392] <2> job_monitoring_exex: ACK disconnect
14:01:52.165 [3660.4392] <2> job_disconnect: Disconnected

[...]

And finally, from administrative events of my master server, every time that I try to do a restore and it fails, is logged this message:

Faulting application bpdbm.exe, version 7.500.112.330, time stamp 0x4f769cac, faulting module MSVCR100.dll, version 10.0.40219.1, time stamp 0x4d5f034a, exception code 0x40000015, fault offset 0x00000000000761c9, process id 0x618, application start time 0x01cd2ea4ad0ddc9f.

All policies of backup ar VMware type and before upgrade restores worked properely

Anyone has my same problem?

Also any kind of help is welcome

Thanks

Christian

  • This is a VERY recently discovered defect in 7.5.0.1 (Etrack 2769869) which is having trouble handling a difference in case sensitivity between the hostname used in image name (from your logs, looks like "GFILES1") and the hostname you MIGHT be using in the policy (I will guess "gfiles1?")

    Change the client name to match the image - GFILES1 - and it should work.

    (This will be fixed in the next maintenance release.)

    TechNote to come!

4 Replies

  • This is a VERY recently discovered defect in 7.5.0.1 (Etrack 2769869) which is having trouble handling a difference in case sensitivity between the hostname used in image name (from your logs, looks like "GFILES1") and the hostname you MIGHT be using in the policy (I will guess "gfiles1?")

    Change the client name to match the image - GFILES1 - and it should work.

    (This will be fixed in the next maintenance release.)

    TechNote to come!

  • Thanks a lot Chris,

    I tried to use GFILES1 instead gfiles1 and the restore is terminated succesfully.