[besson3c]

In addition to disk space, this will help keep the number of files that exist on the hard drive down, for those that wish to use your backup hard drive for other things other than TM backups. Otherwise, Time Machine will simply continue to utilize your entire disk until it has filled up.

Firstly, you will need to disable ACLs on your backup volume, see:

http://forums.macnn.com/90/mac-os-x/...p/#post3524355

To delete backups older than a certain date, execute the following Unix command in your terminal:

Code:
sudo find /path/to/backupset -maxdepth 1 -ctime +1 -exec rm -rfv {} \;

Change the path to your backup to:

Code:
/Volumes/<yourVolume>/Backups.backupdb/<yourMachinename>

The -ctime +1 means "a creation time of older than 1 day". You can change the +1 to +2 (or any other number) to look for backups older than 2 days, and you can remove the plus if you would like to look for backups exactly n number of days old.


Doing so seems to be safe - the next time you invoke the Time Machine interface the old backups will simply be gone from the timeline.

As discussed in both the AppleInsider and the Siracusa Ars Technica Time Machine reviews, deleting hard linked files like this is safe - by deleting a hard linked file you are not deleting the original as long as there is another copy of the file somewhere else. IOW, in order to completely delete a file you need to delete all copies of the file, including hard links. If this doesn't make sense to you, the bottom line is that deleting old backup sets is a safe thing to do

[mduell]

Why not just create a partition the size you want Time Machine to use?

With Live Partition Resizing in Disk Utility in Leopard, it seems like a much easier way.

[nycdunz]

that seems like a good idea, partition your ext HD into the amount of space you wanna reserve for TM

[mduell]

Wouldn't this method delete all backups of files that haven't changed in n days? I don't see how your find command skips the most recent backed up version of a file.

[besson3c]

Originally Posted by mduell 

Wouldn't this method delete all backups of files that haven't changed in n days? I don't see how your find command skips the most recent backed up version of a file.

No, because each snapshot contains every single file in the backup set, and space is saved via hard linking. However, you can delete any one of these files without deleting the original, as long as there is one copy of the file in one of the backup sets.

[besson3c]

For those of you doing this in conjunction with a network backup (such as myself), you obviously cannot do this on a non-OS X machine since this machine has no way of mounting OS X disk images. I'm working a script that can be run on OS X that will allow you to delete a variable number of backup sets only if your total backup image exceeds a variable amount of disk space. The script will only run while there is no "inProgress" files, which would indicate a backup in progress.

I'll post this script for those that want it once I'm done with it...

[Ricisbest]

Currently I'm just using a cron job to run a similar command to the one that besson3c mentioned in the first post of this thread.

besson3c, I'd be interested in seeing your size-related deletion script.

Cheers,
Ric

[besson3c]

Since TM doesn't work with network backups I didn't bother writing my script, but the magic would be done with a find command something along the lines of:

[codex]find /path/to/tm/backups -ctime +30 -maxdepth 1 -exec rm -rf {} \;[/codex]

Where +30 = older than 30 days.

[analogika]

Originally Posted by besson3c 

Since TM doesn't work with network backups

Nonsense.

Of course it does!

[besson3c]

Originally Posted by analogika 

Nonsense.

Of course it does!

I would *love* to hear how you got the interface to recognize the contents of your backup disk image... For me it is backing up but not showing the timeline in the interface.

[analogika]

I have no idea.

As far as I know, it "just worked".

One of our work Mac minis has Time Machine running via network volume.

From Apple's Time Machine page:

Time Machine can also back up to another Mac running Leopard with Personal File Sharing, Leopard Server, or Xsan storage devices.

[besson3c]

Originally Posted by analogika 

I have no idea.

As far as I know, it "just worked".

One of our work Mac minis has Time Machine running via network volume.

From Apple's Time Machine page:

There was some complaints that Apple pulled this feature. For starters, TM won't recognize network disks without attempting to fool it (it needs to see a dot file named after your MAC address as well as .com.apple.TimeMachine.supported or something like that).

What are you using for a network volume? Another OS X client machine? OS X Server? Netatalk? Xsan?

[Hal Itosis]

Originally Posted by besson3c 

As discussed in both the AppleInsider and the Siracusa Ars Technica Time Machine reviews, deleting hard linked files like this is safe - by deleting a hard linked file you are not deleting the original as long as there is another copy of the file somewhere else. IOW, in order to completely delete a file you need to delete all copies of the file, including hard links. If this doesn't make sense to you, the bottom line is that deleting old backup sets is a safe thing to do.

