Huge TM backups - LaunchServices csstore file too big? For years, a typical TM backup for me is around 200MB. For the last week or two, it's grown to about 1.2GB even if I haven't been using the machine. I finally dug into why using tmutil compare and there is a file /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/com.apple.LaunchServices-221-v2.csstore that is 870MB. This file is modified before every TM backup and thus it is backed up every time.

There is another file in that directory named com.apple.LaunchServices-175-v2.csstore that is 5 months old and only 27MB (if this is a useful data point).

Is this normal? Is something corrupt? Can this file be deleted safely and OSX will rebuild it "correctly" ? Any other advice to get my TM backups back to a normal size?
The launch services database is there to speed up the execution of things like telling which apps can open which file. On a clean system, one that you install an OS and don't import apps or settings or data, this database is very small. 

You can inspect the contents of this database indirectly by calling a command lsregister which I make a symbolic link in /usr/local/bin so it's easy to call without typing the long System Library path to the framework tool:

ln -s /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister /usr/local/bin


On my work machine, the database is 85 meg when stored to the filesystem and I have a second account with a much smaller database (probably an admin account I never log in to lately and the system had fewer apps installed when I last triggered a rebuild of the caching database for that user).

sudo find /private/var/folders/zz/ -name com.apple.LaunchServices* -exec du -sm {} +

12  /private/var/folders/zz//zyxvpxvq6csfxvn_n0000000000000/0/com.apple.LaunchServices-175-v2.csstore
75  /private/var/folders/zz//zyxvpxvq6csfxvn_n0000000000000/0/com.apple.LaunchServices-221-v2.csstore


This matches up with the information that lsregister will dump (for me it's 137 thousand lines of text to dump the database and you can look through yours and see which apps take tons of space if you really need to know who is using the space by registering for every file type known to mankind and ruining your backup speeds)

lsregister -dump|head -9
Checking data integrity......done.
Status: Database is seeded.
Status: Preferences are loaded.
Seeded System Version: 10.13.6 (17G65)
Seeded Model Code: MacBookPro13,2
CacheGUID: CD230C46-C259-4B2C-BA4B-88AE7FE74557
CacheSequenceNum: 7684
Date Initialized: 7/10/18, 12:35:16 PM HST (POSIX 1531262116.000)
Path: /var/folders/p6/w8svns2s6pd8vj2gx04pc97h0000gr/0/com.apple.LaunchServices-221-v2.csstore


Or, you could purge some apps you might know are large in terms of mapping to file types or open a support case and provide a sysdiagnose to Apple for analysis if you have an incident / support engineering agreement - it appears to dump all the launch services data and one other app info text file that might be helpful to count apps that have registered (look for lsappinfo.txt inside the sysdiagnose results file).

The TL;DR answer will be:


Just skip backing these up if you are sure they are large and you don't care to dive into why. Add the folder to the exclusions graphically or by command line.
Remove any apps you don't need - then keep removing apps you can reinstall until the database size is more in line with what you want. You may need to manually rebuild the file to test if you don't want to wait for the next trigger to rebuild it.
Open a support case with Apple to determine if you have a bug or just need help identifying which apps are causing the slow performance of Time Machine due to a busy / changing / large file. 


I've never seen this slow down a backup or cause issues, but enough people have reported it there's got to be some programs or situations where this would be a good thing to do.