APLawrence - Information and Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds Get APLawrence.com by RSS











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Home > BillMohrhardt > SATA RDX backup cartridge report for BackupEDGE
Printer Friendly Version




SATA RDX backup cartridge report for BackupEDGE




2011/11/22
Bill Mohrhardt

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.


If this page was useful to you, please click to help others find it:  

Your +1's can help friends, contacts, and others on the web find the best stuff when they search.

3 comments




More Articles by BillMohrhardt



Click here to add your comments





Wed Nov 23 16:28:34 2011:   BigDumbDinosaur
http://bcstechnology.net
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:   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:   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.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar


cartoon

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. We appreciate comments and article submissions.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.


My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide




 I sell and support
 Kerio Mail server
g_face.jpg

This post tagged:

       - Backup
       - Linux




Unix/Linux Consultants

Skills Tests

Guest Post Here