Originally Posted by besson3c 

No, because each snapshot contains every single file in the backup set, and space is saved via hard linking. However, you can delete any one of these files without deleting the original, as long as there is one copy of the file in one of the backup sets.

 
Since -- as you say -- Apple is saving space by using hard links, then
what sort of "space" does deleting such links really recover? After all...
it's really only the original taking up significant space. The command
rm (which was once called unlink) is merely decrementing link counts
of multi-linked files. Nothing major changes until the count goes from
1 to 0.

What would be cool (I think) is if there were some way to "flush history".
i.e., delete older versions of files that have been edited. Does your find
command achieve something like that? Because that would dump actual
files we don't need. [As in, when we don't wish to hang on to previously
edited versions.] Ideally, it would nice to be able to have Time Machine
clear out *all* excess junk with the click of a button... essentially saying
'start everything over from now'.

[CharlesS]

Originally Posted by Hal Itosis 

 
Since -- as you say -- Apple is saving space by using hard links, then
what sort of "space" does deleting such links really recover? After all...
it's really only the original taking up significant space.

Well, each backup is going to have a few files that changed from previous or subsequent backups, and thus will only be linked to once. Deleting a backup will delete any files in that backup with only one hard link.

The command
rm (which was once called unlink)

Nope, AFAIK rm is the original name. The POSIX API to remove a file is indeed called unlink(), though. Unlink is also a synonym for the rm command, but only when removing regular files - you can't use the unlink command to delete directories.

What would be cool (I think) is if there were some way to "flush history".
i.e., delete older versions of files that have been edited. Does your find
command achieve something like that? Because that would dump actual
files we don't need. [As in, when we don't wish to hang on to previously
edited versions.] Ideally, it would nice to be able to have Time Machine
clear out *all* excess junk with the click of a button... essentially saying
'start everything over from now'.

All you'd have to do to achieve that would be to delete the Backups.backupdb folder. Or, if you'd rather not wait for the backup to start all over again, go into Backups.backupdb and delete everything but the very latest backup.

[Drakino]

Originally Posted by besson3c 

I would *love* to hear how you got the interface to recognize the contents of your backup disk image... For me it is backing up but not showing the timeline in the interface.

macosxhints.com - Store Time Machine backups on an AFP NAS

Two methods there. One is to tell Time Machine to work with unsupported drives, and works for me at work to an SMB share.

The second method is my lengthy process I used for my home machines to an AFP NAS. I did this to force a sparseimage as some methods didn't do this and would not work properly once moved to the network.

For a full restore when booted off the OS X disc, it works off AFP shares if you know how to mount them through the terminal first. SMB, I couldn't get mounted, and haven't dug too deeply.

[besson3c]

Originally Posted by Drakino 

macosxhints.com - Store Time Machine backups on an AFP NAS

Two methods there. One is to tell Time Machine to work with unsupported drives, and works for me at work to an SMB share.

The second method is my lengthy process I used for my home machines to an AFP NAS. I did this to force a sparseimage as some methods didn't do this and would not work properly once moved to the network.

For a full restore when booted off the OS X disc, it works off AFP shares if you know how to mount them through the terminal first. SMB, I couldn't get mounted, and haven't dug too deeply.

Ahhh... good to know the defaults command, I didn't know about that. I've already gone through with the second method, like you, and got backups to work but this data was not reflected in the TM interface.

How do you explain the third point of this requirements list?

To get started, here is what is needed:

* An external USB or Firewire drive with enough space for a complete backup
* Two separate Lepoard running Macs on the same network
* NAS unit of some sort that supports AFP. SMB, and other protocols will not work

Is your NAS another Mac, or an actual NAS appliance? Is your NAS running Netatalk?

[besson3c]

Originally Posted by CharlesS 

Well, each backup is going to have a few files that changed from previous or subsequent backups, and thus will only be linked to once. Deleting a backup will delete any files in that backup with only one hard link.

It will also free up some inodes on the disk and take various disk operations (repairs, etc.) less time with less files to negotiate.

[besson3c]

Originally Posted by Hal Itosis 

Since -- as you say -- Apple is saving space by using hard links, then
what sort of "space" does deleting such links really recover? After all...
it's really only the original taking up significant space. The command
rm (which was once called unlink) is merely decrementing link counts
of multi-linked files. Nothing major changes until the count goes from
1 to 0.

