DescentBB

I am trying to get an automatic backup set up for my wife on her laptop.

The backup drive is hosted on the Linux machine, and I have my stuff automatically backing up via rsync.

So, a while back I tried to get rsync going on her computer and was getting complete hangs... I couldn't figure it out, so eventually I gave up and didn't do the backups. I was pretty convinced that it was the rsync executable itself.

The other day she starts bugging me about her computer not being backed up (especially now that I have two drives and keep one in the fire box in case of a fire...) so I decide to give it another shot... this time with just scp. I got the script all set up and runnable, and behold, mid stream I get another total hang.

Some background info:

I completely wiped cygwin back when I gave up on rsync, and did a fresh install now when I tried scp
It's Window Vista home premium on a gateway craptop
I'm getting a total freeze... only way out is to do a hard-shutdown by holding the power button to a while
I'm only trying to copy the contents of her home folder


So, my latest theory is that it has to do with bad blocks on the hard drive. I've scanned the disk several times using the windows utility on startup, and haven't particularly kept track of the results.... could it be that windows has a bad blocks table of some sort that cygwin isn't respecting, and the crash is caused when the hard drive throws an error concerning it? I'm thinking that my next step ought to be to break out the disk recovery utilities and give the drive a good, solid scan to see what it tells me.

Anyone of you guys have any good ideas?

[edit]HD tune claims no bad blocks. I could try badblocks off of a rescue disk....

samba and windows backup. Windows locks files that are in use, and that's most likely where rsync is hanging up. Also, radically different time stamps and permissions, so if it did work, you be syncing everything, every time.

rsync/scp not understanding Windows' weird locking rules can't be responsible for OS freezes though. (If scp is just doing reads, then it shouldn't even be affected.)

I would continue looking to the typical hardware culprits, also looking at the RAM (try running memtest from a live CD overnight) or overheating issues. Have you looked at the drive's SMART diagnostics?

I could see a lockup occurring if/when it tries to copy any actively-used swap files. Are you just trying to copy c:\*, or do you have any rules in place to just copy needed stuff?

Update: I tried it with pscp, which I'd say is a bit more "windows native."

With pscp it just crashes the program, not the whole OS.

I'm copying the contents of the user's home folder.... so there probably are files involved that have weird locks on them.

I've tried in the past to restrict it to just files that I know I need... excluding all of the program data stuff. It hasn't helped.

It doesn't happen immediately... it happens after a while. Maybe my latest theory is that some kind of buffer is over-filling that has to do with the network traffic.

pscp seemed to be transferring the files at the highest rate, and it was crashing the soonest. Scp seemed slower, and caused the hard freeze later in time. Rsync is the slowest (because it's checking things along the way) and seems to be crashing the latest.

Flip's suggestion appears that it may be the best option. this one just seems to be a weird one.... all of my Google searching hasn't turned anything up so I guess I've got some kinda of odd case going on.....

Power properties, power scheme, advanced, check hard drive shutdown time when plugged in enter 0

Then Sleep 240

Check the basics first

rsync takes the fastest route to determine if a file has changed, one of the things it checks is to see if the owner/group differs between the source and the destination, by numerical comparison, which on linux is an integer.

windows uses uuids.

But still, how would an application comparing the wrong numbers freeze the OS?

Seems it might have to do with a file named FontsList.plist.... I'll investigate a bit more.

Hard locks that don't go away till you cut power usually don't happen because of software. It isn't impossible, but Windows should BSOD before that happens. I haven't seen a hard lock that I couldn't pin to faulty hardware since Windows XP shipped.

If you think it is the drive, pull it and image it from another computer. If that works, it isn't the drive.