View Full Version : Troubles

11-30-2005, 10:38 PM
Hi. I got a new 300 gb HD for backup of my 80 GB Mac Mini. It is USB2, external (obviously, for a mini.) I have it connected through a dedicated 4-port USB2 hub which in turn is connected to one of the ports on the mini. The other port goes to my KB, then my mouse.

The mini itself is running OSX 10.3.9, latest patches from Apple. I bought it 31 (yes, thirty ONE) days before Tiger was released, so Apple won't upgrade it to Tiger. I, in turn, won't turn it into a $100.00 more expensive machine.

So anyway, I chose SuperDuper as the backup tool, seemed nice. Indicates it'll run under 10.3.9, so that's good. I paid, it's registered. Then I try a backup. Erase, then copy. Not the smart option, just kill the drive, then copy.

SuperDuper begins to back up, then slows down, slower and slower, until it is apparently not doing anything any more. I get about 18 GB saved of 36 GB which actually needs to go. I am using the erase then backup option. This takes many hours. SuperDuper reports about 300,000 files (!?) to back up. I know I've put maybe ten thousand files on there, at least 4,000 jpegs, since I bought the machine (hence my itch to back it up!) TOP reports there are stalled threads; I presume this is the disk-writing portion of SD, yes? No? I kill SD. The drive light is red (means it's writing.) It won't go out. I have to physically unplug it, OSX tells me I'm an idiot and I should have ejected (but of course, I can't, the drive is paying no attention to me, attempts to eject result in declarations that something is using the drive) then I plug it back in, OSX fixes (presumably) the drive as the light goes green, then red, then the drive mounts and goes back to green (I am using the journaled filesystem because I'm a coward.) If I select smart backup at this point, it quickly determines that it has about 18 GB of files on the drive (takes maybe 5 minutes) and then it immediately jams up again with a red light on the drive, same deal. No more files are going on there, apparently.

I have killed everything prior to the backup. Nothing is running but Finder, superduper and whatever system stuff usually happens. Let me put it this way: Nothing but SD and Finder on the task bar have arrows indicating they are running during the backup. I have a gig of ram, which I know is mostly free, unless SD is using it all. I think this other info is irrelevant, but just in case, the mini has bluetooth and wifi and the faxmodem as well as the 80gb drive and 1.42ghz cpu.

