Slow backups with Quantum SDLT600 tabletop drive.

[thecomputerguy]

I just put together a new backup system here at my workplace. Unfortunately, the performance has really left me disappointed. The specs:

 

PowerMac G5 (Dual 2.0GHz) with 1GB memory and 150 SATA drive. (1.5 years old)

Quantum SDLT 600 external tabletop drive. (NEW)

ATTO UL4S SCSI card with Driver 3.5.0 and Firmware 1.5.0 (NEW)

MacOS 10.4.5

Retrospect 6.1.126 with Driver Update 6.1.4.103

 

Retrospect reports a slow 322MB/min when I backup the internal hard drive with 1.4GB of data. Also noticed that the tape drive likes to see-saw back and forth while writing data. When I say "see-saw", I'm describing the sounds of the tape inside the drive as data is being written. To me, it sounds like the drive rewinds the tape briefly and then writes a little bit of data. Then it pauses for a couple seconds and repeats the same noise. It's not a constant "writing data" sound and it causes the backup to take much longer than I would expect.

 

I haven't changed any settings on the UL4S card yet and ATTO Tech support says I shouldn't have to. SCSI ID on the tape drive is 5 and it's properly terminated. System seems stable so far(1 day of testing)but is not meeting my expectations for the amount of money I spent.

 

Any ideas?

[thecomputerguy]

hmmm...Two weeks and no replies.

 

Well, how about these questions. Anybody else out there running Retrospect on a SDLT600 tape drive? What type of speed are you seeing in the log when Retrospect completes a backup? I've tried the SDLT600 with an ATTO UL4S SCSI card on both Mac and Windows XP platforms. Very similar performance across platforms when backing up the internal hard drives of each machine.

Macintosh 320-350MB/min

Windows 475-500MB/min

 

This equates to between 5 and 9MB/sec. So where's the speed I say? Shouldn't the tape drive be writing data around 50-60MB/sec?

 

Maybe this would help with the speed, I dunno, but is there a way to tweak Retrospect to use a 64K block size when writing data to the tape drive? That's the recommended block size according to Quantum and HP.

 

Anybody have any suggestions before I break down and pay dantz for a single-incident tech call?

[d4vyt]

Hi there,

 

Did you get this resolved at all?

 

The reason I ask is that I have a similar problem with a similar setup.

 

Mac G4 running 10.3.9 and Retrospect 6.1 with ATTO UL4S card connected and a Quantum Superloader 3 - the best speed I've managed to get from backing up local hard drive is 1,261.6Mb/minute which is only 21.02Mb/min - before that I could only get 613-736Mb/min which is 10.2 - 12.3Mb/minute. According to specs I should be able to get 64Mb/sec through to the tape drive!

 

I know our setups aren't exactly the same but they're not a million miles away and our problems seem to be the same, so I wondered if you managed to resolve this at all? If you did, would you mind posting it here so we could all benefit?

 

Many thanks in advance

 

Dave

[thecomputerguy]

Dave,

No, I haven't gotten this resolved. I've done a lot of testing to try and isolate the bottleneck. Backing up a 100BaseT Mac Mini to tape, I saw 5.7MB/sec. Backing that same client up to a file rather than tape, I saw 5.9MB/sec. Decided that maybe the 100BaseT connection was the limiting factor. SO, continue testing.

 

Backing up a new 1000BaseT MacBookPro to DLT, I saw 568MB/min which is 9.5MB/sec. That's the fastest I've seen yet. Something doesn't seem right to me as 1000BaseT ought to speed the data into the server and onto the tape much faster.

 

I also put the UL4S and Quantum SDLT600 drive on a Windows XP box running Retrospect 7.1 and saw a small increase in speed, but not near what I expected. The only time I've really seen some real speed is when I used a little utility from Hewlett-Packard that tests the SDLT600 drive by writing data in varying chunk sizes. Every time it finished the test, the HP utility reported a 57MB/sec transfer. The drive made some nice smooth writing sounds when undergoing the tests, so I know it can handle a fast data stream.

 

At this point, I'm going to have to accept the performance as is. Response here at this forum has really been disappointing and I haven't decided whether I want to spend the money and call EMC. Let me know if you uncover anything. I'd be especially interested in hearing about other UL4S/UL4D users and the speeds they are seeing.

[rhwalker]

Quote:

---

Response here at this forum has really been disappointing

 

---

It may just be that no one else has a configuration close enough to yours for the results to be meaningful. I hadn't replied for exactly that reason. Whatever, I've got a 2.0 GHz single processor Xserve G5 running Mac OS X Server 10.4.5 with an ATTO UL4D to an Exabyte VXA-2 1x10 1u PacketLoader (SCSI), connected to a variety of clients over 100BaseT, and the server has Apple's Hardware RAID card with two RAID 5 LUNs, one of which is part of a RAID 1 mirror (with a 10000 RPM SCSI drive) controlled by SoftRAID. Networked backup throughput varies depending on the type of files on the client. For example, for many small files, I see between 15 and 140 MB/min, and these are all rather slow (500 MHz) client iMacs. For local drives on the server, I see between 55 MB/min. and 400 MB/min., again, depending on whether it's a volume with many small files or lots of big files, and this server is pounded on continually for DNS and SMTP and AFP while backups are going on. The performance is really not going to change much until Retrospect has D2D2T (staging to a local disk, with tape backup from staging disk).

 

Right now, however, it's still fast enough so that we get our backups done in the allotted overnight window, even on full (new media) backups. That's all that matters to us.

 

But it's not productive to gripe about the lack of responses from those of us other users who decide that our configuration is not similar enough to yours to provide a meaningful response, especially when it looks like you are just gathering data rather than trying to fix a problem that is preventing you from backing up.

 

Russ

[thecomputerguy]

