cancel
Showing results for 
Search instead for 
Did you mean: 

NBU 7.7.3, unable to restore flat file to Solaris Client NBU 7.5.0.5 when size show in KB

CHUNYONG
Level 3

Master servers - NBU 7.7.3, Windows 2008

Clients - NBU 7.5.0.5, Solaris 10 U8 

Upgraded the NBU master last week to 7.7.3 and NBU client stay 7.5.0.5. Perform the alternative restoration from source Solaris 10U8 NBU 7.5.0.5 to target Solaris 10U8 7.5.0.5 below are the few scenerio test I have perform:

1) Perform Standard restoration to Solaris 10U8 NBU version 7.5.0.5. Restore failed with Status 183, tar received an invalid archive
2) Perform Standard restoration to Solaris 10U8 NBU version 7.5.0.5 with exclude user01.dbf.Z. Restore successfully.
3) Perform Standard restoration to Solaris 10U11 NBU version 7.5.0.5 with restore user01.dbf.Z. Restore failed with Status 183, tar received an invalid archive
4) Perform Standard restoration to Solaris 10U11 NBU version 7.7.3 with restore user01.dbf.Z. Restore successfully.

I couldn't upgrade all the client to NBU 7.7.3 due to OS not compatible and need to work with application vendor.

I'm seeking the assist or idea to address this Restoration issue.

14 REPLIES 14

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Backup and restore to and from previous versions is perfectly supported. 

Do you have tar folder on destination client? 
Level 3 or higher.

 

rk1074
Level 6
Partner

do u have sufficeint space available on destination FS where u restoring

m assuming 3 servers involved here, 2on 7505 and 1 on 773

Attached the TAR logs.

We have enough sufficient space to perform the restoration.

Master Server = 7.7.3

Solaris 10U8 = 7.5.0.5

Solaris 10U11 = 1) installed with 7.5.0.5 and restoration failed. 

                          2) installed with 7.7.3 and restoration successful.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
I cannot view .log files on my mobile device (only .txt files). You may want to open the file and see if you can find a possible reason for the failure?

Below are the tar log in txt mode:

10:11:01 (223492.001) INF - TAR STARTED 20627
10:11:01 (223492.001) Setting network receive buffer size to 32032 bytes
10:13:53 (223492.001) CKP - 223492.001 1508984033 0 0 1 0 0 0 51 /oradata/databck/HOTbackup/POLICYDB/AUDIT_STG.dbf.Z
10:15:32 (223492.001) CKP - 223492.001 1508984132 0 0 151 2 0 0 59 /oradata/databck/HOTbackup/POLICYDB/1_26307_828593303.arc.Z
10:15:48 (223492.001) INF - TAR EXITING WITH STATUS = 0
10:15:48 (223492.001) INF - TAR RESTORED 4 OF 4 FILES SUCCESSFULLY
10:15:48 (223492.001) INF - TAR KEPT 0 EXISTING FILES
10:15:48 (223492.001) INF - TAR PARTIALLY RESTORED 0 FILES

