05-28-2019 11:35 AM
Hi, I hope you can help me, I'm having a problem with Veritas 6.5.6 x64, the master server and the media server is the same and runs Windows 10 64bit,
Clients run 64bit Windows 2008r2, since they function as storage.
When I try to restore LTO3 tapes to clients, it returns the error, tar received an invalid archive ...
only happens with LTO3 tapes, the LTO5 tapes the restoration ends successfully.
I attach the customer's TAR and BPTM server records
a separate comment, before the master server and the media server ran on windows XP and the clients on Solaris, the policies are created in standard Today we are trying to update at least the operating systems, keeping the same veritas version, even if it is very old.
I hope you can help me
05-28-2019 01:39 PM
Why are you still running such an old version?
You will be hard pressed to get answers when your version is so out of date and you are using unsupported OS's for Master/media servers. To this day, even on current software like 8.1.1, I don't believe Windows 10 is supported for Master/Media use.
05-29-2019 12:43 AM
Hello,
I agree that NetBackup Master/Media have never been supported on desktop OSes, and also that 6.5 version is very old. However here the problem is somewhere else. Considering that LTO5 tape has been mounted and read successfully, I guess that your LTO3 tapes are very old and haven't been written/read for a long time - thus they are unreadable now. See the message in the tar log:
03:23:25.415 p.m.: [2020.2416] <16> UnpackerTAR::readHeader(): ERR - Corrupt header encountered. Checksum verification failed for LF = (159)
03:23:25.415 p.m.: [2020.2416] <16> UnpackerTAR::readHeader(): ERR - CorruptTarHdrException: Checksum verification failed.
Try another image on your LTO3 or another LTO3 tape if you are able to read/restore them.
Regards
Michal
05-29-2019 12:57 AM
I am confused - Windows 10 was never supported by any 6.x version and Windows XP was only supported as NBU client.
NBU 6.x SCL : https://download.veritas.com/resources/content/live/SOLUTIONS/70000/TECH70729/en_US/nbu_6x_OS_scl_20...
Windows 10 is supported as from NBU 7.x as NBU Client only.
About the restore - it seems that you are trying to restore Unix files to the Windows master?
Although this 'may' work, this is not supported by NetBackup.
Can you tell us why the timestamps are different in bptm amd tar logs?
bptm: 18:55:54
tar: 03:21:32.393 p.m.
Are these from different restore attempts?
Anyway - I see these errors in tar log:
03:23:25.415 p.m.: [2020.2416] <16> UnpackerTAR::readHeader(): ERR - Corrupt header encountered. Checksum verification failed for LF = (159)
03:23:25.415 p.m.: [2020.2416] <16> UnpackerTAR::readHeader(): ERR - CorruptTarHdrException: Checksum verification failed.
Were original backups encrypted?
05-30-2019 11:39 AM
Before anything I thank you for your answer, I tell you that a newer version is not updated due to money issues in the company where I work.
Previously the architecture was:
Master Server / Windows XP Media, from there backups and restore were made.
The clients were on Solaris.
As here we do not have much knowledge in solaris but in windows, we try to update at least the S.O.
The LTO3 tapes work if I restore the same tape but to a Solaris client, but not if I try it with a Windows client, it throws me the error that I mentioned before.
What strikes me is that LTO5 tapes if you restore them without problems in windows clients.
Regarding encryption, I'm not aware that they are encrypted.
I already probe installing Server Maetro / media and clients with windows 2008r2 and still throws the same error with LTO3 tapes.
I hope you can guide me with this problem.
Of course, very grateful.
05-30-2019 11:49 PM
Hello,
this problem has generally no relation to type of client. I guess that Windows backup is on corrupted image and Solaris backup is on a good image.
Perform Verify operation on these images. (In a Restore Job detail you will find a backupid which you can use in bpverify command.) I recommend you to perform random verification of at least two images on every tape.
Regards
Michal
05-31-2019 01:06 AM - edited 05-31-2019 01:06 AM
There are only 2 possibilities here - 'something' outside of NBU has corrupted the images on tape or else the original backups were encrypted - via hardware encryption or software (by selecting Encryption option the backup policy).
Backup Admins need to keep proper documentation of backup environment - especially where encryption is used.
The encryption key is needed to restore.
If NBU encrypted backup is restored to a different client, the original client's keyfile.dat must be copied to the destination client.
Detailed TN about NBU encryption and how to restore: https://www.veritas.com/support/en_US/article.100031311
06-03-2019 07:10 PM
Good, I can not even solve this problem, the copies are not encrypted.
The copies are in good condition, because when performing a restore in a client under solaris, it is completed without any inconvenience.
The problem continues even when wanting to perform the restore on a client under windows server.
I hope they can help me.
regards
06-03-2019 11:01 PM
Hello,
You did not tell us results of the following (see above):
I guess that Windows backup is on corrupted image and Solaris backup is on a good image. Perform Verify operation on these images. (In a Restore Job detail you will find a backupid which you can use in bpverify command.) I recommend you to perform random verification of at least two images on every tape.
Regards
Michal
06-10-2019 05:37 AM
@mmarano wrote:
The copies are in good condition, because when performing a restore in a client under solaris, it is completed without any inconvenience.
The problem continues even when wanting to perform the restore on a client under windows server.
Cross-platform restore is not supported by NetBackup.
You can restore Solaris backups to any Unix or Linux client because the file types and directory paths are similar.
Some users have managed to restore flat files from one OS to another successfully, but that is pure luck.
Here is the official NetBackup doc:
https://www.veritas.com/support/en_US/article.100016326