Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

LTO backup

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
 
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.
 
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.
 
Last edited:
I just discovered that you guys have calculators to better estimate all of this. Great news!
 
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.
 
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.
 
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.
 
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.
 
Evan T Gervais said:
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.
Click to expand...

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.
 
We were using Retrospect for the past couple years with a Quantum LTO 4. HORRIBLE solution and not recommended to anyone. Run fast to Tolis Group.

We switched to an LTO 5 drive with Bru software and the difference is night and day. MUCH better solution for backing up media.

I don't like bashing products, but Retrospect deserves it when they went from V6 to V8 with no compatibility between them. I have about 40 LTO tapes that now need V6 and a very specific Mac OS. So I now have to keep a bootable drive with only the Mac OS and V6 available just in case I need old footage. Very dumb on their part. I can't imagine how angry people are that have 100's of LTO tapes that can't be read by the V8 software.

Bru rocks. Love it.
 
You must log in or register to reply here.
Back
Top