[Don Pickett]

I'm in the middle of my first Time Machine backup and am seeing huge variations in write speed, everything from 0 K/sec to 60 MB/sec to a Firewire 800 drive. Most of it seems to be pretty slow, as in under 1 MB/sec, with brief spikes to fast speeds.

[CharlesS]

What I'd like to know is why it sometimes takes Time Machine almost 40 minutes to back up 3 MB of data. Sure, my iMac only has FireWire 400 (can't add 800 or eSATA because of no slots - thanks, Apple), but even with 400, it's kind of ridiculous, especially since TM runs every hour, and if it takes longer than a half-hour to backup, then it means TM is running over half the time.

Here's the log, for the skeptical:

[codex]12/14/07 5:43:38 PM /System/Library/CoreServices/backupd[45846] Starting standard backup
12/14/07 5:43:46 PM /System/Library/CoreServices/backupd[45846] Backing up to: /Volumes/Backup/Backups.backupdb
12/14/07 5:58:46 PM /System/Library/CoreServices/backupd[45846] No pre-backup thinning needed: 271.9 MB requested (including padding), 193.48 GB available
12/14/07 6:13:37 PM /System/Library/CoreServices/backupd[45846] Copied 28845 files (1.7 MB) from volume <hard disk name>.
12/14/07 6:14:40 PM /System/Library/CoreServices/backupd[45846] No pre-backup thinning needed: 270.2 MB requested (including padding), 193.48 GB available
12/14/07 6:17:36 PM /System/Library/CoreServices/backupd[45846] Copied 8145 files (957 KB) from volume <hard disk name>.
12/14/07 6:17:57 PM /System/Library/CoreServices/backupd[45846] Starting post-backup thinning
12/14/07 6:20:15 PM /System/Library/CoreServices/backupd[45846] Deleted backup /Volumes/Backup/Backups.backupdb/<computer name>/2007-12-13-174804: 193.48 GB now available
12/14/07 6:22:51 PM /System/Library/CoreServices/backupd[45846] Deleted backup /Volumes/Backup/Backups.backupdb/<computer name>/2007-12-13-164746: 193.48 GB now available
12/14/07 6:22:51 PM /System/Library/CoreServices/backupd[45846] Post-back up thinning complete: 2 expired backups removed
12/14/07 6:22:52 PM /System/Library/CoreServices/backupd[45846] Backup completed successfully. [/codex]

[Don Pickett]

I just got so frustrated I cancelled the backup. I'm seriously thinking of ignoring Time Machine and using Super Duper, but that could just be the frustration talking.

I have noticed that the Spotlight processes are running concurrently with backupd, and taking a lot of CPU. I wonder if that's the problem: Spotlight is indexing the info as it's written.

[CharlesS]

Originally Posted by Don Pickett 

I just got so frustrated I cancelled the backup. I'm seriously thinking of ignoring Time Machine and using Super Duper, but that could just be the frustration talking.

I cancel the backup all the time. It's a necessary first step in using anything that's performance-intensive, such as iChat's video chat feature. Otherwise, you can measure your performance in seconds per frame, rather than frames per second.

It wouldn't be so bad if there were a way to configure when Time Machine runs its backup. If you could set it so it only ran when you were either sleeping or at work, away from your computer, it wouldn't be nearly as bad. As it is, it feels like Apple must have only tested Time Machine on an 8-core Mac Pro connected to a 12,000 RPM hard drive via an eSATA card which is connected via PCI Express.

[Don Pickett]

Originally Posted by CharlesS 

I cancel the backup all the time. It's a necessary first step in using anything that's performance-intensive, such as iChat's video chat feature. Otherwise, you can measure your performance in seconds per frame, rather than frames per second.

It wouldn't be so bad if there were a way to configure when Time Machine runs its backup. If you could set it so it only ran when you were either sleeping or at work, away from your computer, it wouldn't be nearly as bad. As it is, it feels like Apple must have only tested Time Machine on an 8-core Mac Pro connected to a 12,000 RPM hard drive via an eSATA card which is connected via PCI Express.

