Backing up the catalog, etc.

Status
Not open for further replies.
H

hfritsche

New Member
Joined
Dec 10, 2009
Messages
15
Location
Prescott, AZ
Hi all. Fairly new to LR here. I've asked my question before but must not have been clear with my question so here goes again...

I have all my photos in various folders under a master folder on an internal HD called 'digpix'. Using sync software (MS SyncToy, which is great, btw), I mirror this folder (digpix) onto an external HD. I stress here that the external backup is just that.. a safety backup. All working is done on my internal HD.

I want to move my catalog (lrcat) from wherever the default location is, into my 'digpix' folder. First, I always know where it is but more importantly, since I sync this folder to external HD nearly every day, by default, I will backup my lrcat every day... perhaps eliminating the need to use LR's backup.

Q #1: Is there anything unsound about this thinking? Any cons that I'm not seeing?

Q #2: Are there other associated files that I should move at the same time, such as the previews... anything else perhaps?

Thx in advance for any help I receive.
Harold
 
Sort by date Sort by votes
Harold, Sorry your previous ?s went unanswered.

Q#1, fundamentally nothing unsound. The sole issue may be performance. Experience has shown that Lr performs best with a) its file components running on separate fast drives: the more and faster read/write heads on the job, the better, and b) multi-cored CPUs, which is of no interest in this discussion. Putting the catalog, preview cache, and image files on the same drive will have some performance impact, which may or may not be noticeable. Using a logical partition on the same physical drive won't help that, either.

Q#2, You'd move the pertinent *.lrcat file(s) [the catalog file] from its current location, by default somewhere in the Pictures folder hierarchy, along with the paired *.lrdata folder trees [the preview cache], to the new location, so that they remain side by side in the new folder. The *.lrdata move is optional, Lr will recreate the needed previews automatically, but that will be a drain on performance while it's happening.

In making this move, the catalog knows where to find the original images, in an absolute filepath kind of way, that is, it knows exactly where on your machine the image files are located, you need not preserve some relative filepath between the two. You can more or less put the catalog and cache anywhere (except a network asset) and expect it to work. On Windows, the preview cache must be located in the same folder as the catalog.

One issue arises, should you have set Lr's preferences to automatically open a) the most recently used catalog, or b) a specific named catalog. You can see that once you've moved your main catalog, either of those options will effectively open the wrong catalog. To avoid/reset that problem open Lr, by double-clicking its icon, while holding down Ctrl, that should open a dialog allowing you to navigate to, and to reset the new catalog location preference.
 
Upvote 0 Downvote
Hi Brad,
Thx for a quick reply. Firstly, my previous question didn't go unanswered, just badly answered because I wasn't clear enough with my question. My fault.

I don't think I can do anything about drive performance as I only have one internal drive at this point. I believe that using the EXternal drive for 'live' work will not help because, as I understand it, external drives are significantly slower than internal ones.

So if I understand you... I just move my .lrcat along with its .lrdata folder and I'm good to go. Regarding the 'open most recently used catalog' issue... didn't I read somewhere that if, after moving the .lrcat, I double-click on it... thereby opening it... LR will take notice and register that the 'most recently opened' is now at the new location and I won't have to reset any preferences?

What do you think about backing up the catalog in the future. Since my sync software will sync the catalog/preview files as well as my images, won't that negate any reason for using LR's catalog backup routine?

Harold
 
Upvote 0 Downvote
So if I understand you... I just move my .lrcat along with its .lrdata folder and I'm good to go. Regarding the 'open most recently used catalog' issue... didn't I read somewhere that if, after moving the .lrcat, I double-click on it... thereby opening it... LR will take notice and register that the 'most recently opened' is now at the new location and I won't have to reset any preferences?

Well, yes and no. If you truly moved the catalog, Lr won't be able to find it, at the normal open, and will ask you where to look. That's good. If you copied the catalog, Lr will find the old catalog in the expected location, and confusion will likely ensue. That's the only reason I pointed that out, just be careful that the catalog that's actually open is the one in the new location.

What do you think about backing up the catalog in the future. Since my sync software will sync the catalog/preview files as well as my images, won't that negate any reason for using LR's catalog backup routine?

Yes, that will work fine, and correct, it won't be necessary to use Lr's backup routine. Most folks recommend keeping several back copies of the backup, in the event that something went wrong a couple of days ago, that you didn't catch until you backed up the mistake. Also recommended is occasionally checking to ensure that the backup catalogs open and appear intact. You can simply double-click on a backup catalog to open it, again, remaining aware of the file location issues discussed above.

