Andrew Rodney asks why it's worth backing up the LR catalog using LR's backup and optimize feature in addition to the regular backup system we all should be using. I believe the best answer is that it is a nontrivial relational database with approximately 221 indexes and 91 tables. It's more complex than the filesystems used on Mac and Windows, so in some important senses more can go wrong. It is implemented using the superb sqlite, but sometimes sometimes
bad things happen. Imagine, for instance, if due to
bitrot (the silent corruption of data on disk) a seldom accessed part of the catalog was corrupted without you noticing it, and your backup system means all archived file backups are systematically deleted after a temporal span which is actually not that long compared to the lifetime of the catalog, e.g. 3, 6 or even 12 months. Ooops. I suppose you could get LR to start from scratch and rebuild the catalog if you are certain that every single item of metadata and everything else you need to perfectly recreate the catalog was stored externally to the catalog. Or you could just be thankful that you have some archived versions of the catalog itself, and use that as one more option in your recovery strategy.
Anyways all of this is papering over the problem that Mac and Windows leave us no option but to use relatively crude file systems that put our data at risk due to bitrot. Until this problem is fixed it's like we're all pissing into the wind.