See above...

What would be cool (I think) is if there were some way to "flush history".
i.e., delete older versions of files that have been edited. Does your find
command achieve something like that? Because that would dump actual
files we don't need. [As in, when we don't wish to hang on to previously
edited versions.] Ideally, it would nice to be able to have Time Machine
clear out *all* excess junk with the click of a button... essentially saying
'start everything over from now'.

What are you wanting to do? Only delete the file if it changed, leaving the unchanged hard links alone?

[Hal Itosis]

Originally Posted by CharlesS 

Well, each backup is going to have a few files that changed from previous or subsequent backups, and thus will only be linked to once. Deleting a backup will delete any files in that backup with only one hard link.

 
So... is that necessarily a "good idea"? Is it assured that such files represent
only items we previously deleted or edited? [I'm just saying, it would be nice
if someone explained all this with a little more clarity.] So it sounds like, the
whole "find command" approach really isn't that efficient. If we want to trim
stuff, it's easier to just rm an entire "date" folder (e.g., 2007-10-30-180016).

?

Originally Posted by CharlesS 

Nope, AFAIK rm is the original name. The POSIX API to remove a file is indeed called unlink(), though. Unlink is also a synonym for the rm command, but only when removing regular files - you can't use the unlink command to delete directories.

 
No biggie. The point was: rm won't actually "remove" files with more than one link.
So any 'space-saving' on those items is quite minimal. (Thanks though).

Originally Posted by CharlesS 

All you'd have to do to achieve that would be to delete the Backups.backupdb folder. Or, if you'd rather not wait for the backup to start all over again, go into Backups.backupdb and delete everything but the very latest backup.

 
The latter, naturally (why delete the "Latest" and then recreate it?).

BUT... What about the *special* Spotlight index created on the backup drive?

I say "special" because A) it's quite big... and B) it is put together by Time
Machine and Spotlight REGARDLESS of the mdutil status for the drive. I.e.,
turn off indexing on the drive and let a few backup runs occur. Check for
a /.Spotlight folder on the drive. It's there, it's big, it's deep... even if we
disabled indexing. Even if indexing is *still* off, it gets written anyway.

Seems to me Time Machine might get confused if *we* go around deleting
stuff, while leaving that fat index there. But maybe it's okay. I just see no
mention of it here. Perhaps there will be consequences of doing this, that
we don't yet know about at this early stage. So I'm just wondering if that
index gets tweaked appropriately if Time Machine doesn't notice that we
went into the backup folder and changed its contents... and how much (or
how little) that might matter.

But if you are right that deleting stuff willy-nilly in the .backupdb is totally
harmless... fine. I'm not trying to win an argument here... rather, just get
some of the facts more fully explained.

[Hal Itosis]

Originally Posted by besson3c 

See above...

In other words... not much, right?

Originally Posted by besson3c 

What are you wanting to do? Only delete the file if it changed, leaving the unchanged hard links alone?

What? No. See above...

[CharlesS]

Originally Posted by Hal Itosis 

 
So... is that necessarily a "good idea"? Is it assured that such files represent
only items we previously deleted or edited? [I'm just saying, it would be nice
if someone explained all this with a little more clarity.] So it sounds like, the
whole "find command" approach really isn't that efficient. If we want to trim
stuff, it's easier to just rm an entire "date" folder (e.g., 2007-10-30-180016).

Yeah, that's kind of the point of hard links. If a file is hard linked in some other date folder, it won't get deleted. If the only hard link is in the date folder you removed, then it will.

No biggie. The point was: rm won't actually "remove" files with more than one link.
So any 'space-saving' on those items is quite minimal. (Thanks though).

Depends on how many files you changed in between backups, and how large those files are. Time Machine doesn't just backup the changes, it re-backs up the whole file, so if you're dealing with very large files, you may see quite substantial savings.

Of course, I'd just wait for the drive to fill up and let Time Machine do it on its own, but that's just me.

BUT... What about the *special* Spotlight index created on the backup drive?

I say "special" because A) it's quite big... and B) it is put together by Time
Machine and Spotlight REGARDLESS of the mdutil status for the drive. I.e.,
turn off indexing on the drive and let a few backup runs occur. Check for
a /.Spotlight folder on the drive. It's there, it's big, it's deep... even if we
disabled indexing. Even if indexing is *still* off, it gets written anyway.