Russ,

 

Thanks for posting your specs and experiences. The performance of your system seems on par for the make/model of tape drive that you have. I wish that was the case for me and DavyT. Our tape drives should perform around 6 times faster than yours.

[rhwalker]

Without any disparagement intended of Retrospect, it seems positioned for the small business such as ours, not larger installations with high throughput needs such as yours. It may be possible for Retrospect to get higher throughput in a future version if/when D2D2T staging is implemented. But your needs might be better met with a product such as BRU (Tolis Group), whose throughput is higher in high-capacity, high-performance situations, and which is a more Unix-centric approach (with the good and bad of that). BRU has some shortcomings, be sure to check out what it can and can't do, but it does do high throughput and is reliable. Can't presently handle ACLs, can't back up the full range of clients that Retrospect can. They do have a free trial period. I think that Retrospect is a better fit for small business, but it may not be able to meet your high performance needs.

 

Regards, Russ

[impala]

my specs:

Apple PowerMac G5 Dual 2.7GHz (1 year old)

The only thing not factory stock is the ATTO card.

MacOS 10.4.2 (yeah, out of date)

 

1GB DDR ram (2x512MB PC3200U-30330)

2 of 380GB SATA drives (Hitachi HDS724040KLSA80)

 

Quantum SDLT 600 tabletop SCSI

ATTO UL4D SCSI controller installed into PCI-X slot 4 (the fastest slot).

ATTO driver 3.4.0

ATTO firmware 1.4.2f1 (yeah, it's not current)

no other SCSI devices.

 

Apple factory Fibre Channel card moved to PCI-X slot 3 from slot 4 (I think)

Fibre Channel is LSI

no Fibre devices

 

Retrospect Backup 6.1.126

 

This system is very plain. No screensaver, etc.

 

I only backup network clients, all MS WindowsXP, mostly notebooks.

I noticed that retrospect could not keep up with the SDLT when backing up the network clients. Even when backing up to the local file backup set, these clients usually average 220MB/min to 320MB/min. It's been so long since I've done a full backup of the local HD I cannot comment on that performance. I don't recall a problem though.

 

I just now did a "Backup Set Transfer" from a local file backup set (on the non boot HD) to a recycled tape in the SDLT. The file backup set was created with software compression, containing 55 sessions, 37 snapshots. About half the snapshots are WindowsXP boot partitions > 1GB. The remainder are user volumes varying from 200MB and up. half the sessions must have been small incremental backups, the others were full backups.

 

performance was: 1,493.9MB/minute for 353,891 files, 45.1GB; duration 31.11 (:19 idle/loading/preparing)

 

When it was backing up a large session with nothing else running, performance peaked over 1,550MB/minute several times.

 

I noticed that if Retrospect was not the active window, the see-saw slowdown episodes became more frequent. If I ran Activity Monitor, it became very frequent. Even so, Activity Monitor reported disk activity from 24MB/s to 35MB/s when Retrospect wasn't waiting on the SDLT. I didn't run Activity Monitor very long.

 

Retrospect is extremely sensitive to not being the active window, and to other background processes. This even though I'm running dual cpu and retrospect only uses a single cpu. Retrospect generally seems to be CPU constrained.

[impala]

I think you problem is either not enough CPU power, or too many busy background processes. Hard to tell, though.

 

Several years ago I tried using an AIT drive. I didn't know they were helical scan like DDS. Yeuch! The AIT was blazing fast for local HD. It didn't "see-saw" but it had a heart attack trying to backup network clients. Like running a VCR on slowmo for the whole movie, I guess. I salvaged an old DLT IV drive that handled the slow clients with it's "see-saw" as well as could be expected. This is why I chose DLT again when I had the opportunity to setup a new system. If you ever open the case of a running DLT and AIT, you'll see why DLT is so much easier on the media despite moving it faster. The DLT is a work of art! I don't know about LTO.

 

PROCESS: Here's what I think happens...

Everything is OK until the DLT buffer empties and it has to stop, reverse, prepare to continue. As you say "see-saw". Meantime Retrospect refills the buffer. Now, if the buffer fills before the DLT begins writing again, Retrospect has to stop filling buffer. "Please Wait". Retro now takes a nap while DLT gets writing again. DLT begins draining it's buffer, but Retro takes a bit to get going again. By the time Retro gets going full speed, the DLT buffer is nearly empty again. VICIOUS CYCLE cripples Retrospect much more than necessary. Both the DLT and Retrospect should use bigger buffers so that even if DLT has to do the "see-saw" cycle, Retro can keep filling the buffers and never take a "Please Wait" nap. Then you would have fewer "see-saws". Or, Retro could at least be ready the instant the buffer starts to empty.

 

I was wondering if the Windows Retrospect backup system had the same problem. Apparently so.

 

I don't blame the DLT for the "see-saw". The old AIT would pause/record quicker than the DLT, but was paused so much it wore out the media and it's heads.

 

It's ironic, but we would be better off with a slightly slower tape drive than our source so it wouldn't have to pause as often. But I got the biggest, baddest DLT so I could recycle backup sets as infrequently as possible and have fewer members.

[thecomputerguy]

impala,

 

Thank you for taking the time to post such a detailed account of your experiences with Retrospect. The performance of your network clients is very similar to mine(200MB-400MB/min) and leads me to believe that my backup system is probably running as fast as it can. After reading your post, I went ahead and put the SDLT600 in service fulltime and have had it running for 3 days now. Seems to be running well enough so that I'm gonna leave it alone for the time being. I still feel like there is a lot of performance left on the table, but I don't know where to find it. Maybe it's retrospects fault. Maybe not. Anyways, I've run out of time to spend on optimization and will just let it go for now. As long as it is able to backup all of my clients within a 24 hour period, then that's the most important thing. Thanks again...