Googling around I've seen people report problems with Spotlight and slow speeds, so I excluded the backup volume from Spotlight, as well as the actual backup file (Backups.backupsdb) on the drive and am running it again. So far it's better, with much higher average speeds. I don't know how well Time Machine works when the DB hasn't been indexed with Spotlight.

[goMac]

I honestly haven't had trouble with Time Machine speeds. It's the .Mac Sync performance that really bugs me...

[Don Pickett]

Originally Posted by goMac 

I honestly haven't had trouble with Time Machine speeds. It's the .Mac Sync performance that really bugs me...

What machine are you using?

[CharlesS]

Originally Posted by Don Pickett 

Googling around I've seen people report problems with Spotlight and slow speeds, so I excluded the backup volume from Spotlight, as well as the actual backup file (Backups.backupsdb) on the drive and am running it again. So far it's better, with much higher average speeds. I don't know how well Time Machine works when the DB hasn't been indexed with Spotlight.

The trouble with that is, I've already got my backup drive excluded from Spotlight in the Privacy pane. I imagine if I didn't, that massive 3 MB uber-backup (by 1985 standards) would have taken even longer than 40 minutes.

[Don Pickett]

Originally Posted by CharlesS 

The trouble with that is, I've already got my backup drive excluded from Spotlight in the Privacy pane. I imagine if I didn't, that massive 3 MB uber-backup (by 1985 standards) would have taken even longer than 40 minutes.

I can see that mds and mdworker are no longer taking CPU time, but the backup speed seems to be slowing getting worse. It was doing well, but I'm seeing more and more speeds under 1 MB/sec. WTF?

I would hate to think Apple has released a technology which is only useful with a dual core Intel processor, although I have no idea why processor selection would so effect backup speeds.

[Don Pickett]

Excluding the drive and db in Spotlight seemed to do the trick. Backing up 88 GB took about 2.5 hours.

[peeb]

Time Machine is never a problem in terms of performance on my powerbook, for what it's worth.

[besson3c]

Backups of large quantities of very small files are always pretty slow, and the copy speeds are unreliable.

It would be very interesting to test a TM backup vs. an rsync backup on the same home directory with no file changes just to test for overall scanning/comparison. Doesn't Superduper use rsync?

[goMac]

Originally Posted by Don Pickett 

What machine are you using?

Macbook Pro 2.16.

.Mac Sync always seems to eat up my CPU. It's not noticeable under normal use, but if I'm running something intensive...

[CharlesS]

Originally Posted by besson3c 

Backups of large quantities of very small files are always pretty slow, and the copy speeds are unreliable.

Yeah, but almost 40 minutes for 3 MB of files though?

[besson3c]

Originally Posted by CharlesS 

Yeah, but almost 40 minutes for 3 MB of files though?

Can't explain that, that's odd... It is worthy of note that the amount of data that may have changed is somewhat irrelevant though, as it still has to scan through your entire set of data to compare each file.

I often wonder how many backup schemes using rsync behind-the-scenes... I don't mean to sound dogmatic about rsync, but we backup 6 terrabytes of student email every night and it takes something like 6 hours (spread out across several partitions and several separate running processes). Rsync is a rock solid backup tool in terms of performance and reliability, and seeing as how Apple extended it to include support for OS X metadata it seems highly appropriate for Apple to piggyback upon this tool rather than reinventing the wheel. In my opinion, it is generally poor software design to reinvent the wheel when this is unnecessary.

How many files are on your system CharlesS? Have you ever counted them? Do you have Macports or Fink installed? Developer tools? Perhaps you might want to have the backup exclude these?

[CharlesS]

Originally Posted by besson3c 