Seems to me Time Machine might get confused if *we* go around deleting
stuff, while leaving that fat index there. But maybe it's okay. I just see no
mention of it here. Perhaps there will be consequences of doing this, that
we don't yet know about at this early stage. So I'm just wondering if that
index gets tweaked appropriately if Time Machine doesn't notice that we
went into the backup folder and changed its contents... and how much (or
how little) that might matter.

But if you are right that deleting stuff willy-nilly in the .backupdb is totally
harmless... fine. I'm not trying to win an argument here... rather, just get
some of the facts more fully explained.

Well, if it's properly implemented, it should work just like it does when you modify or delete any other file on the hard drive - Spotlight detects what you did, and updates its indexes accordingly.

[besson3c]

Originally Posted by Hal Itosis 

So... is that necessarily a "good idea"? Is it assured that such files represent
only items we previously deleted or edited? [I'm just saying, it would be nice
if someone explained all this with a little more clarity.] So it sounds like, the
whole "find command" approach really isn't that efficient. If we want to trim
stuff, it's easier to just rm an entire "date" folder (e.g., 2007-10-30-180016).

?

The find command will just allow you to automatically delete backup sets older than X days. It is just automating what you are describing above.

No biggie. The point was: rm won't actually "remove" files with more than one link.
So any 'space-saving' on those items is quite minimal. (Thanks though).

Correct, but if you did a week's worth of backups it would kill off files that have changed within this week. Your space savings would be variable.

BUT... What about the *special* Spotlight index created on the backup drive?

I believe the fsevents kernel stuff will notice that these files were deleted, and update Spotlight accordingly.. I'm assuming that terminal delete commands trigger an fsevent.

But if you are right that deleting stuff willy-nilly in the .backupdb is totally
harmless... fine. I'm not trying to win an argument here... rather, just get
some of the facts more fully explained.

Good conversation!

[Hal Itosis]

Originally Posted by CharlesS 

Well, each backup is going to have a few files that changed from previous or subsequent backups, and thus will only be linked to once. Deleting a backup will delete any files in that backup with only one hard link.

Originally Posted by Hal Itosis 

So... is that necessarily a "good idea"? Is it assured that such files represent only items we previously deleted or edited?

Originally Posted by CharlesS 

Yeah, that's kind of the point of hard links. If a file is hard linked in some other date folder, it won't get deleted. If the only hard link is in the date folder you removed, then it will.

 
Okay yes, I'm familiar with the ``what will and what won't get deleted ' '  aspect.

But... I'm still trying to get a fix on what "singly"-linked files inside folders
other than "Latest" represent. They then must be the stuff that was either
trashed outright, or else original versions of stuff that have newer/edited
replacements in (the target of) "Latest". So singly-linked items in older folders
are totally expendable, as long as we're happy with the current state of things .

Is *that* right?
Is it "complete"... or did I leave out something?

Originally Posted by CharlesS 

Well, if it's properly implemented, it should work just like it does when you modify or delete any other file on the hard drive - Spotlight detects what you did, and updates its indexes accordingly.

Yes... we can hope so anyway.
[ I've never heard of a Spotlight index getting out-of-sync... have you? ]

The thing is: unless Apple says it's okay for us to manually trim backups in
*any* manner (such as this), it may not all work as expected. I sure hope it
doesn't matter, but it might take some extensive testing to be sure of that.

[ I do wish there was one more button in Time Machine that did all this. ]

[Hal Itosis]

Originally Posted by besson3c 

The find command will just allow you to automatically delete backup sets older than X days. It is just automating what you are describing above.

 
Ooooooookay... now I see. I sorta missed that "maxdepth 1" search parameter.

[I thought you were hunting throughout the whole hierarchy for individual items.
That would be nuts, I think?]

My bad... your good.

I hope that Spotlight index will behave accordingly.

[besson3c]

Originally Posted by Hal Itosis 

Ooooooookay... now I see. I sorta missed that "maxdepth 1" search parameter.

[I thought you were hunting throughout the whole hierarchy for individual items.
That would be nuts, I think?]

My bad... your good.

I hope that Spotlight index will behave accordingly.

Yeah, it would... it is convenient that TM keeps such a neat and tidy folder structure so that we can do stuff like this. It is also worthy to note that when you yank a backup out this way, the TM interface handles this gracefully (tested this with an external drive)

[Hal Itosis]

Originally Posted by besson3c 

It is also worthy to note that when you yank a backup out this way, the TM interface handles this gracefully (tested this with an external drive)

 
Tested... how? [or, how *rigorously* I should say.]

For example, did you measure the size of that index before and after?
I would expect it should get smaller. For example, if we rm all backup
folders older than 2 weeks... and the Spotlight index doesn't change,
that might worry me. A little bit of corruption could later grow into a
migraine headache, when we least need it. Best to keep checking this
technique over an extended time period, before declaring victory.

--

Look at it this way: that .backupdb folder is Time Machine's baby, and
we are doing stuff to it... behind Time Machine's back (so to speak). If
you wrote some program that managed a database, and someone else
posted a script that made changes to that database, would it be your
responsibility to know what that script has done? There is an intricate
partnership going on here between Time Machine and Spotlight which
makes the whole thing work. I don't know how much we can assume
about what's going on there. It looks simple though (so let's hope it is).

