Retrospect 8 not using all the tape space available

[jdmaass]

Hello all

I'm using Retrospect 8.2.0 (399) with a Certance LTO 3 tape carousel (8 slots). The 800 Gb tapes seem to have about 781 Gb of space available, but I'm backing up a larger amount of data (close to 1.5 Tb). The script I have written "skips to new member" and I loaded up the carousel with blank tapes.

The script is successfully backing up all the data, but it does not seem to be making very good use of the tape space available. The 1.5 Tb should fit on two tapes (possibly three), but after the first full backup it took three tapes and after the first incremental it is on to the fourth.

In "Media Sets" "Members" it is breaking down as follows:

1- 782.8 Gb Used / 0 b free (good!)

2- 462.5 Gb Used / 318.6 Gb free (sucks!)

3- 188.6 Gb Used / 592.5 Gb free (sucks worse!)

4- 826.8 Mb Used / 780.3 Gb free

 

 

Any idea why it is not using all the space available on the second and third members? (there are not single files equalling hundreds of Gb).

Is there anything I can do to fill the tapes better?

[Lennart_T]

You should forget about the column "free". It assumes that all files can be compressed 2:1. That is far from the truth.

 

The native capacity is 400GB per tape, we get something between 450GB and 650GB per tape on the Windows version of Retrospect.

 

Now for tape 3. If data isn't fed fast enough to the tape drive, it starts to add blank blocks to the tape to avoid constantly stopping and starting the tape. That would wear out the mechanism AND the tape. So I assume tape 3 contains many thousands of tiny files. Tiny files backs up much slower than a few large files of the same total size.

 

I recommend backing up to a (large) Disk Media Set and from that to the tape.

[jdmaass]

Thanks for the quick response.

 

By "a (large) Disk Media Set" do you mean hard drive space large enough to back everything up to (in this case, over 1.5 Tb)?

Doesn't this defeat the purpose of having a tape drive?

Also, would this cause problems for subsequent Incremental backups (incrementals going initially to disk... would it still see it as incremental going from disk to tape?)?

[Lennart_T]

Yes, that is what I mean.

It's called disk-to-disk-to-tape and has many benefits. So your tape drive is still used.

 

 

 

 

Disk-Based Backup Benefits Include:

1. Users are no longer relying on tape as the primary storage medium
   
2. Backups can be faster depending on the type of network
   
3. Restores are almost always faster (no tapes to find and mount)
   
4. Network backups provide superior disaster recovery protection
   

 

Tape-Based Backup Benefits Include:

1. Inexpensive and virtually unlimited media size (via libraries)
   
2. Small form factor
   
3. Multiple redundant backup sets
   
4. Easy off-site media storage
   

 

There are pros and cons to using either method as the sole strategy for protecting your data assets but with today's low hardware and software costs, there is now compelling justification to incorporate both backup strategies for a disk-to-disk-to-tape backup regime.

Disk & Tape Backup Benefits Include:

1. Every disk and tape benefit quoted above
   

 

http://www.ultrabac...._tapevsdisk.asp

 

EDIT: Forgot your last question: No problem at all. We have been doing this for years with Retrospect for Windows.

[jdmaass]

OK... this morning I see that the nightly incremental backup (253 files totalling 1 Gb) has not happened because it needs media. Tape 4 is still listed as only 826.8 Mb used.

Can this really be correct? The 400 Gb tape getting less than 1 Gb performance?

[twickland]

Can we assume that last night's backup script was scheduled to write to media set "Nightly A?"

 

Check the operations log to see if any problems have been reported in writing to the tape drive. In your search, I'd go back in the log to when data was being written to member #3, which also had an anomalously low amount of tape used.

 

If the tape drive reports a fatal error, Retrospect will ask for a new tape member. Were there any blank tapes in your library that could have been used but were not?

[jdmaass]

Can we assume that last night's backup script was scheduled to write to media set "Nightly A?"

Yes... I currently only have 1 script and 1 media set "Nightly A"

 

Check the operations log to see if any problems have been reported in writing to the tape drive.

You mean the Log associated with each separate activity, correct? The inital (full) backup had quite a few "can't read, error -1101 (unknown)" errors and a small number of "didn't compare" errors. I don't see any mention of write errors, though. The two subsequent (incremental) backups (previous to last night's) were both successful, with green checkmarks.

 

Were there any blank tapes in your library that could have been used but were not?

No, Unfortunately I have run out of blank tapes, since I wasn't expecting to need 5 at this stage.