How many files are on your system CharlesS? Have you ever counted them? Do you have Macports or Fink installed? Developer tools? Perhaps you might want to have the backup exclude these?

Yeah, I've got a lot of files, which is most likely the reason TM is so slow so often. I've also got quite a few things in the exclude list. Thing is, though, Time Machine is supposed to use the FSEvents database, so it shouldn't have to scan my whole drive to figure out what changed. And sometimes, it doesn't - I've had times where TM finished in only 10 minutes. Thing is, though, the 30+ minute backups occur way more often than they should, and because it does its backup every hour with no way to change that, what you have is that when TM is in one of its moods, it'll be running the majority of the time.

Now, if there were just a way to configure when TM would run instead of having it run every single hour...

[besson3c]

Oh yeah, I forgot about the FSEvents database. I guess this would explain why they likely didn't go with Rsync. There *must* be a bug with FSEvents then, because it should just tear through a backup every hour in under a minute.

[Don Pickett]

Originally Posted by besson3c 

Oh yeah, I forgot about the FSEvents database. I guess this would explain why they likely didn't go with Rsync. There *must* be a bug with FSEvents then, because it should just tear through a backup every hour in under a minute.

So far the incremental backups have been quick. But there's no reason to have sustained write speeds of 500 KB/sec.

[besson3c]

Originally Posted by Don Pickett 

So far the incremental backups have been quick. But there's no reason to have sustained write speeds of 500 KB/sec.

What do you mean?

[CharlesS]

Originally Posted by besson3c 

Oh yeah, I forgot about the FSEvents database. I guess this would explain why they likely didn't go with Rsync. There *must* be a bug with FSEvents then, because it should just tear through a backup every hour in under a minute.

Under a minute? I haven't seen that even once.

[besson3c]

Originally Posted by CharlesS 

Under a minute? I haven't seen that even once.

I know, neither have I, but I don't understand why this wouldn't be possible in theory. Normally a lot of time is spent comparing files in doing an incremental backup. Since this work has already been done, it shouldn't take 1 minute to transfer 3 mb of files.

Well, I guess the other expensive part of the operation is in creating a bunch of hard links, so I guess the operation should take the amount of time it would take to create 100,000 or so hard links + file transfer.

Just thinking outloud...

[Don Pickett]

Originally Posted by besson3c 

What do you mean?

My original attempts at having Time Machine back up my drive was very slow. I was getting long periods of write speeds less than 1 MB/sec, and sometimes the copying would stop all together. It wasn't until I disable the Spotlight indexing for the backup volume that I got anywhere near decent speeds.

[besson3c]

TM is definitely a 1.0 type solution. Maybe in the next version if will suspend Spotlight indexing until the backup is complete in order to minimize load spikes?

[Don Pickett]

Originally Posted by besson3c 

TM is definitely a 1.0 type solution. Maybe in the next version if will suspend Spotlight indexing until the backup is complete in order to minimize load spikes?

Could be. It took them a while to get Spotlight polished.

[CharlesS]

Originally Posted by besson3c 

I know, neither have I, but I don't understand why this wouldn't be possible in theory. Normally a lot of time is spent comparing files in doing an incremental backup. Since this work has already been done, it shouldn't take 1 minute to transfer 3 mb of files.

Well, I guess the other expensive part of the operation is in creating a bunch of hard links, so I guess the operation should take the amount of time it would take to create 100,000 or so hard links + file transfer

A big part of it seems to be checking whether the disk needs pre-backup and post-backup thinning. In my example above, it took 15 minutes for TM to figure out that it didn't need any pre-backup thinning. Personally, I don't understand why it can't just notice that the disk has 200 GB free and it's only copying 3 MB over, so it pretty much doesn't need any pre-backup thinning. But what do I know.

With that said, it does occasionally stall in the middle of copying files, or - more commonly - right near the end of a transfer, when there's about 70 KB left to go and the progress bar is at about 99%. This very well could be creating hard links, but even that shouldn't take the amount of time that TM tends to take in this situation. I don't have any idea what the thing is doing in there...

