Yet another temporary freezing problem, energy saving related, maybe

Question

I've followed uncountable suggestions about this issue, but none seem to be quite the same situation, and none of the suggestions I tried made any difference so far.
History: MBP 17" June/2009, 8GB RAM, 500GB Seagate with sudden movement protection, started life as 10.5.7, done at least three fresh reinstalls of SL. The problem was present on the second SL install (the one I really used in production for about a year), but I solved it somehow by following uncountable Google suggestions at the time. Didn't take not of the magic one, because the problem wasn't so predictable at the time, or I didn't know enough about it, and also because I only noticed the problem was gone after a couple of weeks of normal use. Unfortunately, some time ago my filesystem went nuts on a kernel panic and, though I was able to move things back in place from lost+found, a few things wouldn't work as they should, so I went for another fresh reinstall. After I started to use the new system the problem showed up again, but I haven't being able to find a fix for it again. Current system (10.6.4) and patches regularly updated, though I tend to delay a reboot to avoid putting together all my usual windows/applications in the correct desktop/spaces. Maybe the only continuously running extension I have is Growl, since I tend to more heavily use the Unix part of the Mac through MacPorts (latex, tcpdump, nmap, bash scripts, emacs and so on). Recently I installed M$ Office, but normally I prefer OpenOffice (does M$ Office install some sort of extension?)
Frequency: I'm almost sure it is triggered by something related to energy saving regarding turning off the screen, but it doesn't happen every time. When I'm giving a class, the machine runs on battery, the settings for screen off are shorter and if I take too long to generate some input (key press or touchpad action), the problem tends to happen. Interestingly, it's particularly more frequent when I'm giving classes:-):-), but it is happening even on my desk with power on. I'm inclined to think there's a "window of opportunity" for the bug to happen, maybe between screen dim and screen off (a few minutes?). My settings are currently at 15 minutes for the screen to go off, for both power adaptor and battery operation, but that's an attempt to lower the chances of this happening during class, which is terrible. They used to be at only a few minutes of inactivity.
Symptoms: if I try to do anything with the machine past some period of inactivity, maybe during that window I mentioned above, there's a high chance of the bug being triggered. The system responds quickly to clicking a window, but applications don't seem to receive the focus of attention; I notice that the window frame of an application doesn't get darker when I try to select it. On a Terminal, the prompt remains as a rectangular frame instead of a filled block (I use white characters on dark background), and no matter how much I try, I cannot give the focus of attention to the visible shell on Terminal, so I can't issue any shell command to try and find out things. Changing workspaces may happen, but at a very slow speed, maybe many seconds after issueing the command. Eventually the system recovers itself, usually after several minutes, and then all user interface events that I tried during the freeze were remembered and are played sequently as fast as the machine can handle, sometimes doing unwanted things in the process due to objects receiving the wrong action (some sort of desynchronization). The outstanding event that preceeds recovering is the screen being progressively blackened and then lit again, but not instantly as in moving the pointer to a hot corner. The screen transition happens during half to a full second, after which all queued events are played at the fastest possible speed. After that the system is completely normal. In the beginning I have hard-rebooted the machine, because I didn't know it would eventually recover itself. During class I also don't have the patience to wait for long (and neither do students:-)).
Solutions already tried:
- disabling sms through pmset. I know it has to be disabled with this particular drive, otherwise conflicts with the drive's own mechanism. It is currently off, and had been on for a while till I refound the suggestion through google.
- re-indexing Spotlight's DB. No change.
- fixing file permissions (I don't see any possible relation, but anyway...)
Don't recall what else is missing on this list, because I couldn't find a concrete suggestion for this scenario, so I believe that's about it.
It looks to be more frequent now, to the point that I decided to stop work just to write this long msg, in the hope that someone else may have seen such behaviour and have something new for me to try.
Thanks in advance.

Answer 1

The problem is that the initial backup is incredibly slow and hasn't worked yet. I right click on the dock icon and start the backup process which after working out what needs to be copied progress's in very slow erratic bursts.
It's hard to offer a definite solution. But there are some simple things you could try to improve the backup speed such as excluding TM backup disk from spotlight indexing (privacy tab in spotlight prefs), and excluding unecessary files and folder from the backup (e.g. applications) in TM prefs.