[Tim Jones]

As Neil states – there’s no where to put the Internal drive in a Mac Pro (regardless of model) as it won’t work without hacking the physical Mac case.

You would need an external chassis to hold the drive and they aren’t easy to come by.

I did find this unit that would get you where you need to be:

PTI SAS Enclosures Tape Drive 5.25 full-height open front

However, having said that, the IBM drive – when properly housed – will work fine with a Mac Pro and ATTO H680 HBA with BRU PE, BRU Server, PreRoll Post, or any other tape-aware OS X backup package.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

[Neil Sadwelkar] “During a LTO-6 (or even LTO-5) tape backup with the above setup (using BRU-PE), the Mac isn’t overly loaded so you can freely use it for any small task like browsing the web, checking your mail, doing your taxes. Just avoid doing something heavy like large Photoshop files, After Effects etc.”

Thanks, Neil. I’ll add to that and state that the overhead for running BRU PE on a modern Mac is so low that we actually have customers that continue to actively edit while backups are running. Between the UI and the background threads, BRU PE utilizes an average of ~18% of a single CPU core. And, because BRU uses shared, read locks with accessing your files, it will even backup files that are in use (with very few exceptions).

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

A new question has arisen about these drives in retail kits and the fact that you may have issues using the drive out of the box on a Mac system. Files will appear to copy, but they will either appear corrupt or fail to copy.

The normal cause of this situation is the fact that the manufacturers ship the drives formatted as Windows-compatible (MS_DOS, vFat, etc.). The way to fix this is simple – attach the drive to your system, open Disk Utility, Select the Device (rather than the partition), repartition it to a single partition and format it as “Mac OS Extended Journaled”. Important Note: This will delete any existing data on the drive.

The drive will now be properly formatted for use with your OS X system.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

We’ve been trying to get the vendors to stop promoting the compressed capacity for tapes for years. Even a highly mail or document-centric environment won’t see 2:1 (2.6:1 claimed on LTO-6). We’ve tested 100’s of environments from Windows desktops to Unix storage servers and the average that we see is closer to 1.6:1.

For media storage, they all need to drop the compressed values since the drives can’t compress this type of data any further. You’ll always see 1:1 (or a slight level of compression if your data contains PDFs or other business-side documents). You’re best bet is to assume 1:1 and then be excited if you get more than that onto a tape.

Fortunately, the compression algorithms used in the drives are smart and recognize when they can’t compress the incoming data stream.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

Tandberg Data’s RDX units are disk drives, not a tape drives.

You are correct that TB 2 offers no performance advantage over TB 1 for LTO tape.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

Hi Bill,

Thunderbolt 2 devices are backwards compatible with Thunderbolt 1 systems. There are a number of mechanisms that would provide either LTO-5 or LTO-6 solutions for your needs.

mLogic’s mTape is an option as are our (TOLIS Group) Thunderbolt bundles.

Do your research and be sure that you compare what you get for the money that you pay.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

Hi Dustin,

I can readily share with you that you will not be able to find a sub-$1,000 LTO-5 or LTO-6 drive unless it’s well used and probably ready to expire. Unfortunately, the manufacturing costs of these devices well exceeds $1,000 in most cases.

Having said that, I still recommend LTO storage for clients looking to do more than move files around. Most software used with an LTO solution will alleviate any user issues – for example, our BRU PE solution is as easy as dragging and dropping. And, for Premiere Pro 6 – CC, you can even archive by project.