Originally Posted by besson3c 

TM is definitely a 1.0 type solution. Maybe in the next version if will suspend Spotlight indexing until the backup is complete in order to minimize load spikes?

I just hope we don't have to wait until 10.6 for it.

[pheonixash]

Wow, this is quite surprising to hear. I check Time Machine every couple of hours just to check whether its still working, since I never see the progress bar at all. It probably takes under a minute for me, and I have a decent number of files on my computer too.

[mduell]

Originally Posted by Don Pickett 

Excluding the drive and db in Spotlight seemed to do the trick. Backing up 88 GB took about 2.5 hours.

How sad is it that achieving 10MBps is considered fixed?

[krove]

Try backing up 300+ GB. What a nightmare. Why in the year 2007 does it still take so fracking long to copy this much data?

[besson3c]

It is the performance and lack of consistency in being able to do a network backup and have this data show up in the TM timeline that caused me to ditch TM.

I hope both of these problems are solved, because I believe that they are solvable.

[PaperNotes]

I turned off Spotlight indexing on my TM drive in the first place because I knew it would try to index it as soon as data was being written to it and I don't see the point of indexing a back up drive. It throws up nasty errors in the OS such as Open with... command showing several instances of the same application.

TM is also turned off all the time. When I want it to back up new data I click on Back Up Now. All manual with me in control.

[mduell]

Originally Posted by krove 

Try backing up 300+ GB. What a nightmare. Why in the year 2007 does it still take so fracking long to copy this much data?

Because Apple refuses to embrace eSATA: as fast as your hard drive (60+ MBps), cheaper than USB.

[Simon]

Originally Posted by krove

Try backing up 300+ GB. What a nightmare. Why in the year 2007 does it still take so fracking long to copy this much data?

It's getting better, just not quite as fast as HDD capacity increased in recent years.

