Help! Can't backup current drive!

[LoopinFool]

I did this once before on an old Series 1 box with no problem.

I'm upgrading my HR10-250 by replacing the drive with a new 500GB drive.

My first step is to backup the current system, but I'm having a big problem.
I started a backup (with 'mfsbackup -f 9999 -9so hdtivo.bak /dev/hdb'). It printed out the message "Scanning source drive. Please wait a moment." It appeared to be scanning the drive (as per the HD access LED on my box). However, I let it run for well over two hours and it never started the backup.
I've done some more tests like no compression and sending the output to /dev/null, but it seems to be doing the same thing every time.

Please Help! Today was the perfect day to be without our TiVo, but I haven't even started copying the programming over yet, and that I expected to take hours. I thought the backup would at least start within an hour!

Thanks for any help with figuring out what's going on,
- LoopinFool

[LoopinFool]

OK, I found another post about using the hdparm command to enable DMA and 32-bit transfers on the hd devices.
Remarkably, they weren't enabled at first, but now are.

My current mfsbackup attempt sounded much better at first, but it's now back to the same blinking HD light and sitting at the "Scanning" prompt.

I'm going to go out for awhile and I hope it's done when I get back. Any ideas about how long is "too long" to wait for the scanning phase of a backup?

I guess if this doesn't work I'll give this all a try on our main computer with much newer IDE hardware. I don't think I have a FAT partition on its HD, though. I'll have to do some more HD juggling for that to work.

Thanks for any other ideas and help,
- LoopinFool

[HomeUser]

Backups without recordings should only take a few minutes mfsbackup taking a long time scanning the drive may be because of a failing drive or possibly a hardware conflict check your connections and cables. Does mfsinfo see the drive ok?

[LoopinFool]

Backups without recordings should only take a few minutes mfsbackup taking a long time scanning the drive may be because of a failing drive or possibly a hardware conflict check your connections and cables. Does mfsinfo see the drive ok?

Yes, mfsinfo sees the drive fine. Perhaps there are some hidden errors on the drive, but it seems to work fine in our TiVo.

I found a good thread on using dd_rescue here. If I can't get the mfsbackup/mfsrestore to work properly in the other computer I'll give dd_rescue a try. Since I'm copying to a larger drive, I'll have to expand the result. Plus, I don't get control over the swap space, but perhaps it's already 127 on the 250GB TiVo drive.

Another weird thing is that after running mfsbackup, all the DMA settings on the drive have been reset to 0, according to hdparm.

Thanks again,
- LoopinFool

[LoopinFool]

Once I had both large drives hooked up at the same time, I tried a normal mfsbackup|mfsrestore. It got through the scanning phase this time, but it was taking many seconds per MB to do the transfer!

I went ahead and started to use dd_rescue to do this. With DMA properly enabled (neither PTVUpgrade CD had it on by default on my newer computer), dd_rescue was going along fine at nearly 30MB/sec. I was pleased. I went to bed.

It got really, really slow again around the 132GB mark. It showed a current speed around 150KB/sec. No errors at all, though! I then tried to see what of the rest of the drive I could copy using dd_rescue. Starting anywhere above that 132GB location, it would copy 100 KB or so and then appear to stop.

So, it looks like once you access that part of my old TiVo drive (at least on the two computers I have here), it switches the IDE controllers into some super-slow
mode that's pretty much unusable.

I'm going to try the weaknees lba boot CD just in case it does better for some reason. Then I'm giving up for this weekend.

I guess future things to try would be: other IDE master/slave locations/settings, dd_rescue on knoppix, or mfstools while booted into knoppix. Know where I can find hints as to getting mfstools working that way?

I guess the TiVo/computer gods are against me this weekend...

Thanks,
- LoopinFool

[HomeUser]

It got really, really slow again around the 132GB mark. It showed a current speed around 150KB/secdd_rescue slows down when it hits the bad area of the drive. dd_rescue drops the block size down trying to get as much of the data in the corrupted area that can be read.

[LoopinFool]

Thanks again for all your help! The weaknees lba boot CD would just reboot when trying to start Linux (on my old machine).

I moved the drives around to different cable locations and got a backup to work on the old system. I've never had trouble with two hard drives set up as master/slave on one cable before, but that seemed to be the problem.

I started an mfsbackup/mfsrestore on the old computer, but it would take around 13 hours to copy with our recordings. I'm going to set up the drives the same way on our newer computer and see if it will go any faster. I bet it goes at least twice as fast.

I'll keep you all updated,
- LoopinFool

[LoopinFool]

Just to close down this thread with the final results...

As I said, the whole problem with doing the mfsbackup from my old TiVo drive was that I had it on the same cable with another hard drive. That's probably also what caused dd_rescue to "halt" in the middle of the transfer.

Once I got the original drive hooked up as slave with the CD-ROM drive (on the secondary IDE channel), with the other HD connected as master on the primary IDE channel, everything started working as expected.

It also made a HUGE difference when I connected the drives using 80-pin high-speed IDE ribbon cables to both drives in my newer machine. The old machine only supports UDMA33 (40-pin cables). The newer computer was no faster than the older one with a 40-pin cable hooked up to the original TiVo drive. But when I switched to all 80-pin cables, the mfsbackup|mfsrestore went about 3-4 times faster! I didn't think it would make that much of a difference with an older 5400rpm TiVo drive, but it sure did. Possibly a quirk with the Linux IDE driver on the PTVUpgrade CD. Same goes for needing to separate the hard drives.

So all's well, we have a 63-hour HD tivo (432-hours SD), and it's working fine.

Just don't have the 6.3 software yet...

- LoopinFool