Catalogs What can I delete and what stays in LR folder?

[mxwizard]

Lightroom Version Number

13.2

Operating System

1. Windows 10

My turn to ask the question. What can I delete and what stays? Thanks all.

 

[Rob_Cullen]

Can you show a clip of the folders in 'Details' view of File Explorer. Your screen-clip is near impossible to read the names of folders and catalogs.

 

[mxwizard]

 

[Rob_Cullen]

Thanks, that's easier.
Basically your current working catalog files contain "-v13" in the filename.
{Lightroom Settings} is essential.
{Backups} are essential- BUT ON ANOTHER DRIVE.
The rest (crossed out in red) can be archived (or deleted if you have been vigilant with catalog backups)

 

[Califdan]

1. Keep the "Backups" folder assuming it has buckups in it. As a general rule your backups folder should be on a different drive than your catalog but that's another topic.
   
   
2. Keep the Settings folder. You may or may not need it depending on a preferences setting so for now just keep it. If it's a big deal for you come back and we'll tell you how to determine if you're using it.
   
   
3. Keep all the other folders and files which start with "Lightroom Catalog-2-2-v13" which should be your current master

The rest can be deleted.

 

[mxwizard]

Thank you all...I have kept the 3 most recent "Backups" in the backup folder, so im good there...The rest now will be easy....Thanks again/

 

[Rob_Cullen]

Arhhh- No.! Not good.
Your 3 most recent "Backups" MUST be on another physical hard-drive, NOT in a folder near the working catalog.
If this hard-drive with the catalog fails for any reason you lose the LOT- Catalog AND backups. So basically backups (stored with the catalog) are useless to restore a catalog if the Drive fails.

 

[Califdan]

Believe him!

Also, I'm not convinced that 3 is enough. I've worked with many clients who have had to go back several weeks or months (multiple dozens of backups ago) to get to a version of the catalog that didn't have some sort of corruption that went undetected for a long time.

 

[clee01l]

Also, I'm not convinced that 3 is enough.

It's not! You need a backup that covers the state for your catalog file BEFORE the error occurred. As one that has gone back as far as six months to recover a "stupid user mistake" (mine!) that accidentally wiped out keywords on over 2000 images, three is never enough.

The drive containing your master catalog file will fail. And when it does, your only recourse will be the backup catalog copies. For that you only need the most recent backup. But this needs to be on a drive that has not failed. To recover a corrupt catalog you need a backup that was not corrupt. How far back depends upon the the time of the corruption. And then there are "stupid user mistakes". We all make them.

A general rule of thumb for backups is One a day for a Month. Then retain one a Month for a year the one for every year. To do this diligently requires some manual housekeeping as there is no way that I know to automatically comply with this "rule of thumb".

What I have done is set aside an old HDD. It is so old (5+ years), that I dare not put critical user data on it. However it is good enough to write backup files to. When I gets full, I will do the housekeeping to make room for more backups. When it fails, I will replace it with another old volume and start over knowing that I will lose every backup and can only hope that I will not need any of them.

 

[PhilBurton]

The drive containing your master catalog file will fail.

HDDs will usually give us a warning when they are failing. Noise (from bearings), slower transfer rates, etc. But most of us us SSDs for all but backups. SSD drives, which include the newer NVMe design, often fail without any warning. The drive works fine, until it doesn't.

What I have done is set aside an old HDD. It is so old (5+ years), that I dare not put critical user data on it. However it is good enough to write backup files to. When I gets full, I will do the housekeeping to make room for more backups.

It's OK to use any older HDD, if you know that's in good shape. If you are enough of a gearhead, you can check the SMART drive report.

If not, you are better served by retiring an HDD after 3-5 years of active service, depending on your appetite for risk. Before disposing of an old drive, be sure to check it for data that was archived. Then disable or smash up the drive so that it is unreadable. (Do a Google search, and have fun!

 

[Steven_LR]

I send the Backups to the Cloud.

 

[clee01l]

I send the Backups to the Cloud.

While this is probably the best most secure backup location. Restoring from a drive failure and retrieving a whole drive worth of data can be expensive and a challenge. That is why I recommend having at least one copy of your system backup locally for easy recovery. If you have a catastrophic event (fire, flood war) you can then resort the cloud for recovery.

 

[Steven_LR]

While this is probably the best most secure backup location. Restoring from a drive failure and retrieving a whole drive worth of data can be expensive and a challenge. That is why I recommend having at least one copy of your system backup locally for easy recovery. If you have a catastrophic event (fire, flood war) you can then resort the cloud for recovery.

I should have stated that I keep a backup of the Catalog Files (including the Zip backups in the Cloud). The image files are a combination of physical and cloud backups. I don't have Terabytes of files, so I see how someone with a large collection, a full cloud backup would be challenging.

Has anyone used Back Blaze to manage an image collection cloud backup. They offer to send a physical recovery drive if needed; full refund of the drive cost upon return.

 

[Califdan]

I'm happy with BackBlaze. However, having said that, in additin to running BackBlaze (cloud backup) I also run CrashPlan (cloud backup) in paralell.

I guess I'm a victim of working with too many clients who were certain that they had an air tight and up to date cloud backup only to discouver after a local drive failure or corruption that their cloud backup was not complete or not up to date. In once case, a drive letter changed in windows and they forgot to tell their service to backup the new drive letter.. In another case the user got a new credit card with a new number after some fraud and they missed giving their cloud service the new CC info and they never got the warning messages from the service as they had also changed their email address. So, eventually the service stopped backing up their data. A third case involved a corrupt catalog where the corruption occured more than a year ago and their cloud service only kept verstions back 12 months. So, by using two cloud services which have different rules, restrictions, billing information I'm covering more bases. Better safe than sorry.