10:18:47 (223493.001) INF - TAR STARTED 21634
10:18:47 (223493.001) Setting network receive buffer size to 32032 bytes
10:21:14 (223493.001) CKP - 223493.001 1508984474 0 0 2 1 0 0 59 /oradata/databck/HOTbackup/POLICYDB/1_26300_828593303.arc.Z
10:22:14 (223493.001) CKP - 223493.001 1508984534 1 736484 853884 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:23:14 (223493.001) CKP - 223493.001 1508984594 1 2119834 2237234 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:24:14 (223493.001) CKP - 223493.001 1508984654 1 3340743 3458143 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:25:14 (223493.001) CKP - 223493.001 1508984714 1 4615084 4732484 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:26:14 (223493.001) CKP - 223493.001 1508984774 1 5997339 6114739 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:27:14 (223493.001) CKP - 223493.001 1508984834 1 7379812 7497212 6 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z
10:27:57 (223493.001) ERR - Invalid TAR header found:
10:27:57 (223493.001) INF - 0: ` Ú  Œ B b < Ñ  5 $ — =   Ò
10:27:57 (223493.001) INF - 0: 60da 0e8c 4262 3cd1 8d35 2497 3d08 02d2
10:27:57 (223493.001) INF - 16:  Ž  T W Q ? ö K Ü   N ö K ò
10:27:57 (223493.001) INF - 16: 138e 0154 5751 3ff6 4bdc 1303 4ef6 4bf2
10:27:57 (223493.001) INF - 32: ^ q  à *
   H „   n D
10:27:57 (223493.001) INF - 32: 5e71 13e0 2a0a 1c03 1e48 841e 086e 4409
10:27:57 (223493.001) INF - 48:  Š  â A à  X -  ²  n 
10:27:57 (223493.001) INF - 48: 198a 15e2 41e0 0b07 582d 01b2 196e 010d
10:27:57 (223493.001) INF - 64: ]   Ô Ñ ' ” u - §   • ¸
10:27:57 (223493.001) INF - 64: 5d0d 0003 1ed4 d127 9475 2da7 1707 95b8
10:27:57 (223493.001) INF - 80: À º « à N Q ! @ ž r œ ¾ ¸ I ?
10:27:57 (223493.001) INF - 80: c0ba abc3 4e51 2140 9e72 9cbe b849 003f
10:27:57 (223493.001) INF - 96: l ·
 o œ é i ý E  ò ) è
10:27:57 (223493.001) INF - 96: 006c b70a 0006 6f9c e969 fd45 1bf2 29e8
10:27:57 (223493.001) INF - 112:  Ç  ± ! € H 7 ó Å 8 ` " þ T 
10:27:57 (223493.001) INF - 112: 04c7 05b1 2180 4837 f3c5 3860 22fe 5403
10:27:57 (223493.001) INF - 128:   c .  $ x ý G ° = ” ­ § 2
10:27:57 (223493.001) INF - 128: 0114 632e 1224 78fd 47b0 3d94 ada7 2032
10:27:57 (223493.001) INF - 144: Ó å å S ‹ ü ´ ã ¶ [  H 
 å
10:27:57 (223493.001) INF - 144: d3e5 e553 8bfc b4e3 b65b 1d48 160a 11e5
10:27:57 (223493.001) INF - 160: 2 U ý *   ! <  P  : 0 ) ã
10:27:57 (223493.001) INF - 160: 3255 fd2a 1602 213c 0150 001d 3a30 29e3
10:27:57 (223493.001) INF - 176: × Û Æ  q ‡  Î ò ¼ [  B ñ  
10:27:57 (223493.001) INF - 176: d7db c605 7187 1dce f2bc 5b14 42f1 0701
10:27:57 (223493.001) INF - 192: ‡ b B ­ O » 9 ! 4 ˜ ›   W ÿ Ü
10:27:57 (223493.001) INF - 192: 8762 42ad 4fbb 3921 3498 9b0c a057 ffdc
10:27:57 (223493.001) INF - 208: ¾ ç ð  þ s a ï ù
± I ? I
10:27:57 (223493.001) INF - 208: bee7 f012 fe73 61ef f90a b149 003f 0049
10:27:57 (223493.001) INF - 224: r
 ; E B
ù ó K b V Ä
10:27:57 (223493.001) INF - 224: 720a 0008 003b 0045 420a f9f3 4b62 56c4
10:27:57 (223493.001) INF - 240: J È â i s î  { L i   A F
10:27:57 (223493.001) INF - 240: 4ac8 e269 0073 0dee 1a7b 4c69 0e1e 4146
10:27:57 (223493.001) INF - 256: 4   æ ? 0  N  h  R I
: Å
10:27:57 (223493.001) INF - 256: 3403 1fe6 3f30 1d4e 1268 1352 490a 3ac5
10:27:57 (223493.001) INF - 272: g ã  X ½ û u é Â v ² b g  ›
10:27:57 (223493.001) INF - 272: 67e3 0658 bdfb 750d e9c2 76b2 6267 0e9b
10:27:57 (223493.001) INF - 288: 8 § ' „ À ´ x ò  Ù  ‹ õ }  Z
10:27:57 (223493.001) INF - 288: 38a7 2784 c0b4 78f2 10d9 198b f57d 135a
10:27:57 (223493.001) INF - 304: a 3 Ê . î c ö ;  8 4  S © æ Ñ
10:27:57 (223493.001) INF - 304: 6133 ca2e ee63 f63b 0438 3417 53a9 e6d1
10:27:57 (223493.001) INF - 320:    Ü U 7   . Ç µ U " Ï 
10:27:57 (223493.001) INF - 320: 1d18 8ddc 5537 0107 2ec7 b520 5522 cf1b
10:27:57 (223493.001) INF - 336: ÿ £ ó û  I ? ò r  ; E
10:27:57 (223493.001) INF - 336: ffa3 f3fb 0149 003f 00f2 7208 003b 0045
10:27:57 (223493.001) INF - 352: B
ù ó K b V Ä J È â i s î
10:27:57 (223493.001) INF - 352: 420a f9f3 4b62 56c4 4ac8 e269 0073 0dee
10:27:57 (223493.001) INF - 368:  { L i   A F 4   æ ? 0  N
10:27:57 (223493.001) INF - 368: 1a7b 4c69 0e1e 4146 3403 1fe6 3f30 1d4e
10:27:57 (223493.001) INF - 384:  h  R I
: Å g ã  X ½ û u
10:27:57 (223493.001) INF - 384: 1268 1352 490a 3ac5 67e3 0658 bdfb 750d
10:27:57 (223493.001) INF - 400: é Â v ² b g  › 8 § ' „ À ´ x ò
10:27:57 (223493.001) INF - 400: e9c2 76b2 6267 0e9b 38a7 2784 c0b4 78f2
10:27:57 (223493.001) INF - 416:  Ù  ‹ õ }  Z a 3 Ê . î c ö ;
10:27:57 (223493.001) INF - 416: 10d9 198b f57d 135a 6133 ca2e ee63 f63b
10:27:57 (223493.001) INF - 432:  8 4  S © æ Ñ    Ü U 7  
10:27:57 (223493.001) INF - 432: 0438 3417 53a9 e6d1 1d18 8ddc 5537 0107
10:27:57 (223493.001) INF - 448: . Ç µ U " Ï  ÿ £ ó û  I ?
10:27:57 (223493.001) INF - 448: 2ec7 b520 5522 cf1b ffa3 f3fb 0149 003f
10:27:57 (223493.001) INF - 464: 3 }  ; E B
ù ó K b V Ä
10:27:57 (223493.001) INF - 464: 0033 7d08 003b 0045 420a f9f3 4b62 56c4
10:27:57 (223493.001) INF - 480: J È â i s î  { L i   A F
10:27:57 (223493.001) INF - 480: 4ac8 e269 0073 0dee 1a7b 4c69 0e1e 4146
10:27:57 (223493.001) INF - 496: 4   æ ? 0  N  h  R I
: Å
10:27:57 (223493.001) INF - 496: 3403 1fe6 3f30 1d4e 1268 1352 490a 3ac5
10:28:01 (223493.001) INF - TAR EXITING WITH STATUS = 3
10:28:01 (223493.001) INF - TAR RESTORED 7 OF 7 FILES SUCCESSFULLY
10:28:01 (223493.001) INF - TAR KEPT 0 EXISTING FILES
10:28:01 (223493.001) INF - TAR PARTIALLY RESTORED 0 FILES

10:33:32 (223494.001) INF - TAR STARTED 23448
10:33:32 (223494.001) Setting network receive buffer size to 32032 bytes
10:36:25 (223494.001) CKP - 223494.001 1508985385 0 0 1 0 0 0 49 /oradata/databck/HOTbackup/POLICYDB/users01.dbf.Z

are the "tar" versions the same in both destination servers?

also check if the "zip/unzip" versions are same also or whatever uncompression tool you use.

mph999
Level 6
Employee Accredited

So, in summary - file user01.dbf.Z backed up with 7.5.0.5 cannot be restored by 7.5.0.5 but can by 7.7.3  - odd, if anything I'd expect the failure to be with 7.7.3, but hey ho ....

So, not having the a test machine to hand to comapre with, but looking at the tar log, that kinda looks corrupt.

10:27:57 (223493.001) INF - 64: ]   Ô Ñ ' ” u - §   • ¸

You explained the file restored at 7.7.3, that's great of course, but did you try opening it, is it 'useable'.

I don't have any easy answers for this, at first glance it looks like some sort of incompatability with the file - but that 7.7.3 was able to overcome it (if we presume for the moment the 7.7.3 restored file is useable).  My justification for this commet it that the file restored with no change other than the NBU client version.

That said, I did see something simliar recently with a tape backup that was failing.  I can't remember the exactly solution, but it was OS settings on the media server (kernel tuning I think, but can't remember which settings, but it was Linux).  The reason I mention this, is that the volumgr daemon log showed lines a bit similar to what I've highlighted in your tar log.  Turns out that the OS settings was causing the shared memory (where the data is sent before being sent to the tape drive) was getting corrupted.

