Stop Spotlight from indexing a mirror volume?

[jeffj]

I am trying out SuperDuper for my backup needs, but I am encountering an annoying issue. I want to mirror my HD to a partition on an external Firewire drive. When I use SuperDuper to do this, Spotlight indexes the mirror and I get duplicate items every time I do a search.

I have used the shareware application Spotless to disable indexing on the partition volume and delete all index files on all volumes. I then asked Spotlight to re-index, and STILL my backup mirror files show up in Spotlight searches. (Even though Spotless tells me that indexing is disabled for the mirror volume.)

I have read the FAQ posted here but am still confused. For example, the FAQ post says,

Now, open SuperDuper! In Options, there's a selection for a "Site Customization Script". Check the box, and select the "disable_spotlight" executable in the open panel.

However, I don't see the "Site Customization Script" check box on any screens. Do you mean "Run shell script after copy completes" check box in the Advanced tab options?

I would be very pleased if someone could give me a clear list of procedures to perform a mirror backup (Backup - all files, bootable) on a periodic basis using Super Duper and keep this volume from being indexed by Spotlight.

Thanks!

[dnanian]

Rather than doing that, please just add the backup drive into the "Privacy" tab in the Spotlight preference pane. That should do it. (Disabling indexing does not disable searching...)

Note that you might have to turn indexing ON -- otherwise, you can't add it to the Privacy tab. But, once added, as long as you're on 10.4.3, it'll stop indexing for that drive too...

[jeffj]

Thanks, it seems to be working. Your hint to turn indexing back ON seemed to do the trick; otherwise, I could never get the volume into the Privacy list for Spotlight! (And simply stopping the indexing did not stop the searching, as you said...)

To keep this setting, I've told SuperDuper not to copy the \.Spotlight-V100 file and to do a smart update each time. I'm keeping my fingers crossed, but so far I am a happy (and registered) user. Thanks again!

[dnanian]

Actually, Jeff, don't do the .Spotlight exclusion thing. We handle that folder automatically...

[jeffj]

Dear Dave:

I removed my custom script (that said do not copy the .Spotlight-v100 file)and am just doing a smart backup, all files. After an automatic smart backup of my disk today, Spotlight is again searching the backup and reporting on what it finds in that volume. How do I *keep* the backup volume out of the Soptlight searches? Do I need to run the script from the FAQ mentioned above?

Again, Thanks!

P.S. I checked and Spotlight reported that content indexing was disabled, and the volume was not listed under the Spotlight Privacy tab. Yeaterday, I had turned indexing on (waited patiently), then added the volume to the Privacy tab, then went back and turned indexing off (I think). Should I simply keep indexing on for this volume?

[dnanian]

If you place it the Privacy pane, Jeff, it should be kept out. You shouldn't exclude .Spotlight, though... that could cause problems.

Make sure that your drive normally stays in Privacy across a reboot. If not, you might need to remove the .Spotlight folder.

[jeffj]

Originally Posted by dnanian

If you place it the Privacy pane, Jeff, it should be kept out. You shouldn't exclude .Spotlight, though... that could cause problems.

Make sure that your drive normally stays in Privacy across a reboot. If not, you might need to remove the .Spotlight folder.

Everyhting working great now. I think the key was keeping the indexing on so that the volume stayed in the Privacy tab. Thanks, great product!

[dnanian]

Great, Jeff, and thanks!

[jeffj]

Oops, the automatic backup ran today and somehow turned indexing off the backup volume. Spotlight again showed two items for every search. After I used Spotless to turn indexing on, the volume magically appeared in the Privacy tab and was not searched. Is there a script I can have SuperDuper run to make sure that indexing is turned on the backup volume after it has been updated?

Sorry to be troublesopme on this isssue!

[dnanian]

Just make sure that your "after copy" action isn't running disable_spotlight, Jeff...

[jeffj]

Well, now SuperDuper has performed several smart updates with Spotlight not searching the backup volume, so I think everything is working fine, Again, thanks for your help!

[dnanian]

Great, Jeff. Thanks for the follow-up.

[sjk]

I'll piggyback on this thread since it's related to my Spotlight issues with SD! ...

I clone a startup volume to an external FW backup volume and haven't been able to reliably stop Spotlight from reindexing that backup volume if it's been dragging to the Spotlight Privacy prefs per instructions posted here. For awhile it worked fine, even after unmounting/remounting the backup volume and system restarts, but yesterday the indexing happened when the volume mounted (and obviously it was gone from the Privacy prefs). Previously I'd ran the disable_spotlight script after cloning, which was 100% reliable for what it did.

It doesn't matter (much) to me if the backup volume has a copy of the startup volume's Spotlight index or none at all. If I ever do a full restore I'd mostly expect to reindex the volume afterwards anyway. As I understand it, certain Spotlight metadata (e.g. kMDItemWhereFroms, set with Safari downloads) is lost when reindexing. However, if a Spotlight index is preserved during cloning, and not reindexed, would that metadata survive? I know its lost simply by copying/moving files between volumes but if there's some way to preserve it using a full SD! volume backup/restore strategy that would be ideal.

Hope that makes sense. Any suggestions are appreciated. Thanks!

[dnanian]

This is the kind of thing that Apple is going to have to define better before we can improve our support, Scott... there's little we can do at present, unfortunately.

At some point we're going to be able to preserve things on a destination volume. But that still won't help if Privacy doesn't work reliably.... and it's unlikely that preserving metadata will resolve any kind of issues with kMDItemWhereFrom, because the paths change, so the metadata gets rebuilt anyway... and there's no way to "bring" the Metadata along with the file (except as EAs, which is how this should have been done in the first place).

Spotlight, along with ACLs and EAs, is still really, really new. No doubt it'll get better in the future.

[sjk]

Since Spotlight Privacy behaves unpredictably when mounted/unmounted the FW volume it may work best to let SD! run the disable_spotlight script on it and avoid (re)indexing altogether.

But if a Spotlight index is copied from one volume and later restored to another volume using the same pathnames then would that avoid reindexing and preserve all the original metadata? If so, is there a scenario for running SD! so it stops/starts volume indexing at the right times and avoid reindexing that would occur because of pathname changes?

... and it's unlikely that preserving metadata will resolve any kind of issues with kMDItemWhereFrom, because the paths change, so the metadata gets rebuilt anyway...

Aren't kMDItemWhereFroms (it's implemented as plural but not documented that way ) attributes just strings that won't be evaluated in a way that triggers reindexing except when that particular attribute changes (e.g. overwriting a file downloaded from a different location)?

Maybe an answer to my earlier question about a SD! scenario for Spotlight index preservation would be to remove the "-E" option from the disable_spotlight script so that the index won't be erased after it's copied to the backup volume and indexing will remain disabled. Later, if the backup volume (including the copied index) is restored to a volume with the same name as the original and indexing is reenabled afterwards would that be an effective way to preserve all the Spotlight metadata, even "special" attributes like kMDItemWhereFroms that would otherwise be lost by rebuilding the index? Or would something else be changed in that backup/restore process to trigger a "massively destructive" index rebuild, similar what happens now after it loses the Privacy info for a volume even though there's a complete copied index on it?

Oh, that scenario assumes "Exclude Spotlight search index" from the copy script so the contents of /.Spotlight-V100 do get copied. Actually that's what my script for the startup volume already does since it excludes /Users (which is on a separate volume) and I haven't changed it since before 2.0 was released. Some scripts are overdue for attention; the include/exclude directives probably need adjustment.

Is there any sanity in my proposal for attempting to preserve metadata across backups/restores or would it probably become an exercise in futility because of still-quirky Spotlight behavior?