S3200. Not more expensive than FW800 and faster than both eSATA and USB3 (maybe not on paper, but in real world tests you'll see USB3 will hardly get beyond 2 Gbps). Of course S3200 also uses the same connectors as FW800 which means no cable or adapter mess.

The real question is: When will Apple drop both FW400 and FW800 connectors in favor of simply a S3200 plug (plus a dongle for older FW400 plugs) on all Macs? If they aren't already certain about something like that they might as well give up on FW altogether and just let people suffer with USB2 (except for those that are savvy enough to go out and buy an eSATA card).

[JellyBeen]

It wouldn't be so bad if there were a way to configure when Time Machine runs its backup. If you could set it so it only ran when you were either sleeping or at work, away from your computer, it wouldn't be nearly as bad.

Charles, I wonder if you saw this little utility.

TimeMachineScheduler - 1.1
TimeMachineScheduler 1.1 software download - Mac OS X - VersionTracker

Works quite well. I have mine set to backup every 9 hours.
I wish we could also set at what time we want the backup too. Maybe this will be in a later version.

[Don Pickett]

Originally Posted by mduell 

How sad is it that achieving 10MBps is considered fixed?

Considering what I know about TM--that it's not just copying the files, but making hard links--this wasn't too bad.

Have to say now that the first backup is over the incremental ones are going by almost unnoticed. Every once and a while I look at the log files to reassure myself that backups are being made, and they are.

[Don Pickett]

Originally Posted by Simon 

If they aren't already certain about something like that they might as well give up on FW altogether and just let people suffer with USB2 (except for those that are savvy enough to go out and buy an eSATA card).

Apple won't drop FW because it's the defacto connector standard in the pro video world (it's the only connector) and Apple won't abandon a market in which they're the dominant platform. And, while I don't know as much about the audio world as I do video, I think FW is pretty entrenched there.

[mduell]

Originally Posted by Simon 

S3200. Not more expensive than FW800 and faster than both eSATA

1394c may beat 3Gb/s eSATA on paper, but in the real world I think eSATA will be ahead because the SATA-1394c conversion chips won't be able to keep up. Also 6Gb/s (e)SATA should be out Real Soon Now (tm).

[CharlesS]

Originally Posted by JellyBeen 

Charles, I wonder if you saw this little utility.

TimeMachineScheduler - 1.1
TimeMachineScheduler 1.1 software download - Mac OS X - VersionTracker

Works quite well. I have mine set to backup every 9 hours.
I wish we could also set at what time we want the backup too. Maybe this will be in a later version.

Nice. I was about to the point where I was going to start looking into writing something like that myself. Now it looks like I don't have to.

Thanks.

[JellyBeen]

Well, if you can improve on it and its anything like Pacifist in quality...I'll use yours in a heartbeat!

[Drakino]

Originally Posted by mduell 

Because Apple refuses to embrace eSATA: as fast as your hard drive (60+ MBps), cheaper than USB.

They don't do anything to stop it though. my eSATA adaptor on my MacBook Pro is working just fine. There are only a few handful of laptops with the connector built in anyhow, give it time to be adopted before saying Apple is refusing. Apple is also currently "refusing" to embrace FW3200, and 10GBit Ethernet and PCI Express 2.0, and DDR 3 RAM, and so on...

[CharlesS]

Originally Posted by Drakino 

They don't do anything to stop it though. my eSATA adaptor on my MacBook Pro is working just fine.

You mean other than not including slots to connect those adapters on any but their very most expensive machines?

[mduell]

IMO embrace means offer, not tolerate.

Originally Posted by Drakino 

Apple is also currently "refusing" to embrace FW3200

Unratified.

Originally Posted by Drakino 

10GBit Ethernet

Expensive.

Originally Posted by Drakino 

PCI Express 2.0

Any day now.

Originally Posted by Drakino 

DDR 3 RAM

No chipset support for any of the markets where Apple competes.

[jrt67ss350]

Originally Posted by CharlesS 

Under a minute? I haven't seen that even once.

Each hourly TM backup on my machine completes in about 20 seconds. I've never had a problem with performance of TM over a USB2 connection - not once. You can't even tell it's doing a backup except for the sound of the external drive. My machine is a MBP 2.2 C2D wth 160GB HD. The external hard drive I'm using is an old cheap SimpleTech 120GB USB2-only drive.

[Hal Itosis]

Originally Posted by Don Pickett 

Googling around I've seen people report problems with Spotlight and slow speeds, so I excluded the backup volume from Spotlight, as well as the actual backup file (Backups.backupsdb) on the drive and am running it again. So far it's better, with much higher average speeds. I don't know how well Time Machine works when the DB hasn't been indexed with Spotlight.

Originally Posted by CharlesS 

The trouble with that is, I've already got my backup drive excluded from Spotlight in the Privacy pane. I imagine if I didn't, that massive 3 MB uber-backup (by 1985 standards) would have taken even longer than 40 minutes.

Originally Posted by Don Pickett 

My original attempts at having Time Machine back up my drive was very slow. I was getting long periods of write speeds less than 1 MB/sec, and sometimes the copying would stop all together. It wasn't until I disable the Spotlight indexing for the backup volume that I got anywhere near decent speeds.

Originally Posted by PaperNotes 

I turned off Spotlight indexing on my TM drive in the first place because I knew it would try to index it as soon as data was being written to it and I don't see the point of indexing a back up drive. It throws up nasty errors in the OS such as Open with... command showing several instances of the same application.

 
As I tried to point out in the other thread (by besson3c), it doesn't matter if we enable
or disable indexing on the target Time Machine backup disk... because it will go ahead
and create one anyway. Have a look, list it out, take a measurement:

sudo ls -lAR /Volumes/yourBackupDisk/.Spotlight-V100
sudo du -sh /Volumes/yourBackupDisk/.Spotlight-V100

Long enough for you?
Big enough for you?


@Don Pickett:
I don't know exactly at what point you switched over, but... the first few backups are
definitely slow anyway, so it's not crystal clear if disabling the indexing was actually
responsible for the speed increase. But perhaps you're right. [idunno]

Anyway... I'm not trying to dispute the speed issues. Just pointing out that there *is* an
index on the backup volume, and I doubt TM would function too well were it *not* there.

[Simon]

Originally Posted by Drakino 

They don't do anything to stop it though. my eSATA adaptor on my MacBook Pro is working just fine. There are only a few handful of laptops with the connector built in anyhow, give it time to be adopted before saying Apple is refusing. Apple is also currently "refusing" to embrace FW3200, and 10GBit Ethernet and PCI Express 2.0, and DDR 3 RAM, and so on...

I think it's also to point out that eSATA and something like FW800 or even better S3200 do not exclude each other. They are geared at different applications. SATA is the native HDD connector so eSATA will always have the bridge advantage over FW when it comes to HDDs. S3200 (plus possibly a FW400 dongle) OTOH is and will remain the native way to connect digital video and audio equipment. It will also be the proper way to connect disks or AV equipment that is more than 2m away since it supports much longer cable lengths than SATA. Just like nobody wants to replace FW800 with Gigabit, it makes no sense to want eSATA to replace something like S3200 or the other way around.

We already have eSATA possibilities on pro Macs. Where it's really lacking is on the iMac IMHO (I'll accept space considerations on the MB and mini). OTOH Apple finally needs to get real about FW if they don't want to dump it in favor of USB altogether. It makes no sense to use up space with FW400 and FW800 ports when all people need is the FW800 plus a dongle. In the future I'd want just two S3200 ports. The S3200 ports will connect directly to FW800 peripherals and a simple $1 dongle will also let you connect FW400 peripherals (just like we connect old VGA screens to DVI-I interfaces on our Macs).

eSATA and FW are good at different things and they certainly don't exclude each other (this is of course also true for USB2). Hopefully Apple will understand how to use them both to make the Mac a better platform. The last I'd want to see is USB2/3 being forced onto everything. Fortunately that won't happen soon.

[Don Pickett]

Originally Posted by Hal Itosis 

Anyway... I'm not trying to dispute the speed issues. Just pointing out that there *is* an index on the backup volume, and I doubt TM would function too well were it *not* there.

I removed my back disk from Spotlight's exclusion list after the initial backup was done. But turning it off did seem to make a big difference in initial back up speed, at least to me.

[CharlesS]

Originally Posted by Hal Itosis 

 
As I tried to point out in the other thread (by besson3c), it doesn't matter if we enable
or disable indexing on the target Time Machine backup disk... because it will go ahead
and create one anyway. Have a look, list it out, take a measurement:

sudo ls -lAR /Volumes/yourBackupDisk/.Spotlight-V100
sudo du -sh /Volumes/yourBackupDisk/.Spotlight-V100

Long enough for you?
Big enough for you?

Actually, it's not.

$ sudo du -sh /.Spotlight-V100/
2.0G /.Spotlight-V100/
$ sudo du -sh /Volumes/Backup/.Spotlight-V100/
300M /Volumes/Backup/.Spotlight-V100/

My Spotlight directory on my backup drive is only 300 MB, while the one on my boot partition is 2 GB. And that backup drive contains almost everything that's on the main hard drive (minus a few exclusions). It also includes a bunch of stuff from another partition of mine as well, so if anything, its index should be larger than the one on the boot partition if it's indeed indexing everything. Factor in all the various different versions of files in the incremental backups, none of which exist on the boot partition any more, and it should be much larger. However, it isn't - it's smaller by almost an order of magnitude. So no, I'm afraid that it is not "big enough for me."

[Hal Itosis]

Originally Posted by CharlesS 

Actually, it's not.

$ sudo du -sh /.Spotlight-V100/
2.0G /.Spotlight-V100/
$ sudo du -sh /Volumes/Backup/.Spotlight-V100/
300M /Volumes/Backup/.Spotlight-V100/

My Spotlight directory on my backup drive is only 300 MB, while the one on my boot partition is 2 GB. And that backup drive contains almost everything that's on the main hard drive (minus a few exclusions). It also includes a bunch of stuff from another partition of mine as well, so if anything, its index should be larger than the one on the boot partition if it's indeed indexing everything. Factor in all the various different versions of files in the incremental backups, none of which exist on the boot partition any more, and it should be much larger. However, it isn't - it's smaller by almost an order of magnitude. So no, I'm afraid that it is not "big enough for me."

 
Actually Charles... your HD's index is probably constipated.
3 gigs sounds suspiciously large. I'll bet you 50 cents it will
go much lower. Reindex your HD, and tell us by how much
it went down. Really. Do it. You'll thank me.

At any rate, 300 megs is MUCH larger than ZERO... which
is exactly what folks were believing until I said different.

According to most math, 300 megs is infinitely larger than 0 megs.

Percentage-wise.

[CharlesS]

Originally Posted by Hal Itosis 

 
Actually Charles... your HD's index is probably constipated.

At least it doesn't have halitosis.

3 gigs sounds suspiciously large. I'll bet you 50 cents it will go much lower. Reindex your HD, and tell us by how much it went down.

Just for giggles, I gave it a try and let it reindex overnight. It went from 2.0 GB to 1.3 GB, which is still over four times as large as the index on my backup drive, which once again contains more than just the files from my boot partition. I think we all know what this means - I'll be taking that 50 cents now. You can pay me at my PayPal address, which has "paypal" on the left hand of the "at" sign, and "charlessoft.com" on the right of it.

Really. Do it. You'll thank me.

Well, I doubt that, since I have absolutely no shortage of disk space whatsoever. 2 GB is nothing.

At any rate, 300 megs is MUCH larger than ZERO... which is exactly what folks were believing until I said different.

According to most math, 300 megs is infinitely larger than 0 megs.

Well, so is 5 KB, so I'm not sure what your point is there.

My guess is that the 300 MB is probably residue left over from my earlier pre-Time Machine backup on that drive.

[Hal Itosis]

Originally Posted by CharlesS 

My guess is that the 300 MB is probably residue left over from my earlier pre-Time Machine backup on that drive.

 
Yes... there has been a lot of guessing and assuming going on.

Just delete that "left over residue" then. Time Machine won't mind... right?
[do the modification dates of the index contents support the "residue" theory?
sudo ls -lAR /Volumes/yourBackupDisk/.Spotlight-V100]

BTW, did cleaning the HD's index speed up searches and backups?

[you're welcome ]

[CharlesS]

Originally Posted by Hal Itosis 

 
Yes... there has been a lot of guessing and assuming going on.

Just delete that "left over residue" then. Time Machine won't mind... right?

I don't think Time Machine is based on Spotlight. And if it did need that index, it would just rebuild it. After all, deleting the index and rebuilding it is the crux of what I just did last night.

[do the modification dates of the index contents support the "residue" theory?
sudo ls -lAR /Volumes/yourBackupDisk/.Spotlight-V100]

No idea, because last night was the last night I was at my apartment before flying home to visit the parents for the holidays. I wrote that last message just before turning off the computer and heading to the airport.

BTW, did cleaning the HD's index speed up searches and backups?

I doubt it, because it's been rebuilding that damn index every time I've rebooted into Tiger and back, and that hasn't changed anything any of those times. Plus, I've been struggling with Time Machine's speed issue ever since I was using the pre-release developer builds, and if reformatting the entire hard drive every time a new build came out didn't solve the issue, I doubt rebuilding the stupid Spotlight index would.