Jump to content
Sign in to follow this  
gkowalsky6

Exabyte VXA-2 1U Packetloader (FireWire) changer Problems

Recommended Posts

Hello, all,

 

I'm trying to make sense of all that. Just got a new library...

My current configuration:

- Dell's XPS P4/3.2GHz, 4 GB RAM, plenty of HD space (HD checked, reported no errors);

- XPSP2 - all updates;

- generic 2-ports FireWire 400 controller, an 800-to-400 generic cable (both new from the box, worked for other devices);

- Retrospect SS 7.5.324, RDU 7.5.8.101;

- Exabyte VXA-2 1U Packetloader (FireWire) changer;

- logged in not as Administrator, but with full Admin rights.

 

As contrary to my experience with SCSI on all prior versions of Retrospect, but per Exabyte's KB directions, I installed drivers for the library and tape drive. Otherwise, Retrospect did see the tape drive, but did not see the changer.

 

Tried to run a local backup - Retrospect hungs on me after backing up approximately 500 MB. No way to stop, only to kill it in Task Manager. After relaunch, neither traces of backed up files, nor catalog were found on the tape - the tape was reported as named, but empty.

 

Changed in Retrospect prefs:

- deselected NTPassthrough (i.e., running with ASPI drivers);

- in script preferences, _all_ security information is _not_ backed up;

- system state is not backed up.

 

If I'm enabling system state backup, or/and security information backup - Retrospect hungs on me, period.

 

Without security/system state test backup/restore of 20 GB went fine. But on scheduled run, the catalog was reported as out of sync. After the recatalog, the .rbc file size went down from 29 MB to 19 MB. Next scheduled run - catalog's out of sync, again.

 

The big bad questions:

- why Retrospect hung accessing a system disk, while having presumably all needed rights?

- the installation's fresh, the disk was checked. What's wrong with catalog files?

Share this post


Link to post
Share on other sites

After the repair, I rerun the script again, this time setting Hidden Prefs-> Debug Logging-> Trees and Volumes, and Backup Sets... to "7". Got the same "Out of Sync" error after volume scan. On top of it, I've got the assertion failure.

 

The log did not give me a clue, however:

+ Executing Recatalog at 11/14/2006 6:49 PM (Execution unit 1)

To Backup Set SKIPPED...

11/14/2006 7:45:22 PM: Execution completed successfully

Duration: 00:56:04 (00:55:10 idle/loading/preparing)

tyceCheckDL: DL 6294 item 'HSLo' bad chunk 1013, error -647 (resource not found)

tyceCheckDL: DL 5940 item 'HSLo' bad chunk 1012, error -647 (resource not found)

several repeated tyceCheckDL errors entries skipped

....

arcDoMatch: hash loading: 0.031 of 0.5 secs (6.20%) for 1 ops (31,000.0 uSec/op)

arcDoMatch: hash saving: 0.187 of 0.5 secs (37.40%) for 2 ops (93,500.0 uSec/op)

arcDoMatch: session loading: 0.141 of 0.5 secs (28.20%) for 1 ops (141,000.0 uSec/op)

arcDoMatch: matching: 0.500 of 0.5 secs (100.00%) for 1 ops (500,000.0 uSec/op)

Catalog File out of sync with Backup Set SKIPPED.

 

Any suggestions will be greatly appreciated.

Share this post


Link to post
Share on other sites

Hi,

 

With firewire devices the operating system needs to be able to communicate with it before it can pass accurate device info along to Retrospect. You're right about SCSI, the OS does not need to see SCSI devices, you could even disable them in device manager and still have them work correctly with Retrospect.

 

Quote:

 

The big bad questions:

- why Retrospect hung accessing a system disk, while having presumably all needed rights?

- the installation's fresh, the disk was checked. What's wrong with catalog files?

 

 


 

At this point I would think the more likely cause of the hang would be device related - the exabyte, not the system disk. Do you have space to setup a test backup to a disk backup set?

 

The catalog files are likely becoming out of sync due to communication errors that seem to be fairly common with firewire libraries. Firewire is convenient, but in my experience it simply isn't reliable like SCSI.

 

I'm wondering if the issues you are experiencing are related to the 'generic' hardware you're using. I've seen reports from other users in this forum that simply switching from 'working' generic hardware to name-brand hardware relieves some device issues. There is a reason name-brand products are more expensive than generic products, and it's not just the name.

 

You say you're logged in with Admin rights, but is this information configured in Configure> Preferences> Security? Also, you don't mention either way, are you using hardware compression for the tapes?

Share this post


Link to post
Share on other sites

Foster,

 

First and foremost - thanks for your help. Seems like this problem was resolved by swapping the existing card with a SIIG's 800 one. So, your suggestions were exactly to the point.

 

Thanks a lot!

Quote:

 

I'm wondering if the issues you are experiencing are related to the 'generic' hardware you're using...name-brand products are more expensive than generic products, and it's not just the name.

 

 


Well, the card we have is not exactly a stray doggy. It came preinstalled with the station from the big company. I'm wondering, do all the four-letters words are bad, or at least troublesome? Neither the <four-lertters-last-name-goes-here> integrated controller worked, nor factory-installed card.

Quote:

 

...Firewire is convenient, but in my experience it simply isn't reliable like SCSI.

 


 

Agreed. Oh, these good old days of SCSI chain voodoo, little furry animals' sacrifices...

 

Now, could you give me any explanation for the following errors:

Quote:

 

tyceCheckDL: DL 6694 item 'HSLo' bad chunk 1036, error -647 (resource not found)

tyceCheckDL: DL 5953 item 'HTrH' bad chunk 1034, error -647 (resource not found)

tyceCheckDL: DL 5959 item 'HTrH' bad chunk 1035, error -647 (resource not found)

 

 


 

These errors appear all the time, despite that I set debug logging to default level 3.

Should I be worried? I did not find the references to these errors in the KB, "-647" is too broad.

 

Quote:

 

You say you're logged in with Admin rights, but is this information configured in Configure> Preferences> Security?

 


 

I would appreciate, if you can give me pointers to the Retrospect rights' configuration, may be a tad more than in the User Manual. I am trying to configure this station the way that _even_ the backup operator will not have Admin rights. It is not a dedicated machine, unfortunately.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×