Are RDX removable disks a good replacement for LTO tape?

Over a period of three weeks, I experienced six complete failures of LTO-1 and LTO-2 tape drives at client sites. Some had failed mechanisms. Others lost the ability to write reliably. These were HP Ultrium 232, 448 and 460 drives. Most of these units were deployed between 2006 and 2008, so the timing of the failures is right. The capacities (400GB) are correct for the applications. I replaced a couple of drives with equivalent devices, just for consistency. One server also had a SCSI HBA failure, further delaying recovery. At that point, the customer asked if there were any hard disk solutions available that would be better (or less-finicky) than tape.

As I began to look for replacements, I discovered that the RDX removable disk storage technology has been adopted by the major server manufacturers (HP, Dell, IBM). From my perspective, it looks like docked 2.5" SATA disks connected either internally or externally via USB2 in capacities up-to 1TB. Since these are actual disks, it seems like recovery and seek time would be reasonable. But I have a few questions about the technology in practice.

• Does anyone here use these drives with success? Is there anything to watch out for?
• What differentiates RDX from straight external USB disks?
• One of the advantages to tape in my application is that the drives have hardware compression. This helps immensely for the highly-compressive datasets I have to backup on Linux systems. Am I correct in assuming RDX relies on software compression?
• Since these are physical disks, are there any mountpoint issues in Linux or Windows? One of the nice things about tape is that its not a mounted filesystem and typically isn't affected by viruses, rootkits, system crashes, etc.
• In addition, I watched a primer on using RDX with Cactus Lone-Tar, and cringed when I saw them using a mkfs command to create a filesystem on the RDX drive at /dev/sda. Is there any chance of device renaming/reordering (from adding a SCSI controller, inserting a USB key, etc.), or will the docking unit persist at a particular device name as you swap drives?
• Are the backup speeds of 30 megabytes/second accurate?

I'm curious, as this could be an interesting alternative. The series of tape drive failures came at a time where it makes sense to reevaluate other options before moving forward.

I looked long and hard at RDX drives and specified the embedded RDX units in a couple of Fujitsu servers I bought. Here's what I found:

1. Microsoft native backup does not play nicely with RDX, because of the status of removable drives in MS disk management. As a result if you run Windows native backup (e.g. 2008 r2) you cannot send incremental backups to an RDX, only one-off full backups. If you want any nuanced handling of the backup you will need to write scripts.
2. Ditto Microsoft Data Protection Manager does not recognise RDX, which is a shame because DPM is great even for small MS shops who might benefit from RDXs.
3. Some people suggest a product called Firestreamer which lets you use RDX with DPM, but it's expensive and I found it to be a real pain to use and configure.
4. I wanted a portable solution for both offsite recovery and archiving. RDX is okay for offsite recovery but for archiving the cost doesn't work. By archiving I mean taking point in time snapshots of the state of data (say every week or month) so that if I corruption is found then you can go back to the previous state.
5. I bought about 4 300GB RDX drives at list price, but then around 12 120 GB drives on Ebay. This gave me enough drives to rotate media offsite, play with full system restore etc. for a small installation
6. I have to say, that I never enjoyed restoring from RDX - times are about 20-30 MBps for the USB 2 version. You can get a SATA version which will make a slight improvement, or now a USB 3 version which do a lot better. If you are restoring images, the USB 2 version takes a long time. What I did like though was the fact that you could store a backup VHD on the RDX and boot that from the OS. I did this to restore a Hyper V virtual file server when its host disk became corrupted.
7. I was waiting for Tandberg to release the RDX Quickstation autoloader, which there were rumours of at the beginning of 2010. Eventually I got fed up with waiting and bought Fujitsu LTO3 tape autoloader. This gives me loads of capacity, fast restore, no messing about with software issues, and cheap media. Also, backup software understands tape media rotation in a way that I never experienced using RDX.
8. Tandberg have now released the RDX Quickstation and it looks pretty good - I like the fact that it uses the iSCSI protocol with an LTO3 tape emulator, because this means that it will work with virtualised backup software (which generally needs an iSCSI target to backup to tape, because most virtual systems do not give the virtual machine access to a host SCSI port or whatever you need to connect to a tape drive.) Although I like the look of it, and RDX drives are pretty good to handle, and it has speeds of around 70 MBPS, I'm still stuck on the fact that RDX drives are expensive. If you are just rotating 8 RDX drives then you're probably cool, but if you want to archive then you're not.

This is a very late answer to this question, but one big difference between using hard disks (in general) vs. tape is the durability of the media.

Tape is likely to last a long time if stored properly. I've had data read from 20-year-old 34x0 tapes without issues and the LTO claims are similar.

Hard disks sitting on a shelf, not so much.

Tape is also much more durable, e.g., during transport. A tape cartridge should be able to handle much more rough treatment than a hard disk if you're, say, sending by UPS.

Tape can be less expensive per byte also. At this writing LTO6 2.5TB tapes are about $30; bare SATA "desktop-grade" 3.5" 2TB drives are $80. Obviously, the tape drives themselves are quite expensive, so it depends on your volume.

These are not reasons to ignore removable hard disks as backup - but they are factors to consider.