APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

SATA RDX backup cartridge report for BackupEDGE

I have been testing an internal SATA RDX drive, made by Quantum, in an IBM x-series 226 server with dual 3.0 Ghz CPU's, 3 GB of RAM, and dual 73 GB SCSI drives configured as a simple RAID 1. The Operating System is Red Hat Enterprise Linux 5.3, Microlite BackupEDGE version 03.00.03 with the RDX cartridge configured as a file system partition. I modified the retention time to be only 3 days, as I was backing up to the same cartridge, and wanted to verify that the program would automatically delete the oldest archive to make room. When we have a cartridge for each workday, I will extend that back out to 2 weeks.



   Backup performance :

SUMMARY - BACKUP
Serial Number          = demo1011
Date                   = Tue Nov 22 01:04:12 2011
Files Encountered      = 288530
Total Data             = 31.60GB
Data Written           = 31.87GB
Volume Left            = 114.53MB
Segments Used          = 32
Elapsed Time           = 00:34:04
Data Transfer Speed    = 93.838 GB/hr
                      = 1601.513 MB/min
                      = 27988485 bytes/sec
Exit Status            = 0

   Verification :

SUMMARY - BYTE-BY-BYTE VERIFICATION
Serial Number          = demo1011
Date                   = Tue Nov 22 01:40:13 2011
Segments Used          = 32
Data Read              = 31.88GB
Elapsed Time           = 00:35:58
Data Transfer Speed    = 54.419 GB/hr
                      = 928.756 MB/min
                      = 16231202 bytes/sec
Files Encountered      = 288530
Files Excluded         = 4
Files Modified         = 7
Files Not Checked      = 2
Special Files          = 21031
Verified Successfully  = 267488
Change Log             = /usr/lib/edge/lists/simple_job//changedfiles_system_mas
ter.txt
Status                 = No problems found
Exit Status            = 0
 

The time to backup on our current Iomega REV internal SCSI drive, with a similar amount of data, was 36:52, and the verify was 36:25. Admittedly, the current backup happens when the system has live user activity, but the users can really notice the slowdown when the backup/verify is active. I did login to the test system while the backup was running to the RDX drive, and it did not seem to slow down as much. This was probably due to the SATA connection being separate from the SCSI backplane for the RDX drive, whereas the Iomega REV is also a SCSI device. Setting up the RDX cartridge as a SharpDrive device was slightly slower, somewhere between 1 and 2 minutes slower overall.

Where the RDX drive really shines though, is on a Selective Restore. In essence, the RDX cartridge is a hard drive, so the access time for individual files is extremely fast. I restored one of our largest files (782 MB) :

SUMMARY - RESTORE
Serial Number          = demo1011
Date                   = Thu Nov 03 16:08:53 2011
Elapsed Time           = 00:00:40
Data Transfer Speed    = 109.793 GB/hr
                      = 1875.469 MB/min
                      = 32776199 bytes/sec
Segments Used          = 10
Data Read              = 782.69MB
Files Restored         = 1
Exit Status            = 0
 

Forty seconds is excellent. The same restore from our REV drive took over 28 minutes.

Performance aside, the fact that Iomega no longer makes the REV drives is what is making this decision for me. Also, the cost per Gigabyte on the cartridges is extremely low (320 GB for $112.75), and we are not limited to a cartridge capacity going forward. It will also be nice to have multiple week's worth of data on each cartridge. If a user was to mess up one of their files, and not realize it for a week or two, we would have them covered.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> SATA RDX backup cartridge report for BackupEDGE


3 comments



Increase ad revenue 50-250% with Ezoic


More Articles by © BillMohrhardt







Wed Nov 23 16:28:34 2011: 10225   BigDumbDinosaur

gravatar


Elapsed Time           = 00:34:04
Data Transfer Speed = 93.838 GB/hr
= 1601.513 MB/min
= 27988485 bytes/sec
Exit Status = 0

Verification :

SUMMARY - BYTE-BY-BYTE VERIFICATION
Serial Number = demo1011
Date = Tue Nov 22 01:40:13 2011
Segments Used = 32
Data Read = 31.88GB
Elapsed Time = 00:35:58
Data Transfer Speed = 54.419 GB/hr
= 928.756 MB/min
= 16231202 bytes/sec

Something looks odd with these numbers. Why such a large difference between the transfer rate during the backup and the transfer rate during the verify? Also, the elapsed times don't make sense given, the large difference between the transfer rates.

On the servers that we ship there's relatively little difference between the two, using SCSI LTO drives. For example, on our office file and print server the hourly transfer rate for last night's backup was 83 GB. The verify rate on the same machine was 80 GB and the elapsed times are within a few seconds of each other. We'd expect the verify rate to be somewhat slower due to the nature of the operation. But why such a big difference on your system?






Wed Nov 23 19:54:53 2011: 10226   BillMohrhardt

gravatar


Good question. It only seems to be on the backup/verify with the RDX cartridge where the transfer rates are so markedly different. On our current Iomega REV backups, the transfer rate on the verify pass is slightly better than the backup pass. I would sort or expect that. I will check the system logs to see if the machine with the RDX drive is performing other tasks during the verify, which may be affecting the performance. It seems unlikely though.



Wed Nov 23 20:26:24 2011: 10227   BillMohrhardt

gravatar


Actually, this appears to be a ratio math error in the Summary. On the backup, it should be 31.87 GB / 34.067 min, giving .9355 GB/min, times 60 = 56.13 GB/hour. The transfer rate is way overstated on the summary.
The Verify summary is much closer 31.88 GB/35.967 = .8864 GB/min, times 60 = 53.184 GB/hour. The verify pass is taking almost 2 minutes longer, to be sure, but the calculation of the transfer rates is using some incorrect numbers on the backup pass. I checked last night's backup & verify, and the transfer rate overstatement is similar.

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





What happens then? Is there a ticker tape parade and heartfelt thanks from the computer it has reached? No, my friends, there is not. The poor packet is immediately gutted, stripped of its protective layers and tossed into the hungry maw of whatever application (mail, a webserver, whatever) it belongs to. (Tony Lawrence)

There are two ways to write error-free programs; only the third one works. (Alan Perlis)












This post tagged: