by nia » Fri Jan 29, 2010 10:11 pm
Here is to report that Symantec Backup Exec 12.5 for Windows Servers works with mhvtl via iSCSI.
See my post here regarding how to use mhvtl with iSCSI:
See these screen shots as an indication of a working operation.
Microsoft iSCSI Inititator connected:
MHVTL Medium Changer and 4 DLT tape drives recognized and configured in Windows Device Manager:
Tape drives using Symantec drivers updated by Backup Exec during installation:
MHVTL Medium Changer and Drives in use in Backup Exec:
Successful Backup Job:
Detail of Successful Backup Job:
Detail of Successful Restore:
by sloony67 » Tue Feb 02, 2010 12:10 am
by prejdarov » Fri Feb 12, 2010 11:51 am
This setup works with Backup Exec 2010 on Windows Server 2008 R2. Tested version of mhvtl is 0.18.2 (yes, multiple robots and all working simultaneously).
by nia » Fri Feb 12, 2010 2:53 pm
Have you had issues with Backup Verify ? It started to fail on me and I am not sure if related to mhvtl or the windows host and Backup Exec .. I do not have much experience in Backup Exec.
by prejdarov » Thu Feb 18, 2010 3:35 pm
Well, yes.... and no. While with NetBackup I had no issues with performing backups and verifying images after that There is a problem with Backup Exec. If I try and do some small backups like 20-30MB (C:\Users for example) everything goes fine - backup is done, then the verify process ends with success and I can restore the data. If I try to do backup to a folder that has some 300+ MB, it fails with "An inconsistency was encountered on the storage media in *Drive_Name* " error. The restore jobs from these backups also fail with CRC errors. There is no difference if it is multiple tape backup or not (given that the default size of mhvtl tape is 500MB). First I thought that there must be something with the CentOS 5.4 x64 (current) setup, but the problem persists even on a *reference* Gentoo x64 iscsi-vtl. It has nothing to do with the selection lists. I found those errors in the dmesg:
scst: ***ERROR*** Unknown opcode 0xb5 for dev_tape. Should you update scst_scsi_op_table?
0: b5 20 00 10 00 00 00 00 00 34 00 00 00 00 00 00 .........4......
scst: ***ERROR*** Unknown opcode 0xa2 for dev_tape. Should you update scst_scsi_op_table?
0: a2 20 00 10 00 00 00 00 00 f8 00 00 00 00 00 00 ................
Most of the time there is 2-3 opcode 0xb5 errors per failed job, but sometimes there is additional 0xa2. Don't know what is this all about, but hope it helps. Again in NetBackup everything seems to be fine with NetBackup 7 Master on Windows 2008 R2. If anyone needs more info or another test, I will gladly help
by nia » Thu Feb 18, 2010 9:16 pm
Yea, I get these also from scst ..
I am not having any issues with restores at all even large one. Large backup with no verify succeeds also.
I have my Default media capacity set to 2000, but the size of the volume may not be any cause for any error.
When I was researching the backup verify errors, I was seeing many people suffering from this. Most of the time fingers have been pointing to Backup exec or the windows host but not the tape device.
I will continue to play with it some more to see if I can get enough info for the developer to investigate ..
Thanks for your feed back .. Good stuff..
by herve » Mon Mar 08, 2010 7:14 pm
i have the same issue with mhvtl 18.4 and scst 1.01
any new information ?
by nia » Tue Mar 09, 2010 12:28 am
No update yet. MHVTL Developers will eventully check this.
This is coming from scst, so it is outside of mhvtl, but could be a true mhvtl error that needs to be fixed.
Perhaps, we should email [hidden email] also.
by markh794 » Wed Mar 17, 2010 6:41 am
This is the SECURITY PROTOCOL IN / SECURITY PROTOCOL OUT op codes. (i.e. Encryption)..
You have several options.
1. Ignore the errors
2. Fix scst to pass through the above SCSI OP codes
3. Update the /etc/mhvtl/device.conf and configure devices which do NOT support the SPIN/SPOUT op codes (e.g. Ultrium-1, SDLT320, DLT7000 etc)
This way, the backup software "shouldn't" be sending the op codes to devices which are of older vintage (testing required).
by prejdarov » Wed Apr 07, 2010 11:43 am
Thanks Mark. With SDLT320 and QUANTUM as a manufacturer there are no more opcode errors. But now the verify and restore process doesn't work. The Error is "The data being read from the media is inconsistent" (e00084ca HEX or a00084ca HEX). Ran the trace.exe and found that it starts to fail on READ6 operation after some 500-1000 successful READ6s. Here is what I got in my vtl messages:
Apr 7 17:09:30 nbu65-vtl vtltape: processCommand: READ_6 "Fixed block read" under development - Read 1 blocks of 65536 size
Apr 7 17:09:30 nbu65-vtl vtltape: readBlock: Expected to find hdr type: 11, found: 3
Hope this helps. I tried both with write pass-through and write single block enabled and disabled.
If verification is disabled the backup finishes without errors, but then the restore fails.
|Free forum by Nabble||Edit this page|