A closing question

[Ellis Vener]

If you accidentally start to close Lightroom and have the "backup Lightroom when closing" option turned on,  to get out of the dialog without closing Lightroom?

[aduke]

I really, really hate to provide this answer since I really hate answers that say "I don't know", but, I run LR using the option to backup every time LR closes and have tried pressing both the Cancel and the window close (upper right x), and LR closes immediately.

The only good news is that you can re-open LR and be back where you were when you closed LR the last time.

Alan

[brianrybolt]

If you accidentally start to close Lightroom and have the "backup Lightroom when closing" option turned on,  to get out of the dialog without closing Lightroom?

This aspect of LR drives me crazy.  I hope someone can answer your question or Adobe will pick up on this and help us out.

[fdisilvestro]

There is no confirmation in LR after closing. When you select to have the backup performed on exit, you have the option to proceed or skip the backup, nothing else.

At that stage you have already been disconnected from the Catalog.

I'm not sure how you arrived to that conclusion. The .lrcat.lock and .lrcat-journal files are still present until you complete the backup and LR closes. Additionally, how will it validate the catalog integrity and optionally optimize it if LR were disconnected from the catalog?

[Wayne Fox]

If you accidentally start to close Lightroom and have the "backup Lightroom when closing" option turned on,  to get out of the dialog without closing Lightroom?

yeah, I’ve always been curious why there is no cancel button in that dialog.

I run into this because sometimes without thinking I close the window, which forces lightroom to quit. so I started using the full screen with menu bar option now which does save me sometimes.  I’m not sure why I keep the menu bar showing because I rarely select anything from it, but I tried it and it just looks weird to me ...

[Tim Lookingbill]

I think for clarity at least for me we should distinguish the meaning of "closing" vs "quitting" LR. Closing suggests you just close the window while LR remains active in system Ram and connected to the catalog on the hard drive.

Just curious but what does LR backup when closing or quitting? I never paid much attention to this mainly because I'm preferring to use ACR CS5's GUI over LR's just because of its complexity of options that requires questions such as these.

Note the confusion in the other LR thread on Soft Proofing and Virtual Copies and why Before/After can't be invoked between them instead of the "Master Photo" which I thought xmp edits were embedded when hitting Save.

[bassman51]

LR backs up the catalog thru this closing dialog. You can also set it to backup when you open (which would be way to frustrating for me).  I have this copy go to Dropbox, so it's out of the house pretty quickly.

In addition, I have it set to make a second copy - on a different hard drives - of all imported image files.  These are never referenced by the catalog and therefore provide a starting-point recovery is you loose the image files that you are working on. 

[digitaldog]

My answer is, don’t have it backup in the first place
Seriously, what’s the point? You have to, you should back up all important files, the database, your images, presets and anything else on your hard drive. This operation only backs up the catalog and at odd times that make no sense to me. Instead, I have a full backup of ALL new files take place in the middle of the night when I’m sleeping. IF Adobe backed up even a fraction of the files associated with LR (DNG Profiles, Lens Profiles, presets, and of course your images), OK, that might be useful for some who don’t back up anything else. They don’t provide that. They provide a kludge of a backup schema. Turn it off, back up using a product designed for that task. FWIW, I’m damn sure you’re doing this anyway, begging the question, what good is the LR backup in the first place?

[bassman51]

I think Adobe's strategy is sensible.  They separate backing up your original image files, which never change, from your catalog, which changes whenever you do any operation.  So they offer the option of backing up the image files at the first possible moment - upon import. Then your catalog can be backed up at the start or end of any session, per your preference.   

I use both of these, then create additional copies using Apple's Time Machine and Crashplan. 

[digitaldog]

They separate backing up your original image files, which never change, from your catalog, which changes whenever you do any operation. 

My files change all the time. I have Auto Write XMP on and use DNGs, so that’s all getting written to the image files which of course, get backed up daily (to a hard drive and CrashPlan).

[Damon Lynch]

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.

[fdisilvestro]

I agree with Damon,

Backup the LR catalog as often as possible from LR (apart from backing up your images with an external application) for all the reason already explained.

Another advantage of doing it from LR is that you can check the integrity of the catalog and optimize it. You cannot do this if you just copy the catalog with an external tool.

[JRSmit]

Assuming the optimize does also look into seldom used parts of the lrcat database so bitrot is spotted.
Just having LR write a copy to another folder or drive does not prevent from propagating bitrot apparently as it is just a file copy.
Not that i have experienced such problems since i started using LR which is from 2008 onwards. I always use an external program to backup, not only the lrcat, also the adobe LR files in other places (roaming etc) and the image files of course.

[digitaldog]

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.

OK, I’ll bite as I know far less about such things as you. First off I do optimize my catalog. The question becomes this; what benefit does the backup schema play above and beyond this part of the process? I backup using data validation in Chronosync, and I realize that there are differing methods to do this. If one optimizes their catalog on a regular basis and uses a daily backup of the catalog (to multiple locations), what advantage is there of letting LR backup the catalog?
Like JRSmit, I’ve had zero issues with my catalog prior to the 1.0 release but that doesn’t mean I’m not concerned about ensuring catalog stability.

[davidedric]

I may be missing something, but why not let Lightroom run through the back up / optimise routing on quitting (incidentally, on my system I get the dialogue whether I close the window or quite through the menu)?  Storage is cheap enough, and occasional manual weeding doesn't take more than a couple of minutes.

If you really have to be away and turn your computer off, just "skip this time".

Dave

[Damon Lynch]

OK, I’ll bite as I know far less about such things as you. First off I do optimize my catalog. The question becomes this; what benefit does the backup schema play above and beyond this part of the process?

The optimization is a very sensible step. I'm reasonably certain part (maybe the majority) of this optimization process is what the sqlite developers call "vacuuming" the database, which takes the entire database and rebuilds it afresh. So LR should in theory pick up many and hopefully all corruption problems during this step.

So the question becomes for those of use who the same catalog year in year out: in addition to our backup system, is it worth archiving specific catalog backups that LR produces, perhaps for instance in one month intervals? Maybe it truly will be worth it one day if your backup system doesn't allow you to recover files from many months ago. Maybe it is truly worth it when running a brand new release of LR, where there is greater chance of programming errors causing catalog corruption. And of course none of us can predict when a RAM stick will go bad, or a drive controller will start playing up.

In any case, I do agree that writing out the metadata to external XMP files (or DNG if that's your thing) is good practice.

[digitaldog]

The optimization is a very sensible step.

Thankfully there’s a separate command for it. Too bad we don’t have similar preferences as Back Up to call this routine on Quit/Close. I wonder if someone has or could write a plug-in for that.

So the question becomes for those of use who the same catalog year in year out: in addition to our backup system, is it worth archiving specific catalog backups that LR produces, perhaps for instance in one month intervals?

Yes, that’s the question. 

Maybe it truly will be worth it one day if your backup system doesn't allow you to recover files from many months ago.

That would only occur (for me) if I went months without using LR. Otherwise, any change triggers the multiple backup’s I have.
So at this point, I’ll stick to my workflow and not setup this backup as I do optimize and I do have a backup that takes the catalog and everything else into account.

[digitaldog]

Oh, a minor point. I suspect that if I Optimize the catalog, there will be changes such that a backup will take place.

[john beardsworth]

I'm reasonably certain part (maybe the majority) of this optimization process is what the sqlite developers call "vacuuming" the database

That's correct. It includes an SQL Vacuum call.

[digitaldog]

Oh, a minor point. I suspect that if I Optimize the catalog, there will be changes such that a backup will take place.

Answer is yes, I just noticed CrashPlan sending up the catalog after optimization.