On the other hand, Seagate has released some new, very high capacity disk drives designed for archival. These drives are much slower than normal drives (5900RPM), but are designed for storage of data where capacity is more important than speed. For example, Amazon has the 5TB external drive for $159 (https://www.amazon.com/dp/B00J0O5R2I/). While you definitely wouldn’t want to edit using this drive, it would definitely give you the space that you need to offload your existing data to clear space on your higher performance storage.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

Unfortunately, there is no such beast (PCIe Thunderbolt adapter) that works with the Mac… Plus, you would need an x4 slot as a minimum to properly support even Thunderbolt 1. You could use an eSATA card like the Sonnet Tech Tempo 2 port eSATA card which would allow you to attach 2 more eSATA drives.

To expand that unit further, you would either need to update the drives in your StarTech units to larger disks or upgrade them to native SAS drive enclosures with expander support so that they can daisy chain allowing more drives per SAS channel.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

[Tom Goldberg] “I don’t doubt that BRU checksums are better than SHA1 or MD-5, just that they are bigger and slower. I note that no one else seems to think it is worth the overhead. And by no one else, I include IBM, HP, Quantum, Oracle, Spectra, and so on.
“

Then you either did not fully read what I posted or are not understanding it – BRU’s in-stream CRC method is neither slower nor larger. In fact, it’s faster than MD5 and is in-stream rather than a sidecar to the process. An MD5 sidecar “file” is usually around 57 bytes each and requires a separate file entry in the data written (if they are included in the archive at all) while BRU’s 32bit CRC is 4 bytes and in-stream. You can’t “lose” BRU’s checksums, but you could lose the MD5 sidecar files that so many are promoting as “good enough”. As for speed, I’d love to see any tar or LTFS-based solution try to match BRU’s native CRC-inclusive I/O speeds while including all filesystem metadata, extended attribute information, ACLs, long paths, and full international character set support – even without including the MD5 sidecar files.

So far as mentioning hardware vendors, these companies aren’t responsible for what the software does with their devices. You attempt to imply that the fact that they don’t include such a solution is indicative that it’s not needed – two important points with regards to that:

• They don’t think it’s worth it because to do so would imply that their solutions are potentially prone to errors.
• Those that include software with their hardware provide software tools that are based on archive container formats that can’t provide in-stream checksums.

I can’t comprehend why you are having a problem following this point. They don’t offer or recommend it because they can’t. TAR, MTF (Microsoft tape format), NDMP, nor LTFS have a way to include the checksum mechanism within their formats without breaking the existing formats.

BRU has proven for more than 29 years to be as fast or faster, more reliable, more compatible and with broader platform support than any other solution (except maybe raw tar in that last point).

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!

[Tim Jones]

Apologies to readers as this gets a bit long winded.

[Tom Goldberg] “I stand by my statement that the only way to know for sure is a full restore and compare. I did not mean to imply that has to be done manually, automated means such as your Autoscan certainly meets that criteria. And I don’t dismiss checksum comparison as a powerful way to verify without a full restore – only that it should be done against the source data set. Copied data IS more likely to have bit errors going between hard drives than going onto tape.
“
Tom, that’s simply not valid and I suspect that you make that statement from never having tested BRU’s resiliency in this situation. Because BRU’s checksum is calculated as the data is read from the disk, it is as valid as the original data. If the original data is bad on the disk, it will be bad on the tape, but even a bit-by-bit comparison (which BRU also supports) or restoring that data to an alternate location and comparing the files will report the compared bad data as good – so your example is not a good one to promote or refute the reliability of any of these methods. And our AUTOSCAN pass is not comparing the data on the tape to the source data – it’s rereading each block, recalculating the CRC and then comparing the calculated CRC to the CRC in the header of the block.

On the other hand, this does mean that BRU’s checksum is a completely reliable mechanism for checking the validity of the data in the archive container. And, with BRU’s CRC mechanism and our Any Time Verify, you can verify AND audit a tape 6 months from now or even 10 years from now with no knowledge of the original data source, filesystem or platform, unlike what you state above about needing the original source data set. Everyone else uses MD5 checksums because it’s the only way for them to provide ANY sort of checksum; they can’t modify the tar, MTF, or LTFS formats to add stream-based checksums because it would break the interchange capability.

Comparing our in-stream CRC algorithm against an external MD5 (or an even stronger SHA1) file-based checksum is not even close. BRU calculates the CRC in the stream, not as a separate process or pass. Additionally, we have shown that the BRU I/O engine running on an OS X system with a high-performance RAID source drive is still not topping out BRU’s performance capability. We have sustained performance of over 3.2GB/sec using BRU to create archives of the data on the array (faster on other platforms where PCIe-3 is available). This is far faster than any modern tape drive can handle, so the overhead relating to speed is nonexistent using BRU’s methodology.

Also, BRU has no issues archiving data sets with extremely deep folder structures, folders containing 100,000’s of files, filenames with special characters or international languages, so the user does not need to modify their workflow to take those things into consideration. We have one customer that recently left another LTFS solution because rather than rework their international workflow to fit LTFS, they were using ZIP to create archive containers using generic names so that the data could be backed up to the LTFS format used by the other product. Then they realized that they couldn’t restore a single file without first restoring the ZIP container. They bought a lot of BRU licenses.

Finally, the ~18% overhead that BRU generates is not simply the CRC (that’s literally 4 bytes – 32bits per block), but also includes all of the other filesystem and low-level metadata that we save with relation to the file. Things that LTFS simply throws away.

Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!