• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Stop struggling with Lightroom! There's no need to spend hours hunting for the answers to your Lightroom Classic questions. All the information you need is in Adobe Lightroom Classic - The Missing FAQ!

    To help you get started, there's a series of easy tutorials to guide you through a simple workflow. As you grow in confidence, the book switches to a conversational FAQ format, so you can quickly find answers to advanced questions. And better still, the eBooks are updated for every release, so it's always up to date.
  • Dark mode now has a single preference for the whole site! It's a simple toggle switch in the bottom right-hand corner of any page. As it uses a cookie to store your preference, you may need to dismiss the cookie banner before you can see it. Any problems, please let us know!

How to Verify Backup

Status
Not open for further replies.

Paul_DS256

Senior Member
Premium Classic Member
Joined
Mar 29, 2015
Messages
1,202
Lightroom Experience
Intermediate
Lightroom Version
Classic
Lightroom Version Number
LR Classic 8.4
Operating System
  1. Windows 7
I just read a thread where a user could not restore a backup. This lead me to search for a method to verify a backup. I couldn't find any and wonder if there is a way to test that a backup could be used?

As an FYI, I ask because I use to work for a DB company who knew they had a problem with their backup utility but didn't let customers know. It only came to light when a major US bank had a catastrophic DB failure and found they could not use any of the backups to restore their DB.

A standard best practice for any backup strategy is to test it. If there is no way to test a LR backup, does anyone had steps for testing the backup by restoring to a new location so as not to disrupt existing catalogs?

Thanks
 
You can simply try if Lightroom is able to use a backup catalog. Make a copy of the zipped backup, unzip it and double click it. Does Lightroom start and open the catalog successfully? If so, then this backup is fine (and most likely others are too). No need to do this in the original catalog folder, so no risk of disrupting your existing catalog.
 
Completely agree and opening it is the only sure-fire way to know. One point of caution, is you have LR Preferences set to open latest catalog then next time (after opening the backup one) it'll open that again, so be sure to select the correct (working) catalog.
 
Completely agree and opening it is the only sure-fire way to know. One point of caution, is you have LR Preferences set to open latest catalog then next time (after opening the backup one) it'll open that again, so be sure to select the correct (working) catalog.
Yes, good point. Double click your regular catalog after you have verified the backup.
 
With respect to the catalog backup, as above, but be sure to clean up afterwards so you don't end up USING the backup and also the primary and get blended changes.

But bear in mind the catalog is only the pointers, make sure you also verify your image backups, which of necessity are done with some other program.

AND, unless you are backing up your catalog to a non-default place, make sure you are also backing up your catalog backups to another disk. Adobe by default, I think, backs up the catalog to the same disk, so a disk failure will take out both catalog backups and catalog. You should be backing up the catalog, then backing up the catalog-backups AND images to somewhere else.
 
