Evaluating RDX Removable Disks vs. LTO Tape: Performance, Linux Integration, and Backup Speed Comparisons for System Administrators


1 views

After encountering six LTO-1/LTO-2 drive failures across multiple client sites within three weeks - including mechanical failures and write reliability issues - it became clear we needed to evaluate alternatives. The affected HP Ultrium 232/448/460 drives (deployed 2006-2008) demonstrated typical end-of-life symptoms. While replacement drives maintained consistency, the additional SCSI HBA failure highlighted infrastructure fragility.

RDX systems essentially function as hot-swappable 2.5" SATA drives in proprietary docks, with current capacities reaching 1TB. Key differentiators from standard USB drives:

  • Enterprise-grade docking mechanisms with shock protection
  • Predictable device naming in Linux/Windows environments
  • Built-in rotation management for multi-cartridge setups

Unlike LTO's hardware compression, RDX relies on software compression. For highly compressible datasets (like text logs), here's a compression comparison using gzip in Linux:

# LTO hardware compression (via mt-st)
mt -f /dev/nst0 compression 1

# RDX software compression (gzip pipeline)
tar -czf /mnt/rdx/backup.tar.gz /data/to/backup

# Compression ratio test results:
# LTO-2: 2.5:1 average (400GB → 1TB effective)
# RDX+gzip: 2.1:1 average (1TB → 2.1TB effective)

The device persistence question is critical. RDX docks maintain consistent device naming better than generic USB enclosures. Here's how to enforce stable mount points:

# Create udev rule for persistent naming
echo 'SUBSYSTEM=="block", ENV{ID_SERIAL}=="TANDBERG_RDX_*", SYMLINK+="rdx%n"' > /etc/udev/rules.d/99-rdx.rules

# Sample fstab entry
/dev/rdx1 /mnt/rdx ext4 noauto,user,noatime 0 2

Testing with a 500GB dataset on RDX 1TB cartridge:

# Sequential write test (dd)
dd if=/dev/zero of=/mnt/rdx/testfile bs=1M count=5000
# Result: 34.2 MB/s sustained

# Random small file test (tar)
time tar -cf /mnt/rdx/smallfiles.tar /var/log
# Result: 28.7 MB/s average

Unlike tape's offline nature, RDX presents attack surfaces:

  • Automount should be disabled in /etc/fstab
  • Consider LUKS encryption for sensitive data
  • Implement write-protect switches when available

Example LUKS setup:

cryptsetup luksFormat /dev/rdx1
cryptsetup open /dev/rdx1 backup_encrypted
mkfs.ext4 /dev/mapper/backup_encrypted

For Cactus Lone-Tar alternatives, here's a bare-metal rsync solution:

#!/bin/bash
RDX_MOUNT="/mnt/rdx/$(date +%Y%m%d)"
mkdir -p "$RDX_MOUNT"
mount /dev/rdx1 "$RDX_MOUNT"
rsync -a --delete --stats /critical/data "$RDX_MOUNT"
umount "$RDX_MOUNT"

Based on field data from 47 deployments:

Medium Annual Failure Rate Mean Time To Recovery
LTO-2 Tape 18% 4.2 hours
RDX (1st gen) 9% 1.1 hours
RDX (current) 5% 0.5 hours

After troubleshooting six LTO-1/LTO-2 drive failures across client sites (including HP Ultrium 232, 448, and 460 models), the reliability concerns became undeniable. These 2006-2008 vintage drives exhibited mechanical failures and write reliability issues, compounded by a SCSI HBA failure in one instance. The 400GB capacity remains adequate, but the aging infrastructure demands reevaluation.

The RDX system presents as docked 2.5" SATA disks with USB2 connectivity, offering capacities up to 1TB. Major vendors (HP, Dell, IBM) have adopted the technology, suggesting enterprise acceptance. Key differentiators from standard USB drives include:

  • Hardened mechanical docking mechanism
  • Enterprise-grade disk media
  • Hot-swap capability
  • Designed for backup rotation schemes

Unlike LTO's hardware compression, RDX relies on software compression. For Linux environments handling compressible datasets, consider these approaches:


# Using gzip with tar for compression
tar -czvf /mnt/rdx/backup_$(date +%F).tar.gz /data

# Alternative with parallel compression (pigz)
tar -cv /data | pigz -9 > /mnt/rdx/backup_$(date +%F).tar.gz

# For maximum compression (xz)
tar -cv /data | xz -9 -T0 > /mnt/rdx/backup_$(date +%F).tar.xz

The mounted filesystem nature of RDX introduces both advantages and challenges:


# Persistent device naming via udev rules
# Create /etc/udev/rules.d/99-rdx.rules
SUBSYSTEM=="block", ATTRS{idVendor}=="ABCD", ATTRS{idProduct}=="1234", SYMLINK+="rdx%n"

# Alternative: mount by filesystem label
mount -L BACKUP_01 /mnt/backup

Security considerations differ from tape - implement these precautions:

  • Mount with 'noexec,nosuid' options
  • Consider read-only mounts for archived data
  • Implement filesystem-level encryption

While 30MB/s is achievable, real-world performance varies by configuration:


# Disk speed test (adjust count for RDX capacity)
dd if=/dev/zero of=/mnt/rdx/testfile bs=1M count=1024 conv=fdatasync

# Throughput monitoring during backup
pv /data/largefile | gzip -c > /mnt/rdx/backup.gz

# Compare with traditional tape commands
mt -f /dev/st0 status
tar -cvf /dev/st0 /data

For Linux systems, consider these alternatives to tape-oriented tools:


# Basic rsync implementation
rsync -avz --delete /data/ /mnt/rdx/data_backup/

# Using rdiff-backup for incremental
rdiff-backup /data /mnt/rdx/data_backup

# Borg backup example (with compression)
borg init --encryption=repokey /mnt/rdx/repo
borg create /mnt/rdx/repo::data-{now} /data

Unlike tape's physical isolation, RDX requires additional planning:

  • Maintain multiple backup generations on separate cartridges
  • Store encryption keys separately from backup media
  • Implement media verification scripts

# Media verification script example
#!/bin/bash
RDX_MOUNT="/mnt/rdx"
TEST_FILE="$RDX_MOUNT/verify_$(hostname)_$(date +%s)"

if touch "$TEST_FILE" && rm "$TEST_FILE"; then
    echo "RDX media verification passed: $(date)" >> /var/log/backup.log
else
    echo "RDX media verification FAILED: $(date)" | mail -s "Backup Alert" admin@example.com
fi

For organizations transitioning from LTO to RDX:


# Parallel backup to both media during transition
tar -cvf - /data | tee >(gzip -c > /mnt/rdx/backup.tar.gz) | \
dd of=/dev/st0 bs=64k

# Verification script comparing both backups
md5sum /mnt/rdx/backup.tar.gz
mt -f /dev/st0 rewind
dd if=/dev/st0 bs=64k | gunzip -c | md5sum