Tape name not being updated

[wobblewoo]

Hello.

 

Lets say Mondays tape is in the drive and it runs (completes on a single tape, no errors), when we eject it and then put in Tuesdays tape it still thinks Mondays is in the drive!

 

Ive been erasing the tape each time to force it to use the correct tape but ive just restarted the server and now the tape in the drive (which was showing as Tuesday in the software before the restart) now displays correctly as Thursday and ive done nothing else.

 

Were running the latest Retrospect (8.2 build 626) on a Xserve 10.5.8 with a Quantum LTO3 drive.

 

Interestingly we don't seem to get this problem running a normal backup, only a recycle one - however we need to run a recycle backup.

 

Any ideas?

 

W

[wobblewoo]

Anyone?

[rhwalker]

Were running the latest Retrospect (8.2 build 626) on a Xserve 10.5.8 with a Quantum LTO3 drive.

Doubtful that anyone can respond because Retrospect 8.2 has not been released yet.

 

Russ

[Daniels]

I am pretty sure he meant 8.1 (build 626) since 8.2 will have a different build number and the current version out is 8.1.626

[wobblewoo]

Exactly that, its Version 8.1 build 626.

 

Apart from that though can anyone help with my problem? Do you need any more information?

 

Thanks for your time so far.

 

W

[rhwalker]

Are your tapes barcoded?

Does your drive / autoloader have a barcode reader?

 

Russ

[wobblewoo]

The tapes are not barcoded.

 

The drive is a Quantum lto 3 400gb/800gb hh ultra160 68pin scsi tabletop using a single Sony lto3 ultrium tape at a time.

 

Im in the putting all the tapes in the drive and seeing what the software says that it is.

 

Thanks again

[rhwalker]

Ok. Perhaps it's a bug, and the reason others aren't seeing it is that almost all tape users use barcoded tapes.

 

If you swap tapes behind Retrospect's back, how is it supposed to know what tape is in?

 

Before writing to a tape, a normal backup will read the header. Perhaps it should be reported as a bug.

 

Russ

[wobblewoo]

How would we use barcoded tapes, im assuming that our drive doesnt support that. Is it only autoloaders that use barcoded tapes?

 

If that was the case, and Retrospect didnt know i swapped the tape how would it know its the wrong tape in the drive if it didnt read the header!

 

Could answer why it then read the correct tape after a restart, it probably reset the scsi bus and re-initalised the drive.. just a thought.

 

Ill report that as a bug and see how we get on.

 

ANy other ideas would be good though.

 

Is there a way to erase each tape automatically before it starts a backup?

[Daniels]

I have found that if you use a recycle backup it will reset the data set and overwrite the tape before starting the backup.

[wobblewoo]

Thats how i think its supposed to work but it doesnt do that here, It still thinks that the prior days (or day befores if we dont erase a tape) tape is in the drive and so times out.

[Daniels]

Have you tried stopping the engine and dumping your config files and then re-starting the engine? The only drawback to this is that you will need to set up all your scripts and reload your backup sets. It will also refresh Retrospects storage devices.

The other question becomes how are you ejecting the tapes, through Retrospect Console or on the drive iteself? I have found that Retrospect does not like it when you eject the tape manually using the eject button on the tape drive.

[wobblewoo]

Ive resetup all the scripts (although i didnt dump config files).

 

We have set the tape to eject after a backup and that seems to have solved the problem, although were now having another issue (see thread below).

 

Thats silly. Are you saying that we have to eject the tapes from the software in order for the backup to work? Can i set an action script to do this in the morning? The reason i ask is the non tech office manager swaps the tapes over.

 

http://forums.dantz.com/showtopic.php?tid/33958/

 

Cheers

 

W

[Daniels]

As long as the console knows that you are switching tapes then it should automatically update the tape name and yes you can have a script do this. I have seen the problem occur when you close the console first and then switch tapes manually. I have done this on my backup system especially with a cleaning tape and everytime it corrupts the config files.

If Retrospect ejects the tape for you then make sure to load the new tape without exiting the console and Retrospect should recognize the change in tapes.

Edited May 25, 2010 by Guest

[wobblewoo]

So that basically sounds like i need to leave the Console running on the headless server (where the drive is connected). As long as we do this we can manually eject the tapes, is that correct?

 

Normally we remote into the server (using Retrospect) via office machines or offsite you see.

 

Maybe this is something that Dantz should fix, a simple head read of a tape before it backs up.

 

Thanks for your time so far all.

 

W

[Daniels]

I would recommend not manually eject the tapes at all and use the eject command in the Retrospect console. If Retrospect exits after ejecting the tape you should be able to insert a new tape and then open the console and it should pick up the new tape. Either way make sure the console is running when the tape is ejected.

 

This is definitely a bug that Retrospect definitely needs to look into and I would post it in the bug report.

[wobblewoo]

But the server is headless and the office manager just swaps the tapes over each day. The best i can do is set Console to run at startup and so hopefully notice the change. Ill let you know how it gos.

 

Ive posted this already in the bug report. Hopefully this big update ive heard read about will fix the issue.

 