I would like to introduce a different viewpoint. What Adobe calls a Lightroom Backup is nothing more than a file copy taken at a point in time and it is not in the truest sense a "backup". It should be able an identical replacement of the file it was copied from.
A true back up app is a fully functioning system backup with version control. It is what you need to be using to backup your image original files as well as your LR catalog files and supporting files (except for previews which can be recreated on demand. This can be a little more complicated with all of the data saves in a proprietary file format (usually some database component) For instance, Apple uses a backup file with an extension of ".sparsebundle". Without the app that created it, there is no way to extract one snapshot file out of the sparse bundle to recover a defective or deleted original. Backup apps are composed to two parts: Backup and Restore. Setting up the Backup part without testing the Restore part is asking for disaster. You test the Restore part by invoking that and choosing one or more typical files from the backup list and restoring them some location that does not overwrite the master original.
 
I would like to introduce a different viewpoint. What Adobe calls a Lightroom Backup is nothing more than a file copy taken at a point in time and it is not in the truest sense a "backup". It should be able an identical replacement of the file it was copied from.
A true back up app is a fully functioning system backup with version control. It is what you need to be using to backup your image original files as well as your LR catalog files and supporting files (except for previews which can be recreated on demand. This can be a little more complicated with all of the data saves in a proprietary file format (usually some database component)
The LR catalog backup ZIP files are dated, and there is no limit, other than storage capacity, for the number of such backups. That is a form of version control.

As Cletus said, the backup of your actual files is your responsibility, not Adobe's. If you use RAW files, then you need just one backup copy. Best practice is to have multiple copies of your file backups, including one offsite location. That "location" could be cloud-based.
 
If you use RAW files, then you need just one backup copy. Best practice is to have multiple copies of your file backups, including one offsite location. That "location" could be cloud-based.

The first sentence I think is predicated on the idea that LR (and many) editors are non-destructive, and so the raw file is not changing.

I just want to point out that having one copy introduces a number of vulnerabilities, notably either malware that encrypts/corrupts files, or just plain "bit rot" where a file changes spontaneously. If you end up backing up the corrupt copy to your "one" copy you are screwed.

That's why point in time backups are always preferred.
 
The first sentence I think is predicated on the idea that LR (and many) editors are non-destructive, and so the raw file is not changing.

I just want to point out that having one copy introduces a number of vulnerabilities, notably either malware that encrypts/corrupts files, or just plain "bit rot" where a file changes spontaneously. If you end up backing up the corrupt copy to your "one" copy you are screwed.

That's why point in time backups are always preferred.
Most backup applications will only make a new copy if the file has changed. And because the file didn't change, or because the change wasn't noticed (a 'bit rot' change will not be noticed because that won't change the modification date and backup applications rely on the modification date to determine what has changed since the last backup) you will not get a point in time backup of your raw files, unless you force the app to make a completely new backup every now and then.
 
What Adobe calls a Lightroom Backup is nothing more than a file copy taken at a point in time and it is not in the truest sense a "backup". It should be able an identical replacement of the file it was copied from
Thanks Clee01. That helps. My concern about people with corrupt backups was that it was in a different form. I know that when you backup a database, it flattens it to just the data then needs to create the database when restoring from a backup.

Thanks all for your insights.
 
Thanks Clee01. That helps. My concern about people with corrupt backups was that it was in a different form. I know that when you backup a database, it flattens it to just the data then needs to create the database when restoring from a backup.
That is not the case with the Lightroom catalog backup. It's a full copy of the catalog file, so there is nothing to 'restore'. You just replace the old catalog file with it (in case of corruption), or start using a backup copy (in case you lost the original for some reason, like a disk crash).
 
That is not the case with the Lightroom catalog backup. It's a full copy of the catalog file, so there is nothing to 'restore'. You just replace the old catalog file with it (in case of corruption), or start using a backup copy (in case you lost the original for some reason, like a disk crash).
Johan is correct here. Like I said earlier. What Lightroom calls a backup in nothing more than a copy of the file that the SQLlite database engine generates to hold your data. The only addition to that is that since about version 6 the "backup" file has been compressed to a ZIP file format to compactly store what amounts to a binary series of "0s" and "1s".
 
Most backup applications will only make a new copy if the file has changed. And because the file didn't change, or because the change wasn't noticed (a 'bit rot' change will not be noticed because that won't change the modification date and backup applications rely on the modification date to determine what has changed since the last backup) you will not get a point in time backup of your raw files, unless you force the app to make a completely new backup every now and then.

Correct, with emphasis on "most". There are some (goodsync for example) which will allow you to checksum the file each backup and compare to the backup file's checksum. That takes a lot longer, but if (as I do) you run it locally and at night, who cares. Also some clouds (I think Amazon Cloud) can provide a checksum on request so it doesn't need to read the backup while doing this check. This is about bit rot.

But ... run-amok programs, or malware, will often change the file attributes and trigger a backup, which could write the corrupt file into your backup archive. And Ransomware is becoming a continually growing threat.

But for bitrot it is the rare program which will do checksums. Very rare. It's an area that Linux is addressing with growing use of various file systems that internally check checksums, though they are not quite mainstream. Windows tried it with ReFS (as a replacement for NTFS) but at least so far has made a mess of the effort. I'm not sure if Mac's linux heritage is following along with linux in that regard.

Bitrot by the way is the most (maybe only) compelling argument I've heard for using DNG files, so their internal checksums can catch such issues.

That is not the case with the Lightroom catalog backup. It's a full copy of the catalog file, so there is nothing to 'restore'. You just replace the old catalog file with it (in case of corruption), or start using a backup copy (in case you lost the original for some reason, like a disk crash).

One minor note for those unfamiliar and following along at home... in some cases Lightroom will zip the backup of the catalog. This can be really confusing on Windows where the idiotic default behavior is to hide the file types of known files, leaving it showing without the "zip". Forums are littered with people trying to open the zip backup directly and having it fail to open -- actually -- hmmm--- maybe someone should whisper into Adobe's ear to notice that and offer to unzip it for the user?
 
Most backup applications will only make a new copy if the file has changed. And because the file didn't change, or because the change wasn't noticed (a 'bit rot' change will not be noticed because that won't change the modification date and backup applications rely on the modification date to determine what has changed since the last backup) you will not get a point in time backup of your raw files, unless you force the app to make a completely new backup every now and then.
To sort of reply to Johan's and Ferguson's posts just above, no backup program will recognize bit rot, unless you do file checksums as part of the backup process. If you back up each RAW file as soon as it is ingested, then you minimize the chance of bit-rot.

A good practice is to never depend on just one backup file. At a minimum, there shold be a local back-up of the backup volume. Better still is a third copy. Right now my third backup is at a friend's house. We periodically swap backup drives. But I plan to move to a cloud-based system in the near future, since I live in earthquake country. And near enough to wildfire country.
 
The interesting thing is that you do not want a backup program to be triggered by bit rot, because you do not want that corrupted file copied into your backup... The only thing you may want is an early warning that something has gone wrong, so that you can replace that file with a backup copy. That is indeed an argument for DNG, but you would still have to manually run a check from time to time. Lightroom does not do that automatically. And there is a plugin that can do the same for raw files: Validator: A Lightroom Plugin for Verifying Image Files

And if you do not get an early warning, then you'll simply find out the file is corrupted if and when you need that file again. Then you can still replace it with a backup copy, so an early warning may seem like a great idea, but it's just that: an earlier warning.
 
A good practice is to never depend on just one backup file.
The truly paranoid among us also do not depend on one backup program either. I use two separate ones to different media. Just in case some bug got introduced I didn't notice that was corrupting the backup.

Or case in point: one of them just stopped running due to some licensing quirk, it demanded a re-validation of my (perpetual!) license, but since it ran unattended this demand was not visible. It sends an email when it runs, I didn't notice for a month or so I stopped getting emails (I think it should still have run and sent the failure version but... without license it won't do that either). Bad. But in my case I also still had a daily backup with a different program going to the cloud, so I would not have been in trouble.

Or... anyone remember the Adobe mess, where for a version or two the Catalog backup was corrupt? It ran, it looked good -- but the output zip file was corrupt. Bugs happen. Always nice to have a fallback plan.

It is really hard to over-do the belt and suspender approach with backup, given all we invest in our photographic archives, and how hard Murphy works to screw up our lives.

PS. That license issue is a case in point why subscriptions are not the only thing one needs to worry about. I have a perpetual license, but when/if it periodically needs to be validated, it must reach out to their servers to activate. If that company vanishes my perpetual license is short lived. "Perpetual" is not a meaningful word in computers.
 
If that company vanishes my perpetual license is short lived. "Perpetual" is not a meaningful word in computers.
Legacy Perpetual version will eventually succumb to Technological advances. Such as we are beginning to see with MacOS Catalina version being 100% 64 bit.
 
Legacy Perpetual version will eventually succumb to Technological advances. Such as we are beginning to see with MacOS Catalina version being 100% 64 bit.
That's certainly true, but much longer term. What worries me is short term, that so many vendors now have license validation technology built into their software. Once upon a time that was tied to a dongle, or your MAC address, or other characteristics physically in your possession. That could be a problem (e.g. getting a new NIC), but at least if the status stayed quo, you kept working. Now many of them require some periodic connection over the internet (e.g. so they can kill cases if they see 100 users of a single use license). The user might not even know that is happening, well, until they can't reach the company's servers. Companies are very opaque about license verification technology, for obvious reasons.
 
Thanks, I hadn't come across that one.
Victoria,

Since I saw Johan's post about Validator, I went out and snagged a copy and installed it in to Lightroom. It's very easy to use and seems to run fast considering that it is checksumming large (in my case NEF) files.

Phil
 
Status
Not open for further replies.
Back
Top