Retrospect overwrites backup set members

[lafong]

Retrospect sometimes overwrites backup set members. It grabs a member of an existing set, and uses it for another set. This is very bad, and very frustrating. I think may be related to its sometimes identifying an existing tape (with data) as "Erased". One other person on the forums had that problem, and found that updating drive and autoloader firmware cured it. We are already at the latest firmware for both. They also mentioned a bad batch of VXA tapes. We've seen no pattern of tapes involved. I am a little doubtful at this point we'll ever find the cause of this problem. It is extremely random. It would be nice if we could set a preference to never, ever, add a tape to a backup set without asking first. But, it seems that if Retrospect thinks a tape is erased it will use it for another backup set without asking, no matter what. We are at v7.0.326 of Windows Multi Server, with a 4-drive Exabyte 430 VXA-2 autoloader.

[rhwalker]

Yep, I'm that "other person". Spent hours and hours troubleshooting the issue (but on the Mac version), and you seem to be going through the same ordeal. The errors are so random that it's hard to reproduce and decide what the problem is after changing one variable. My final conclusion was that it was an interaction of:

 

(1) a batch of marginal tapes (I sent them back and Exabyte declared them to be "good", so I just tossed them out);

 

(2) one firmware version with some quirks in the BOT error recovery code; it's interesting to read the release notes from Exabyte during the period when they were struggling with this issue;

 

(3) Retrospect's odd algorithm for apparently deciding that a tape is "erased" when it gets an error at BOT; and

 

(4) Retrospect's refusal to honor the names of pre-erased, pre-named, barcoded tapes, and to whimsically use whatever tapes it believes are "erased" in the library, even if their barcode is tagged for a different data set. Makes management of barcoded inventory impossible and also can cause loss of backup sets, as you have found.

 

I had thought (at least as reported in the release notes) that item #4 had been addressed a couple of years ago for the windows version of Retrospect.

 

My solution, for now, until things improve with the Retrospect code (not holding my breath here because I reported this a couple of years ago under our service contract), is to do weekly cleanings of the tape drive and never reuse tapes after they fill. We go through a lot of cleaning cartridges and a lot of tape, but our data is more valuable than the cost of cleaning cartridges and tape.

 

I feel your pain.

 

Russ

[cmcfarling]

Don't know of a fix but I can relate to the frustration. Although Retrospect gives you the ability to name tapes, and even the ability to barcode them, it will happily ignore the name and barcode if the tape is blank/erased.

 

If using a tape library, if Retrospect runs out of space it starts searching for any blank media. So for example let's say the current backup is going to the backup set "Backup_A". In your 7 tape library you have tapes

 

1-Backup_A

2-Backup_A

3-Backup_A

4-Backup_A

5-Backup_A

6-Backup_A

1-Backup_B

 

The 1-Backup_B tape is erased but you manually named it when you erased it with Retrospect. So the unattended backup moves along and fills up 1-6-BackupA and now it needs a new tape. Even though 1-Backup_B doesn't follow the same naming convention, Retrospect will grab it, rename it 7-Backup_A and carry on with the backup.

 

The other problem with this behavior is if some of the tapes are blank. So let's say this time you fill your library with 7 tapes. 1-Backup_A has already been written to by Retrospect causing it's name to be embedded on the tape. You go ahead and apply stickers to the tapes so you know which one is which when they're out of the library. The tapes are loaded as follows:

 

 

1-Backup_A (slot1)

2-Backup_A (slot2)

3-Backup_A (slot3)

4-Backup_A (slot4)

5-Backup_A (slot5)

6-Backup_A (slot6)

7-Backup_A (slot7)

 

Then you take the time to go though and manually name each tape in Retrospect. At this point going to Configure >> Devices displays the tape library slots. The name Retrospect sees corresponds to the physical label on the tape. So far so good. Now, an unattended backup to Backup_A starts as scheduled. Retrospect will grab the tape in slot 1, see that it is the 1st member of Backup_A and proceed to write to it. Then tape 1 fills up so Retrospect moves onto slot 2. Well, since you named that tape 2-Backup_A Retrospect will surely notice that and proceed with that tape. Wrong. Since the tape is erased Retrospect ignores the name and continues to move through the library looking for a non-empty tape named 2-Backup_A. When it gets to slot 7 it realizes that no such tape exists and they are all erased. As such it decides to use the tape in slot 7 as 2-Backup_A to save the time of skipping back to slot 2. From then on it backs up one slot at a time as each tape fills up.

 

When you come in and check in a couple days the tapes are arranged as follows:

1-Backup_A (slot1)

7-Backup_A (slot2)

6-Backup_A (slot3)

5-Backup_A (slot4)

4-Backup_A (slot5)

3-Backup_A (slot6)

2-Backup_A (slot7)

 

Now each tape is named differently than what it is labeled on the outside, except for the tape in slot 1. Time to peel and reapply those labels.

 

So with that said, it would be nice if the naming feature actually did something meaningful. As it stands you can name tapes all you want, then Retrospect will be happy to override all those names that you spent all that time setting up.