W

[Daniels]

If the console and engine are on two different machines then do not eject the media unless the console is running on the remote computer.

This is just a suggestion but here are the steps I would follow:

1. Open the console on remote computer.

2. Eject the tape through the console.

3. Have Office Manager swap tapes.

4. Make sure new tape appears.

5. Quit the console.

If this works then we know Retrospect has a problem when tapes are switched behind its back.

Edited May 25, 2010 by Guest

[rhwalker]

If this works then we know Retrospect has a problem when tapes are switched behind its back.

Nope. Steps 1 and 5 are irrelevant. You've got the wrong model for the design.

 

Retrospect is the engine. The console is just a GUI (there can be many consoles), without any real intelligence. Think "iPhone app" for the console.

 

The engine has the intelligence (don't we wish).

 

Russ

[Daniels]

In my experience I have found that the engine does not have the intelligence to detect changes in tapes if the console is not running. I tried swapping tapes without the console running and it has always led to problems.

Also anytime I have manually ejected or loaded tapes without the console running the log never gets updated which it should since the engine should know what has happened with the device.

It seems to me that engine uses the console to talk to backup device so if the console is not running there is no communication between the backup device and the engine and that is why I suggested trying to change tapes with the console running.

Edited May 26, 2010 by Guest

[rhwalker]

In my experience I have found that the engine does not have the intelligence to detect changes in tapes if the console is not running.

Then that's a bug.

 

I tried swapping tapes without the console running and it has always led to problems.

Yes, but whether the console is running is a "red herring". A better statement of your test is that you swapped tapes using the tape drive's front console (or some autoloader administration utility) rather than doing so from Retrospect.

 

Also anytime I have manually ejected or loaded tapes without the console running the log never gets updated which it should since the engine should know what has happened with the device.

That's an entirely different issue from the issue of the original poster. You seem to want tape drive status change updates to automatically appear in the log. That might be a nice feature (or perhaps a debugging aid), but it has nothing to do with the original poster's problem, which relates to Retrospect (engine) knowing what tape is in the drive.

 

Many (most) tape drives (ours does) has a bit that gets set in the drive status when things change.

 

It seems to me that engine uses the console to talk to backup device so if the console is not running there is no communication between the backup device and the engine and that is why I suggested trying to change tapes with the console running.

You seem to have a profound misunderstanding of how the program works, and of computer design in general.

 

The console is just a GUI. And how do you expect the console, located across the world or even another subset, to "talk to the backup device"? Perhaps by telepathy?

 

Russ

[Daniels]

I have swapped tapes using the autoloader's front panel and when I go back into the console the tape names and locations are screwed up. This is especially true when using I use the cleaning tape but it has happened with other tapes as well.

 

The console is just a GUI. And how do you expect the console, located across the world or even another subset, to "talk to the backup device"? Perhaps by telepathy?

Maybe I am missing something but when I eject media from a device in the console it sends a command to the backup device to eject the tape which would mean that there is talking between the console and the backup device. If there was no talking between the console and backup device like you suggest then the eject command should do nothing.

Edited May 26, 2010 by Guest

[rhwalker]

I have swapped tapes using the autoloader's front panel and when I go back into the console the tape names and locations are screwed up. This is especially true when using I use the cleaning tape but it has happened with other tapes as well.

As noted above, that's a bug. But the problem is at the engine, not the console.

 

 

Maybe I am missing something but when I eject media from a device in the console it sends a command to the backup device to eject the tape which would mean that there is talking between the console and the backup device.

Again, you have a profound misunderstanding of the program's operation.

 

The console sends user actions to the engine. The engine parses those user actions and causes commands to be sent to devices, depending on the type of media set. The console refreshes its display based on information from the engine. There is no communication path from the console to any devices. Ask yourself: Do you install the Retrospect Driver Update on the console computer or on the engine computer?

 

If there was no talking between the console and backup device like you suggest then the eject command should do nothing.

Again, you have a profound misunderstanding of the program. See above.

 

I suggest you read the "Retrospect 8 Getting Started Guide", especially page 4.

 

Everything that the console can do can be done on an iPhone, and that's why it was so easy to do the Retrospect iPhone app. The console is simply a Graphical User Interface ("GUI"). That's all. Retrospect is the engine.

 

It may just be that you are unfamiliar with modern computer program design, and factoring an application into GUI and operational modules.

 

Russ

[Daniels]

Okay I see how the system works now. I did not realize that the engine did all the talking to the backup device and console goes through engine to talk to the backup device and does not communicate directly. Since I have always had the console and engine on the same computer it seem more logical for the console to talk directly to backup device instead of going through the engine.

 

Since I now understand that the console only shows information from the engine I understand that the swapping without the console running is an engine bug.

 

The bigger question is why swapping works with the console running and does not without the console running.

Edited May 26, 2010 by Guest

[rhwalker]

The bigger question is why swapping works with the console running and does not without the console running.

It may be that a console display refresh triggers the engine to obtain the status of devices, which might mitigate the bug but still doesn't eliminate it.

 

But the bug is still at the engine.

 

Russ