Jump to content

Performance expectations on Disk to Tape


bjo16

Recommended Posts

 

I have a Dell P-edge 2650 with dual 3.06 Ghz P-IV procs, 4 GB RAM and 5 10k RPM 73 GB HDDs in RAID 5 configuration with PERC 3/Di controller. I'm running RS Multiserver 7.0 with the 7.0.1.103 update. I've created a Disk Backup Set for data comprising about 230 GB of drive space. I'm in the process of duplicating that data to a Sony SDX-700C AIT-3 tape drive in an Overland Library Pro autoloader, both of which are on a different SCSI controller from the RAID.

 

The problem is that it looks like it will take longer going from local disk to tape than it did going from remote network machines to disk. Should I not expect more than ~350 MB/sec disk to tape speed in my configuration? I can't find any bottlenecks in the system EXCEPT for RS's use of memory. Even though there's ~3.0 GB free RAM, it's pagefaulting like crazy (1000+ faults/second). The disks are barely ticking (averaging 5% disk utilization time), the processor is at 2%, the work queues are empty, etc. There's certainly no hardware limitation anywhere in the chain. The slowest segment is the AIT-3 drive itself, which is still rated for 1,800+ MB/sec. I'm getting 17% of that...

 

This performance problem completely defeats the idea of going disk-to-disk-to-tape, as going from network clients to tape seems to be faster. Does anyone have any ideas of what could be slowing me down?

Link to comment
Share on other sites

Hi

 

First off, make sure you disable the windows drivers for the tape drive and autoloader in the Windows device manager. They can conflict with Retrospect's built in drivers.

 

Are you backing up lots of small files or a few big ones? Small files backup much slower than large files. I like to benchmark my systems using a few 1GB files to guage the maximum throughput.

 

Are you doing a snapshot transfer to tape? That is fairly memory intensive and can cause the paging you are talking about.

 

Thanks

Nate

Link to comment
Share on other sites

 

Windows drivers are and have been disabled. I'm backing up 40,000 files in that 230GB of stuff. Some (10%) of the files are large (> 1 GB), and those are the ones that get the ~350 MB/sec when I sit and watch it. I haven't even tried letting the thing churn through a section of the snapshot with 10,000 10k files in it.

 

I'm using the snapshot transfer to tape, yes, with all the verification and comparison options turned OFF. I understand it will be memory intensive, but there's something very wrong with an application that has 3 GB of free memory available to it paging that much.

 

Any other ideas?

Link to comment
Share on other sites

  • 3 weeks later...

Hi

 

Are these backup sets that were originally created with an older version of Retrospect?

 

Retrospect 7 has a new fast matching feature that may help. The catch is it only works with backup sets that were created with Retrospect 7.

 

The memory issue is not a clear cut as anyone would hope. Retrospect runs as a background thread. Windows limits the max memory usage of background threads to 2 GB. As a result Retrospect has it's own separate paging system that kicks in when a specified percentage of memory is used.

 

Thanks

Nate

Link to comment
Share on other sites

hi

 

i'm using dell dual 2.8 xeon. 2 gig memory RS v7.0 using overland lto2 library. Pretty similar spec to you and I'm getting up to 2500 MB/s (average about half that). Files are coming across a gig network from multiterrabyte raids with million(s) of files ranging in size from 100k to gigs. Using an old ait1 drive I seem to remember getting speeds similar to yours so there is something that is adrift with your system. I would look at the scsi config (try another card - try disabling the raid if you can -etc)

 

I do seem to remember backing up loads of fonts (tiny file sizes) did impact the performance.

 

What happens if you use NTbackup to backup the files.

 

si

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...