- Thread starter
- #21
Tim Jones
Well-known member
- Joined
- Dec 16, 2008
- Messages
- 316
- Reaction score
- 0
- Points
- 0
- Location
- Huntsville, AL, USA
- Website
- www.productionbackup.com
Around what I expected.
LE's UI is based on an older threading model and only two threads are being used. PE is much more optimized in this area.
Session recognition is on by default and others have asked for an option to disable it. That will be included in 2.0.1.
As for Doubler Archival mode, so long as you're using SAS or Fibre-Channel, you'll get very close performance to a single drive's numbers. Again, PE has been optimized to use threads more effectively. The only issues would be trying to use two LVD SCSI LTO-4 drives on the same SCSI channel as that would saturate the LVD-320 bandwidth.
That is correct. Depending on the file sizes and block sizes used, BRU will add 12% to 18% to the final archive size.
And, what is the performance hit if you run the Windows tools and not include the Unix and Mac-specific metadata details of your environment (I realize what you say below)?
Well, for one - you can't write to tape using tar under OS X.
As to the requirement for two copies - that's why Doubler Archival Mode is a simple checkbox choice. Check, Drag, Drop, Click - insert two tapes and you're done (unless you need more space than one tape
). And "hopefully" isn't a word we use with restores. Any issue that occurs in a tar archive can cause the entire restore operation to abort, not just result in the loss of the corrupted data. It's because tar doesn't like "glitches" mid-stream and tells you so by simply aborting at that point. As to what BRU does differently, we do not add ECC or other redundancy to the data stream, so we don't "rebuild" corrupted data. Rather we write the data so that we can recover from such an error in a way that allows the additional data to be restored beyond the data corruption point. It's not just about something going wrong during the backup, but also something going wrong during the restore.We're not trying to push anyone to move to something they can't use or don't need, so I would be the first to tell you that if your Windows solution is working for you, don't change horses mid-stream.
Actually, PE is much easier to use than LE. It was designed for exactly the purpose you describe - drag, drop, click. Are you saying that you think LE is easier that that?
As to BRU Server 1.2.0 and the PPC/Intel issues, note that the 98th percentile of our BRU Server customers are backing up data across a network - and of those, only 62% are reporting using 1GbE. Therefore, the PPC built tool running under Rosetta is not the bottleneck as the server process is spending the bulk of its time waiting for the data stream from the networked systems. Additionally, since BRU Server will happily make use of that retired 1GHz G4, a lot of our Mac customers are re-tasking otherwise useless PPC hardware for use as their backup servers. In that case, no performance hit at all. This is why there isn't a true discrepancy between what I said and what support are saying.
As for encryption, drive-based encryption is fine if you will only ever access the media using the original tape drive. As part of the PE 2.1 and Server 1.3 enhancements, each will include software-based encryption that uses a block cipher and key rather than a stream cipher like AES. With AES and similar stream encryption methods, the more data you archive, the lower the difficulty in potentially breaking the cipher. Because BRU's software encryption uses a block-based cipher, the key rolls with every block, so the encryption is as strong in the 10^12 or 10^21 block as it is in the first block. Also, using software based encryption allows you to handle the data on any compatible tape drive so long as the encryption key is known. For delivery and offsite archival, using drive-based encryption means that each drive must use the same key to access the data on the tapes. As for performance, we use assembly code on all platforms except PA-RISC and achieve over 600MB/sec throughput using fully randomized data.
