Yesterday I ran into that problem (again) that I cannot restore with ArcServe 6.x from other than session 1.
In case you’re also using a skeleton NetWare with a similarly old ArcServe and Google to search :-), here are the error messages:
E1058 Failed to read from media – Filemark detected
E1112 Failed to find session 2.
E0015 Job xxxx: Restore Operation Failed
As far as I remember, last time when I tried to look for the solution I failed, but now I found a relatively fresh solution/explanation at:
http://www.tek-tips.com/viewthread.cfm?qid=1238418&page=7
It refers to
http://software.groupbrowser.com/archive/t-110093.html as partial source.
I also devoted some more slice of my life to get further information on this, here is the compacted result.
When a tape drive is not recognised by tapesvr.nlm, then it uses the default settings, which is 1024 bytes for block size and “VTABLE” for format type as CA’s TEC356365 “explains”:
“Prior to the latest device patch, if the tape device could not be matched to the Tapelist.dat file, Tapesvr.nlm would still load, but the device would be initialized with generic information for that device type. In those cases, drives could be initialized with an incorrect format type of VTABLE (instead of FSTSEEK) and an incorrect block size. The results could range from poor drive performance to the inability to restore backed up data.”
So, when you try to restore from other than session 1 (eg.: session 2, 3, etc.), then you get the above mentioned error messages (the “inability to restore backed up data” part).
However, you can still restore files from any session, by issuing a “tapesvr enable vtrestore n” command on the NetWare console, obviously “n” is the session number to be deal with. (You should get a message like “VOLUME TABLE restore of session #n has been enabled”)
I strongly suspect, that this is not just 6.1/6.6, but (BAB-BrightStor ARCserve Backup) 11.x too.
As described in CA’s TEC356365, they “realised” that this is not good, so they created a patch, which instead of letting tapesvr.nlm start with the “standard settings” (1024/VTABLE), now display you the following warning message and tapesvr unloads.
“E6918: An un-certified/un-supported device has been detected! Check the Computer Associates technical support website for more information… ”
They also created an tapesvr.cfg option:
“UnSupportedDeviceOverride=ENABLED” as they say: “ONLY to allow users to be able to use ‘certified’ devices without having to immediately down the server and remove the ‘uncertified’ devices in order to allow tapesvr to load“.
In fact, as TEC356365 also says, having an unsupported device, with default settings have the only problems of “poor drive performance” and “inability to restore backed up data“.
The latter was discussed previously, but actually I don’t really understand why ArcServe cannot just simply restore that damn session in VTABLE format automatically, why do I have to enter that cryptic “tapesvr enable vtrestore n” command?
As for speed, with the 1K/VTABLE settings I got “92,320 files 11,346,014 KB written to FULLSYS @190,742 KB/min”. After changing to 16K/FTSEEK, I got “92,349 files 11,211,035 KB written to FULLSYS @192,574 KB/min”.
Not much of a change. (I use CANWPABD by the way.)
Now you got the question, how can you change from 1K/VTABLE to bigger buffer and FTSEEK.
The answer is relatively easy. Use the latest tapelist.dat and see if you tape drive is in the file. I mean, yes, no matter what version of ArcServe you use, grab the latest tapelist.dat you can. Currently the newest seems to be available from “BrightStor ARCserve Backup r11.1 SP2 for NetWare [build 961]“.
I understand if you wouldn’t like the idea to download an 500MB kit to get that 30K file, so here is it for you: tapelist.dat [29688 bytes, 2006.SEP.12].
Copy the file to ARCSERVE.6\NLM directory, unload and reload tapesvr.nlm.
To check the settings, remove any tape from the device, then go to “Tape Server”, “Tape Device Management”, “Tape Drive Status” menu.
If you see change, then you can go to have fun. If you don’t you’re out of luck. You can get your favourite hexeditor, and overwrite a similar entry’s id [name] in the tapelist.dat and hope it would work, or wait for a newer tapelist.dat.
Passing by, I noticed an article on “validate.nlm” which you might also like. Quote:
“What is VALIDATE.nlm?
In the distant past, …
… Therefore VALIDATE.nlm was never used for its intended purpose. ARCserve still requires VALIDATE.NLM. VALIDATE.nlm simply tells ARCserve that all drives are acceptable.”
Good job, validate.nlm!