It's probably not necessary to waste time or disk space backing up the preview cache *.lrdata folders. I know some pro's that go to that much trouble, in order not to lose productivity in the event of a preview issue, but Lr will recreate them on the fly, and that should be sufficient for most of us part-time users.
 
Upvote 0 Downvote
Just to be triple clear, when you move the catalog/previews, yes double clicking the moved .lrcat file will open LR and all will be well. :)
 
Upvote 0 Downvote
Brad stated: "Experience has shown that Lr performs best with a) its file components running on separate fast drives: the more and faster read/write heads on the job, the better"
My situation: Imac with 25'gb internal, Lightroom program on Boot. External 4 bay cabinet with 2-1.5gb stripped into 2 partitions, one holding image archive containing all imported dngs and jpegs in a single catalog, and the other is a scratch disk for PS and holding all cache files for LR. 1- 1gb in cabinet holding Light Room catalog, previews and other material. 1-1gb holding Light Room cat BUs and other material BUs.
Does this sound like the best arrangement of the components? The fastest drive is probably the 1.5 stripped which holds the images. Does Light Room access these raws-jpegs under normal working conditions apart from when I choose to write metadata to them? If not, should I be using the stripped drive for the LR catalog instead of the single 1 gb?
Thanks for any suggestions
Jonathan
 
Upvote 0 Downvote
Sounds pretty good jljonathan.

I think the primary trade-off will be between the Develop ACR cache, and the original image files. That's where the high volume, high bandwidth reads (mostly) and writes occur. Since you have these on fundamentally different drives, I think you're in pretty good shape. I'm not all that familiar with the performance hit of the partitioning of the striped drives, so you'll have to be the judge of that.

The *.lrcat catalog reads/writes are typical of a database, lots of little reads/writes everywhere, all the time. This is likely to be seek rate rather than bandwidth constrained.

The *.lrdata, preview cache is active only during pre-rendering, and while scrolling in Library or output module views. While scrolling, these are relatively small files at screen resolution, with consequently lower bandwidth required. The speed issues here are pre/re-rendering where the CPU bears the brunt.

The heavy lifting is in the Develop module, where both the ACR cache and the original image files are/may be extensively read in full resolution. Here, the entire raw/source file needs to be read in, rendered on the spot, converted to screen resolution output, and displayed. While not publicly documented, we believe that the ACR cache contains some degree of pre-digested information from the raw rendering pipeline. From this you can discern that the fastest Develop performance is obtained by working on a single image until adjustments are complete. Moving between images in Develop, will cause a read/load from the ACR cache of a substantial filesize of mid-pipeline data in the best case, or a complete reread/rerender from the original image file, if there's no cache hit. This of course depends on your image throughput and the diskspace allocated to the cache.

There is one theoretical improvement, I believe it's possible to hack a Mac to keep the *.lrdata preview cache on yet another drive using some sort of drive redirection, like a Windows subst command. Symbolic link?

That said, I believe that specifically choosing tuned drives for each of the LR file system components won't produce any noticeable incremental improvements. Just getting each of the pieces on a separate read/write channel is most of the battle. In fact, it's likely that those improvements may be marginal as well, and not worth the effort except in a) very high volume shops, b) you already have the components, or c) you're just compulsive about performance tuning. :)
 
Upvote 0 Downvote
Brad
Thanks for the very thorough rundown. The only thing I might try out for fun would be separating the ARC cache from the image files, move it onto one of the other un-striped drives.
Jonathan
 
Upvote 0 Downvote
Sorry for jumping in here, but where is the ACR cache located on a windows system? Can the location be changed by preferences?

Thanks,
Thomas
 
Upvote 0 Downvote
Thomas,
Edit > Preferences > File Handling, bottom panel. As I said, try to put it on your fastest drive, and make it as large as you can afford the disk space. 5'GB is the max, I believe.
 
Upvote 0 Downvote
[quote author=hfritsche link=topic=8768.msg59''4#msg59''4 date=1262118157]
Since my sync software will sync the catalog/preview files as well as my images, won't that negate any reason for using LR's catalog backup routine?
[/quote]

Just to clarify this point - until your backups are doing versioned backups, then no LR's backups won't be negated. What happens if your catalog gets corrupted, you don't realise immediately, and your last good backup gets overwritten by the corrupted backup. That's why LR's own backups do dated backups rather than just overwriting, so I'd keep that running alongside.
 
Upvote 0 Downvote
Status
Not open for further replies.
Back
Top