Plugging this same HD into a PCs USB2 port, it can be formatted, copy 50 gigs to it no problem (different filesystem so no assurance it's going to the same location on the HD) and the surface scan, running overnight, detects no problems with the drive. Copying 50 gigs to the drive takes about an hour and a half or so.

The Mini, up until this backup exercise, has been uniformly well behaved. Nothing else appears to be wrong.

So. Please do some finger pointing for me. The Mini? SuperDuper? The drive? The hub? Bad files on the Mac? Aliens? George W. Bush?

I know a bit about linux, I realize the mac isn't linux but is somewhat similar here and there, but I don't know where to look or what to look for other than what I've described to you.

I am, as you might imagine, a bit frustrated.



11-30-2005, 10:43 PM
I'm using S-D 2.01 v76.

Sorry. All that text and I didn't give you the version. Duh.


11-30-2005, 10:50 PM
Did you actually back up directly to the drive, or to an image stored on the drive?

11-30-2005, 10:53 PM
I used the option the program comes up with, which is, erase, then copy, initially. Then, I modified the options to use smart, so it would only copy new files (I was hoping to get it done incrementally at that point) and it read what was there then jammed up. At that point, the end of log is:

| 11:34:16 AM | Info | /
| 11:34:19 AM | Info | /cores
| 11:34:19 AM | Info | /usr
| 11:34:55 AM | Info | /Users
| 12:59:02 PM | Info | User terminated processing of transcript...

11-30-2005, 11:06 PM
Yes, but was it directly to the USB drive, or to an image?

If directly to the drive, please plug the drive directly into the USB port, and not into a hub... let's try to simplify this as much as possible.

12-01-2005, 01:15 AM
I used the default, so it went right to the drive, not to an image. I never even saw the option to save to an image, though I understand where it is now. Though I still would have picked this, as it says it's faster than writing to an image. When you look at the 18 GB it writes to the disk by opening the drive in finder, you can see the user folder and various folders inside that folder, and so on. Not a .DMG file or anything like that. Just a standard folder with my stuff in it.

I'll give it another shot tomorrow, and I will take the hub out of the picture. Right now, it's running another long surface test on a PC (and doing fine, so far.) The KB and mouse will work through the hub (in fact, everything I've ever tried will) so if I have to dedicate one of the mini's two ports to the drive, I can do that.

Thanks for the speed of your responses. More tomorrow.


12-01-2005, 10:40 AM
OK, good. I want you to write directly to the drive, and wasn't sure, based on your comments, that you were. (It's quite common that USB drives come formatted as FAT32, and Tiger will even format as FAT32, so you could end up with a drive with a 4GB file limit.)

Anyway -- I don't think the issue is the drive surface, though it's possible. I'd recommend an erase-and-zero (of free and used space) on the Mac, rather than a test on the PC, to actually test, though.

12-01-2005, 09:52 PM
Ok, I have the drive re-attached to the Mac Mini, directly, no hub. Currently, it is writing the 8x sequence of random values to the drive. Looks like this may take a loooooooooong time, so I hope to post tomorrow that it all went well.

All the PC tests went ok, including a backup of 200 gigs down at our local radio station (on PC, so again, can't presume the surface was used the same.) But that and the two surface tests went fine. If the random write goes ok, I will go back to trying SuperDuper, feeling fairly certain that the drive and the connection to the drive are ok.

12-02-2005, 12:29 AM
OK -- let me know what happens.

12-02-2005, 03:00 AM
Using the por on the mini instead of the hub, copy rates are reported as 9.69 mb/sec instead of 0.85 mb/sec. So the hub... the hub is a bad idea. :) It took only about 35 minutes to get to 18 GB instead of hours and hours.

But the bad news is the backup stops in the same place, at 18.08 GB, with drive locked on write (LED is red.) It's been sitting with the same reading, 18.08 GB, 36,035 of 318,631 files evaluated, 32736 files copied (that's suspiciously close to 2^15th, isn't it? Accidentally use a short integer, perhaps?) 18.08 GB evaluated, 18.08 GB copied.

Still copying right to the drive, still using erase then copy, not smart version.

Your thoughts?


12-02-2005, 09:15 AM
Don't worry, we're not using a short integer. (Seriously -- the standard OSX installation has an awful lot of files, and we'd fail on everything -- one of our standard test systems has way over 1M files.)

I'd check, with "sudo lsof | grep "SDCopy"", to see what file's being read/written (it'll likely be close to the last one listed). My guess is that there's a file there that's being constantly updated, and when we copy it it looks larger than it really is. (See the User's Guide on Troubleshooting for a description of this.)

Let me know if that helps -- and yeah, USB hubs with USB drives are definitely a bad idea. :)

12-02-2005, 02:35 PM
Ok. I ran SuperDuper with smart, because I know that it'll hang trying the same file.

I enter the command string to look for open files

The file it is stuck on copying is vk.mpg, which is a large mpeg movie, about 8.08 gigabytes (specifically reported as 8,679,608,945 bytes) and which shows each time I look at it as having 38527 bytes copied, when I re-invoke lsof.

Is the file too large for SuperDuper? I know it's a good mpeg, I've watched it. So that means the file is ok, right? Or no? Is there a way I can test the file itself? It's not being updated, in fact I've not even thought about it for a month or so and have rebooted many times in the interim, so I can't imagine anything (other than SuperDuper) might have a lock on it or otherwise be fumbling around with it.

This file arrived via our network; it was captured on a PC from a videotape we made, then copied through finder to my machine. Any red flags there?


12-02-2005, 04:06 PM
The exact same thing is happening to me -- SD hangs at the same point -- no progress is made and the hard drives spin down.

- Paid version of SD 2.0.1 (v76)
- PowerBook G4
- Tiger
- WiebeTech ToughTech FW800 external drive (2 partitions, both OS X Journaled), FW800 direct connection
- Full erase/backup to dedicated partition

12-02-2005, 04:20 PM
There's no file size limit that I know of with SD!, Ben, although I don't think I've tested an 8GB file. We use a system call to copy the file (with two alternate paths should a failure be flagged). How long have you left it? It might take some time to copy.

12-02-2005, 04:21 PM
I believe you and I are dealing with your case in email, bdmcnitt, and I don't think it's at all the same thing. Clearly, Ben can quit, etc, whereas your machine went to sleep and you can't quit...

12-02-2005, 04:23 PM
...tracked the problem down to a particular file? You should be able to tell if you are having my kind of problem (appears to be a large file issue at this point) or a continuously updated file as described above.

There are some good suggestions a couple of posts back in this thread. What you want to do, I think, is run the backup until it hangs, then run the commands above (you'll have to enter your password) and then look to see if you can recognize one of your files in the list of stuff SuperDuper's SDCopy command has open.

I'm waiting to hear from someone about the large file for my case at this point, but I hope that helped you.

12-02-2005, 04:27 PM
I've left it sit overnight, about 12 hours. But that was when it was going slow. When I decided it had hung in the new, faster version, I had left it a few minutes. Took about 30 to get 18 gigs copied, then hung, apparently doing nothing, for about maybe between five and ten minutes.

I'll start it again, now (1:30), and check it when I get back from work, about 5. If it takes 30 minutes to do 18 gigs, I have about double that to do, so an hour is a reasonable, though loose, estimate. three hours should be more than enough. I'll let you know what I find out.

12-02-2005, 04:38 PM
My guess is it's going to take well over 5-10 minutes to copy 8GB, Ben. I'd definitely leave it and check the destination drive to see if, perhaps, the file is getting larger.

12-02-2005, 09:54 PM
Yes, you're right -- it takes quite some time to copy 8GB. And with that in mind, considering it was going so slowly before (through the hub), it was probably working then, too, but taking a day or two to do the file.

I did two successful complete erase, then copy (not smart) backups, then I reformatted the drive as two partitions (I only have an 80 GB drive in the mini) so I have a 100 and a 200, then did an erase then copy backup to the 100, and that went fine also. I've scheduled a smart backup for 5:30 AM every morning, and hopefully that'll be the end of my worries.

I thank you very much for your *wonderful* support. I'll be writing a review, and I will point you at it when it is up. :)

12-02-2005, 09:55 PM
Hooray, Ben -- congratulations on getting the job done!

12-02-2005, 10:00 PM
Oh, and to follow-up with Brian's case (the other user who came in on this thread indicating he thought he had a similar problem), his difficulty was a damaged directory structure. After running Disk Utility, his backup worked just fine.