I wonder if something similar is happening here - sure, the restore works at client 7.7.3, but is that a physically different client - I guess so as you stated you couldn't upgrade the original client.  So - if different client, although the main change looks like the NBU version, it's also well, a diffeernt client so possibly different OS settings and so on.  bptm sends the data from disk/ tape to shared memory before it is passed to the tar process - could that shard memory be getting corrupted I wonder.

Why is only one file failing, who knows, but that reminds me of another issue my colleague had - backup of a certain file was always failing.  It turned out (eventually) that the clients NIC had a firmware issue and it was rejecting that particular file (which in that case was a tar file).  Every other file worked, it just didn;t like one particular file for some reason.

I struggling to think of a way to investigate this - I'm thinking a truss output from a failing restore compared against the truss output from a working restore.

The other issue is that 7.5 is well out of support, so the solution to this, although not great, is probably going to be, use a 7.7.3 system  as and alternate resore, and copy to the cient.

 

We have tried to perform the different set backup copies and it's are not working for Solaris 10U8 client.

We have test perform restore to Windows client with Standard restoration although is not the best practices. The same copy are restore successfully to NBU version 7.5.0.5 and NBU version 7.7.3.

Hence I would like to know is there the NBU 7.7.3 have the different TAR extension to different OS platform or limitation?