--

BTW, just want to mention that ctime is not necessarily "creation" time.
In many cases it isn't. In this case, it happens to work out. But, it would
not be good for readers here to start making scripts with the idea that
ctime is always the creation time. It's really the time the inode was last
changed... which could happen very easily (chmod, chgrp, chown, etc.)

[CharlesS]

Originally Posted by Hal Itosis 

Look at it this way: that .backupdb folder is Time Machine's baby, and
we are doing stuff to it... behind Time Machine's back (so to speak). If
you wrote some program that managed a database, and someone else
posted a script that made changes to that database, would it be your
responsibility to know what that script has done?

If your program that managed the database did so by watching file system events and then updating the database as appropriate, and those file system events would get generated whenever someone else's script made any changes to the files your database tracked? Um... yes.

I'm willing to assume that Spotlight works unless I see evidence to the contrary, given that we've had it since Tiger and I haven't heard of any problems with the database getting out of sync so far.

[besson3c]

Originally Posted by CharlesS 

If your program that managed the database did so by watching file system events and then updating the database as appropriate, and those file system events would get generated whenever someone else's script made any changes to the files your database tracked? Um... yes.

I'm willing to assume that Spotlight works unless I see evidence to the contrary, given that we've had it since Tiger and I haven't heard of any problems with the database getting out of sync so far.

I'm going to assume it would be fine too, as it would make absolutely no sense for Unix file commands to not invoke fsevents since Apple themselves run scheduled Unix commands that manipulate files, and there are most certainly any number of GUI frontends to these Unix tools, including possibly Automator. Fsevents, AFAIK, is a very low level system thing, not something supported at the application level (keeping in mind that "rm" is an application).

[Hal Itosis]

Originally Posted by CharlesS 

If your program that managed the database did so by watching file system events and then updating the database as appropriate, and those file system events would get generated whenever someone else's script made any changes to the files your database tracked? Um... yes.

Um... then um... we will um... find out eventually. Um... won't we?

Originally Posted by CharlesS 

I'm willing to assume that Spotlight works unless I see evidence to the contrary, given that we've had it since Tiger and I haven't heard of any problems with the database getting out of sync so far.

You haven't!?!?!?
Any more jokes?

There's no end of posts at MFI and macosxhints (and probably here)
where Spotlight couldn't find a file you're *staring* at. Then, possibly
when you open it... but definitely when you re-index... like "magic",
it finds it.

[Hal Itosis]

Originally Posted by besson3c 

I'm going to assume it would be fine too,

So... you won't even bother to do any specific Spotlight index-size measurements?
Or further scrutinize the situation?

Well... I guess we won't be hearing any Time Machine complaints
from you then, about: "Hey, my backup got screwed up!".

Good.

And good luck to anyone blindly running your script.

There's always room for luck I guess.

[CharlesS]

Originally Posted by Hal Itosis 

There's no end of posts at MFI and macosxhints (and probably here)
where Spotlight couldn't find a file you're *staring* at. Then, possibly
when you open it... but definitely when you re-index... like "magic",
it finds it.

Oookay, so if I follow your argument to its logical conclusion, then, no one should ever modify or delete any file on their hard drive?

Originally Posted by Hal Itosis 

So... you won't even bother to do any specific Spotlight index-size measurements?
Or further scrutinize the situation?

Well... I guess we won't be hearing any Time Machine complaints
from you then, about: "Hey, my backup got screwed up!".

Good.

And good luck to anyone blindly running your script.

There's always room for luck I guess.

Where "luck" is interpreted as Apple's software working the way it's supposed to, I guess.

