Oh no you don’t – DNG and panto season
It’s amazing how often some Lightroom users still assert that a disadvantage of the DNG file format is that any time the metadata changes in the DNG file, you have to backup the whole DNG file again (and again). This isn’t a disadvantage of DNG – it’s a failure to re-assess and think through your backup strategy.
So as it’s now pantomime season, a deep intake of breath please, and after me – OH NO YOU DON’T!
To explain, I don’t dismiss the need to back up your work. Backup is good, of course, but you have to think it through and ensure it is appropriate.
A false sense of security
Let’s say that you did decide to back up the DNG any time the metadata changes. One obvious downside is that repeatedly backing up the image is going to put a strain on your backup resources.
But the more fundamental problem is that these backed-up DNGs don’t include up all your Lightroom work, just the settings that Lightroom saves as XMP metadata. This data is intended for sharing information with other programs, not backup, and it omits missing flags, stacking, history steps, virtual copies, assignment to collections and published collections…. So the backup value of these DNGs is quite a bit less than you might imagine.
What to do?
1. Back up the catalogue
Instead back up your Lightroom catalogue routinely – mine are set to prompt me every time I exit the program – and that’s all your Lightroom work fully covered.
2. Back up new DNGs
With a DNG-based workflow you back up new DNGs. This “virgin” backup is what safeguards your photos, and you don’t then need to worry about the “working” DNGs which are shown in your catalogue. It doesn’t matter if Lightroom writes metadata to these “working DNGs”, because the work is backed up by your catalogue backup and the pictures are covered by your “virgin” backup copies.
If things did go wrong, this combination of the catalogue backups and the virgin backup DNGs means your work and your pictures can be recovered – 100%.
Separate “virgin” DNGs from the “working” DNGs
One problem is that people trust their backup programs. We just don’t take time out and validate that they are indeed backing up what they are supposed to do, do we? And how confident are we that we would know how to restore our work? So we apply the same kind of lazy thinking to DNG backups. We just think that updated DNGs must be backed up.
But the solution really isn’t difficult – the hard thing is seeing through the assertions that backup is a disadvantage of DNGs. Maybe our backup software can’t distinguish new or virgin DNGs from existing files which have been updated? But an even easier way is to physically separate new or “virgin” DNGs from the “working” DNGs to which LR writes metadata. Put new DNGs on one drive or in one top level folder. Once these new DNGs are backed up, they can be moved over to the drive for working DNGs – which isn’t continually targeted by the backup program.
So while a DNG-based workflow can be attacked, you really have to choose ground that is much less shaky than the old backup argument. It’s a tired old pantomime dame, keeps getting rolled out and shoved centre stage. Next time you recognise it, just remember – it’s behind you!