[twickland]

You mean the Log associated with each separate activity, correct?

No; I mean the complete operations log, which you can view by hitting Command-L or by selecting "Log" in the View menu. If you can't see back far enough, go to the Console pane in Retrospect's preferences and increase the number of log lines shown.

 

You are looking for error messages that specifically refer to your tape drive or its communications bus, such as 206 Drive reported a failure, 102 Trouble communicating, 203 Hardware failure, 205 Lost access to storage medium, etc.

[jdmaass]

Thanks, I did not know about that log.

 

Unfortunately I don't see any such errors. All here looks much the same as the individual logs.

[twickland]

The script I have written "skips to new member" and I loaded up the carousel with blank tapes.

Whoops! I missed that sentence when reading your first post. That's the reason you're seeing what you're seeing.

 

"Skips to new member" instructs Retrospect to ignore whatever capacity is left on the current member and to request a new member every time the script runs that scheduled backup. You want to specify "no media action."

 

If there's nothing important on those partial tapes, you could mark them as lost, erase them, and use them for members 5 and 6.

[jdmaass]

Wow... thanks.

I assumed "skips to new member" meant that it would skip to a new member when the tape was full.

 

Thanks very much for the help.

[Andrew Cherry]

You are looking for error messages that specifically refer to your tape drive or its communications bus, such as 206 Drive reported a failure, 102 Trouble communicating, 203 Hardware failure, 205 Lost access to storage medium, etc.

 

I've got a similar problem to Jdmaass; Last night's scripted backup failed, and the log reported a "102 Trouble Communicating" error. According to the info in the Backup Set dialog, the tape is only half full, but when I try to backup to this set, it asks for a new tape.

 

Has the tape been filled with blank blocks, as Lennart explained? Also, do I need to worry about the integrity of the data on the tape from previous backups?

 

Any assistance you could give me would be much appreciated.

[twickland]

Last night's scripted backup failed, and the log reported a "102 Trouble Communicating" error. According to the info in the Backup Set dialog, the tape is only half full, but when I try to backup to this set, it asks for a new tape.

If a fatal error (communication, drive reported an error, etc.) occurs when writing to a tape member, Retrospect will flag that member and ask for a new tape member.

 

Has the tape been filled with blank blocks, as Lennart explained?

No. However, the last file being written at the time of the error probably lacks the correct end of file marker. If so, the tape cannot be written to any further, unless and until it's erased.

 

If you wanted to confirm this, you could try rebuilding the catalog. If you have set "fast catalog rebuild" for this media set, you should be able to rebuild the catalog by inserting just the last member. (Important: to save yourself a potential headache, drag the existing catalog file to the desktop or somewhere else safe, so that you can easily drag it back in case you get in deeper with your catalog rebuild than you like.) When the rebuild reaches the last file on the last tape member, it may finish and ask whether you have any further members. If this happens, you were lucky; the last written file was in fact closed properly and you will be able to continue writing to this member. More likely, the tape drive will shuttle back and forth trying to read the last file; you may get a "resynchronizing" message. This means the last write failed and you will need to skip to a new member.

 

Also, do I need to worry about the integrity of the data on the tape from previous backups?

If the data was properly written to the tape the first time, it will be OK, assuming that nothing further happens that causes damage to the tape. If the last file was not closed correctly, Retrospect will know this, and will back up the file in question during the next scheduled backup. You can run a Verify operation on the tape member to confirm that all is OK.

 

However, -102 errors rarely occur only once. They usually indicate that there is a problem with the tape drive itself, or with the connecting cable or the associated bus adapter in the host computer. How is your tape drive connected?

[Andrew Cherry]

The tape drive has a SCSI connection to a PC workstation*. Lately, it's been temperamental; it has to be booted carefully, and if the workstation fails to recognise the drive, they both have to be shutdown & left unplugged for at least 30 seconds. The transfer rate occasionally drops to very low levels, and as you said, we've had a few -102 errors over the last couple of months.

 

I've updated the drive's firmware and had our IT support service look it over, but it's still not as stable as it was. I think it may need to be replaced; is SAS preferable to SCSI, in terms of stability?

 

By the way, thank you for the information and advice, it was a great relief!

 

*Sorry for posting this in the wrong section. This topic was very close to the question I wanted to ask.

[Lennart_T]

Sometimes it helps just to unplug and replug the SCSI cables (with everything powered down, of course). That removes oxide and dust from the contacts.

And never blow on the contact, they get saliva all over the place.