I find it amusing that this is coming from the guy who thought it was a great idea to post a command-line "fix" to something which involved hex-editing a particular offset in /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom even though that file would be different depending on what version of 10.3.x had been originally installed on the machine, and who just got angry when I pointed this out and claimed the burden of proof was on me to install every machine-specific 10.3.x installer and find one where your "fix" caused problems, and unless I could prove it with evidence of a messed up Archive.bom file, you were going to assume that your solution was perfectly safe..............

[TETENAL]

Originally Posted by CharlesS 

Where "luck" is interpreted as Apple's software working the way it's supposed to, I guess.

The fact that those backups can not be deleted even by root unless one disables ACLs (and doesn't Time Machine not make use of those?) appears to be some evidence that users are not supposed to delete random stuff out of the backup database. If one wants to remove files or folders out of the backup, one can use the respective command in the Action menu of the Finder while in Time Machine mode. If one wants to limit the size of the backup, one can partition the backup drive.

But I would not suggest to manually mess with the backup, even when besson3c figures it "seems to be safe".

[CharlesS]

Originally Posted by TETENAL 

The fact that those backups can not be deleted even by root unless one disables ACLs (and doesn't Time Machine not make use of those?) appears to be some evidence that users are not supposed to delete random stuff out of the backup database.

Is this true? I was able to delete my Backups.backupdb folder quite a few times during the beta testing period when I was trying to track down some bugs.

At any rate, if this is so, I would assume it's because you'd no longer have an accurate backup of your disk if you actually went inside the "date" folders and messed with files in there, not because Spotlight can't keep track of file deletions.

[TETENAL]

Originally Posted by CharlesS 

Is this true?

I'm not trying to manually delete stuff out of my backup now to test this, but that's what besson3c claimed in his intro post:

Originally Posted by besson3c 

Firstly, you will need to disable ACLs on your backup volume

[Hal Itosis]

Originally Posted by CharlesS 

Oookay, so if I follow your argument to its logical conclusion, then, no one should ever modify or delete any file on their hard drive?

Sure... go into /System or /sbin and delete anything you want.

I'm just saying, it might be wise to have a modicum of caution:
Leopard is new. Time Machine is new. Multi-linked directories
are new. If you're an expert on all this new stuff, then great!!!
If you have actually experimented and verified the results, even
better. If you're guessing and assuming, then I hope you're right.

Originally Posted by CharlesS 

Where "luck" is interpreted as Apple's software working the way it's supposed to, I guess.

 
Yes. And when it doesn't we need to fix it. Again... I refer to many times
I've read that users needed to reindex their drives. Even I have had to do
that once or twice (early Tiger), to snap Spotlight out of its haze.

Is that the "working the way it's supposed to" you mean?

[CharlesS]

Originally Posted by Hal Itosis 

Sure... go into /System or /sbin and delete anything you want.

I'm just saying, it might be wise to have a modicum of caution:
Leopard is new. Time Machine is new. Multi-linked directories
are new.

However, Spotlight is old. If you were arguing about something actually internal to Time Machine, that would be one thing, but you're just arguing about the Spotlight index getting out of date. Spotlight reads from fsevents, so it should automatically pick up any changes that occur in Backups.backupdb.

Yes. And when it doesn't we need to fix it. Again... I refer to many times
I've read that users needed to reindex their drives. Even I have had to do
that once or twice (early Tiger), to snap Spotlight out of its haze.

Is that the "working the way it's supposed to" you mean?

Great, so you've got some anecdotal evidence of kinks in Spotlight, from the early days of Tiger. That was two years ago! I should hope that Spotlight is reliable by now. If not, oh well! Spotlight is a system-wide service, so if you are checking the Spotlight database after doing anything with the backup, then you should logically also be checking the database whenever you alter anything else on the drive. Do you? Just relax, use your computer, let Spotlight do its thing in the background, and if the Spotlight index gets messed up, then rebuild it! I don't see why we need to work ourselves into a frenzy about such a minor thing.

[Hal Itosis]

Just want to mention that, there is a GUI method available (that doesn't require disabling ACLs).
We need the Finder window Toolbar set to display the 'Action' menu (that "Gear" icon widget).

To delete a backup:
• enter the restoration dimension in Time Machine and,
• go back to the time and place in the backup you want to delete,
• Select “Delete Backup” from the Action menu in the Toolbar.

[TETENAL]

I already mentioned the commands in the Finder's Action menu a few posts above. You can delete one object from all backups or one backup (point in time) of all objects.