LTO backup

[Tim Jones]

No two tapes are always going to be the same. Tapes will exhibit soft errors - blocks of data that are not written successfully and automatically rewritten. This is one of the reasons why we don't simply write the same stream to both drives, but rather create to self-contained streams.

As to the speed, while large numbers of soft errors will contribute slightly to performance issues, the source drive's speed can be a real issue when 2 processes are reading at the same time. Is your media drive a fast SAS or F-C array or a USB, Firewire, or internal drive?

Tim

[Evan T Gervais]

Thanks for the further info, Tim

The decks are hooked up via mini-SAS, and the media currently being backed up is on an external HDD Lacie Hal connected via FW800. Usually the backups are connected to an external HDD via E-SATA.

[Tim Jones]

eSATA will definitely be faster than FW-800. Remember, the TOTAL bandwidth for a FW-800 drive is 78MB/sec. Far less than the 160MB/sec that driving 2 LTO-4 drives would require.

[Evan T Gervais]

Thanks for all the help, Tim.

I guess in the end I didn't have anything to worry about when I noticed the different backup sizes on the first tapes of my multi-tape job. If I could ask one more thing it would be this:

BRU adds a header of approximately 15% of the total file size. So if I calculate that my media will fit onto 2 LTO 4 tapes (four total with the use of Tape Doubler). If the media on the first tapes are different (one 757 GB one 690 GB), how will I know that both copies will actually fit on two tapes, and one won't end up being on three? Is there another method I should go about for calculating how many tapes I will need for each back? Currently I just take the total GB size and multiply it by 1.15.

[Evan T Gervais]

I just discovered that you guys have calculators to better estimate all of this. Great news!

[Tim Jones]

The unfortunate truth about tape is that there's no real "exact" method for determining a tape's capacity. For example - if you're backing up mostly R3D files, but throw in 100GB of doc files / EDL lists, etc., that 100GB will exhibit some level of compression. This could mean that an 800GB tape would actually store 910GB of processed BRU data. On the other hand, an old tape of questionable repute suffering from a high level of soft errors may only store 700GB using that same data.

BRU will properly handle the cross-over data so long as you continue to feed tapes into the drive.

[Evan T Gervais]

I seem to be having a lot of issues with the new BRU PE released (version 2.2.0). It seems the stalling on restoring files (mainly .R3Ds) is still there. When I turn on Auto-Trimming, it helps with the problem but they are still there. The other thing that happens is when I create a backup, while it is writing, it tells me that the tape is starting to rewind. The backup completes properly, but sometimes it doesn't generate the same Archive ID as what is on the tape, so the tape won't be able to restore unless I manually go in and change the Archive IDs to match.

Also, one last thing. I know that BRU PE 2.2.0 can read previous versions archive IDs. But can, for example, BRU PE 2.1.0 read 2.2.0 archive IDs? Just wondering in case I want to revert back to 2.1.0 because of these issues.

[Evan T Gervais]

Another Issue I have found is that when you complete a single tape backup, and have "Verify Archive" disabled, BRU will still verify the backup. If you abort the verify, BRU will crash and you will no longer be able to use that Archive it created.

A bug we have found here is if you don't rewind your tape if you are overwriting a pervious tape, then BRU PE 2.2.0 will display the "Rewinding Tape" dialogue box overtop of your progress bars when doing a single tape backup. This only happens during single tapes. No issues as of yet using the tape doubler.

[Evan T Gervais]

All of the bugs I have stated above only happen during Single Tape Backups. Right now, it seems more efficient for me to use the tape doubler function when creating single tape backups, and then just erase the duplicate copy later. I haven't had any issues while using the tape doubler, but major bugs while making single tapes.

[Maciej Roszkowski]

Another Issue I have found is that when you complete a single tape backup, and have "Verify Archive" disabled, BRU will still verify the backup. If you abort the verify, BRU will crash and you will no longer be able to use that Archive it created.

A bug we have found here is if you don't rewind your tape if you are overwriting a pervious tape, then BRU PE 2.2.0 will display the "Rewinding Tape" dialogue box overtop of your progress bars when doing a single tape backup. This only happens during single tapes. No issues as of yet using the tape doubler.

Hi Evan
I'm having the same issue with the tape rewinding dialog. I usually forced Bru to shut down and overwrote the tape. I never tried letting it just sit on the initial tape. I'm in the process of lettign it roll now to see if it will create a usable tape.

Tape import tool is gone away as well which really irked me. I contacted support and they gave me the file. Without an extended support contract they won't even respond to you though.