even on same solaris installations, if the admin is not careful there'd be different versions of tools like "tar" and "zip/unzip" specially. that's why i ask if the versions are the same on all your solaris hosts. some versions of "zip/unzip" cannot unzip files greater than 2GB.

mph999
Level 6
Employee Accredited

tar changed at 7.7.3 to 'nbtar' (ie. the name of the actual bnary changed) and this contained som echanges to how tar works.

From your last note:

File restores at 7.7.3 on solaris but not at 7.5.0.5

File restores at 7.7.3 and at 7.5.0.5 if Windows client is used.

.... So, 7.5.0.5 can restore the file, just not on your Solaris box ....

The 7.5.0.5 tar file on Solaris is the same code as the 7.5.0.5 tar file on Windows ...

I'm thinking that this may be starting to point a bit more towards an OS setting issue than NBU itself, given that 7.5.0.5 can restore it (on windows), and the tar code is the same.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

I am very curious to know why this method is used to back up databases as opposed to a 1-step backup and 1-step restore using the appropriate NBU agent ? 

I have perform additional restore test for few version:

1) Restore user01.dbf.Z from Tape to Solaris client version 7.7.3 - restore successfully.

2) Restore user01.dbf.Z from Tape to Solaris client version 7.5.0.5 - restore FAILED.

3) Restore user01.dbf.Z from VTL to Solaris client version 7.5.0.5 - restore successfully.

4) Restore user01.dbf.Z from Data Domain to Solaris client version 7.5.0.5 - restore successfully.

Wondering is the restoration of TAR extension are different from Tape, VTL and Data Domain?

mph999
Level 6
Employee Accredited

That is interesting ....

1) Restore user01.dbf.Z from Tape to Solaris client version 7.7.3 - restore successfully.

3) Restore user01.dbf.Z from VTL to Solaris client version 7.5.0.5 - restore successfully.

4) Restore user01.dbf.Z from Data Domain to Solaris client version 7.5.0.5 - restore successfully.

But ...

2) Restore user01.dbf.Z from Tape to Solaris client version 7.5.0.5 - restore FAILED.

For (2) that fails and (3) that worked, was it the same physical Solaris box ?

I'm still thinking about this 'corrupt shared memory'  - it's very similiar to the previus case I worked on.  Interestingly, with that previous case (although it was a backup) the issue only happened on LTO6 drives, other LTO drive generations worked.  The only reason I mention this, is to demonstrate that you can get strange behavior betweening seemingly simliar storage devices.  In your case, VTL and physical tape are (from NetBackups view) the same (NBU thinks a VTL is real tape), yet we see different behavior.

mph999
Level 6
Employee Accredited

To answer this ...

Wondering is the restoration of TAR extension are different from Tape, VTL and Data Domain?

Shouldn't be - it will be the same scsi command sent to read the data for the VTL and the real physical drive.