Finally, it is time to bring everything into Lightroom. Before starting, you have a couple of decisions to make. Review the following information and decide where you want your Lightroom assets to live and how you want Lightroom to manage those assets.

Three Key Questions

  1. One Catalog or Many?

    You are bringing a lot of images. Does it make sense to have them all in one Lightroom catalog? Or, should you create separate catalogs for specific project types (e.g. Family, Client, Personal)? The pros and cons of each approach are myriad and beyond the scope of this guide. Ultimately, the decision comes down to personal preference.

    For the purposes of this guide, we will create one master catalog that contains all images. If you need multiple catalogs, adapt this model to fit your needs.

  2. Mobile Lightroom Drives?

    My colleague, Vanelli, wrote an excellent article entitled: Where Should I Keep My Lightroom Catalog? In the article, he presents a method for building a Lightroom catalog on a mobile hard drive. If you frequently edit in the field or move between workstations, read this article before proceeding.

  3. Convert to DNG on Import?

    As mentioned in DAM Foundations, this guide assumes that you plan to convert all incoming images to DNG. The logic here is simple; the DNG conversion creates one more layer of redundant data protection and allows one to move the source files to another secure drive when the import is complete. The tradeoff is that you will almost double your data footprint as a result.

    If you do not convert to DNG on import, your new source repository will be your working repository. Any safety archives you create will be out-of-sync with your working repository. So, when you do your backups at the end of this step, take special care to design a backup strategy that protects you.

Prepare Lightroom

Thus far, you have only used on of the three repositories created in DAM Foundations.

  • 00_LIGHTROOM (Lightroom Catalogs)
  • 01_PROJECTS (Working Media Files)
  • 99_SOURCE_ARCHIVE (Source Media Files)

99_SOURCE_ARCHIVE holds all of the media you are about to import into Lightroom. At this point, the other two take center stage.

Catalog Storage

First, create a new Lightroom Catalog and save it in 00_LIGHTROOM. When saving the catalog, apply the same naming convention learned in CONFORM. If you elect to create multiple catalogs for your imports, save all of them here as well.

You could elect to save your catalog(s) on your local hard drive (as opposed to your connected RAID or Drobo), but that creates an opportunity for your data and your media to become disconnected in the backup process. So, store the catalog with the data and in a folder of its own.

In 00_LIGHTROOM, create a new subfolder called CATALOG_ARCHIVES. As your catalog grows, you will be prompted to back it up. Do so, and save the archives here.

Why go to all of this trouble?

Lightroom is a referenced DAM, not managed, which means the catalog is only a database containing the location and metadata related to your images, not the images themselves. As a result, when compared to the rest of your new repository, the Lightroom catalog will be relatively small. This small footprint makes it very easy to make a handy local backup of the just catalog. I have reminder set to save the catalog file to a USB key once a month.

Once you have created your new Lightroom catalog, set up your imports with the following parameters:

  • Select Copy as DNG.
  • Set your import destination to: DAM Drive 01/01_PROJECTS.
  • Check Don’t Import Suspected Duplicates.

With this configuration, Lightroom should catch incoming duplicates automatically. And, as desired, cull “bad” media through pre-import selects.

Import Media

If you have Aperture libraries to migrate, bring them into Lightroom first. For best results, use Rich Harrington’s The Essential Guide to Moving an Aperture Library to Adobe Lightroom. If you had iPhoto libraries to migrate, they should have been converted to Aperture libraries first.

Once all of your Aperture libraries have been migrated to Lightroom, import each folder in 99_SOURCE_ARCHIVE. Do so one at a time and, as needed check Into Subfolder and select the subfolder for the appropriate project type (e.g. 01_FAMILY).

NOTE: The import order … Aperture libraries first … is important. If an image was important to you before this migration, it was most likely in either Aperture or iPhoto. By importing those libraries first, you create the broadest possible net with which to catch duplicates coming in from the “loose” files.

Create a Local Mirror

When all of the folders in 99_SOURCE_ARCHIVE have been imported, the next task is mirroring your new working repository to DAM Drive 02. Note that “mirroring” is different than “syncing”. The former is a one-time, one-direction copy that creates point-in-time snapshot; the latter is a bidirectional copy/add/delete function that creates two identical, ever-changing volumes.

For more on the distinction between the different types of backup, check out Vanelli’s excellent article: 3-2-1 Backup for Photographers. This guide uses many of the same principles.

Recall that Offload makes copies verified by file-level checksum. This is the best way to mirror the drives. If you have Offload, use it to mirror the drives. If not, simply drag and drop 00_LIGHTROOM and 01_PROJECTS to their corresponding folders on DAM Drive 02.

Create An Offsite Backup

Once the DAM drives have been mirrored, the only task left is creating offsite backups of both the working and the source repositories. Sound a bit paranoid? Consider how much time and trouble we just went to establish a new, clean baseline media archive. Would you want to repeat all of that work in the event of a catastrophe? Thought not.

With enough room on the DAM drives, once could mirror 99_SOURCE_ARCHIVE as like other two folders. However, that not advised for two reasons:

  • The source and working directories are on the same drives, which reduces the security of the backups.
  • The two DAM drives are intended as mirrors. As new files are added to the primary DAM drive, they should be mirrored to the secondary DAM drive. So, both DAM drives should remain attached to your primary workstation. This further reduces the security of the backup.

With this in mind, do a Get Info check on DAM Drive 01 to find out the combined size of the three repositories. Then, purchase a mobile hard drive with enough capacity to easily fit all three repositories. If you can afford it, get two to make redundant offsite backups. Alternatively, you could use an cloud backup service like Crashplan as your second offsite backup.

With two offsite backups in hand, create a folder on the root of each drive named something like: 20150204_BACKUP_LIGHTROOM.

Within that folder, create a text file named 00_README.txt and include the following information in that file. As you add future backup volumes, this information will be invaluable in keeping everything organized. I include everything below, but feel free to tailor to your own needs.

  • BACKUP OWNER: (your name)
  • BACKUP SIZE: Total size, usually in terabytes, of the backup when created.
  • DATE (CREATION): Date the backup was created.
  • DATE (RANGE): Beginning and end dates of the files included in this backup.
  • DAM DRIVE 01: Drive name, type & location of primary working repository.
  • DAM DRIVE 02: Drive name, type & location of secondary working repository.
  • OFFSITE 01: Drive name, type & location of primary backup repository.
  • OFFSITE 02: Drive name, type & location of secondary backup repository.

Once you have your backup folder and README file created, use the same process (Offload or Drag and Drop) to mirror the repositories to these folders on new drives and/or cloud service. I advise against compressing these archives into ZIP files before or after they are copied to their offsite drives. Doing so only adds time, risk and frustration to retrieving files in the event of a catastrophe.

When your offsite backups are complete, take them to an offsite location (e.g. home, safety deposit box). Then, and only then, delete 99_SOURCE_ARCHIVE from your DAM drives to create more space for your working repository to grow.

Enjoy A Tasty Beverage

Congratulations! It has taken time and effort, but you now have a fresh, clean and mirrored working media repository with at least one offsite backup. Your future self is sure to thank you. So, crack open an adult beverage and pat yourself on the back.

Now, all that remains is to securely CLEAR all of the various source drives we left in the WIPE box after the CONSOLIDATE step.

Doug DaultonDoug Daulton is a writer, photographer and filmmaker based in Las Vegas. His current project is Bokeh, an independent feature film currently in post-production.

Follow Doug’s work: articles · web · twitter · google+.

This Post Sponsored by:

Drobo. A family of Safe, Simple, and Expandable storage systems for capture in the field, editing in the studio, or backup and archive.

ZenfolioLooking for more than just a photo hosting website?  Join the tens of thousands of photographers who switched to the best all-in-one solution to organize, display and sell your photography work online. Learn photography anytime, anywhere, and at your own pace—from bite-sized tutorials to comprehensive courses. Try free for 10 days by visiting

SongFreedom is about artists supporting artists. We’re a music licensing platform with the best music available–stuff from the radio, or your favorite indie bands and soundtracks.  A place where photographers and cinematographers can find the most powerful song for their story with the click of a button.

Capture Cinematic Weddings with Ray Roman.  A Wedding Workshop Series Traveling the US and Canada. Learn to shoot stunning wedding videos from the master of ceremonies, Ray Roman — The World Renowned Wedding Cinematographer! Use the code PHOTOFOCUS for discounted tickets.

The HDR Learning Center Check out new ways to use High Dynamic Range photography to make compelling images. Free tutorials and posts to get results. Produced in partnership with HDRsoft.

Join the conversation! 4 Comments

  1. Just a point of contention, re DNG file conversions: you keep saying that the data footprint will be doubled. DNG files are typically smaller than the source RAW files. If you are keeping the source RAW files, there is absolutely no reason to convert to DNG; just use the originals in your working and backup data stores. If you convert to DNG, there is absolutely no reason for keeping the original RAW files–the data is the same, and in many cases even proprietary information is available (try it out–there’s a focus point plugin for Lightroom, and it works equally well on DNG as it does on CR2 files).

    Advising people to keep the originals after a DNG conversion will just create a waste of space and yield no technical benefit. Either convert and reduce overall required storage space, or don’t convert. Converting and keeping the originals is just silly, from a technical perspective. If you are that married to the originals, EVEN THOUGH the conversion gives you the same data in a smaller space, then just don’t convert.

    • @Matt – I understand and appreciate your notes. Here is why I make those suggestions.

      1. Yes. DNG is typically around 15% smaller than RAW, So, technically, you are only increasing your data footprint by 85%. I am just rounding up for simplicity.

      2. One could just use their camera’s RAW files in both the working and backup stores. Nothing wrong with that. I choose to convert to DNG for the 15% filesize reduction and as, for lack of a better phrase, a “visual check” between working and backup stores.

      My archive has RAW files from Canon (CR2), Panasonic (RW2) and Olympus (ORF) cameras. So, when looking through the filesystem, I know that DNG means a working file and anything else is a backup source.

      3. This guide errs very heavily on the side of caution as it is written from the perspective of someone building a new new baseline repositories … working and backup … from a batch of disparate sources. Redundancy is extreme, by design. What can I say, I am paranoid. 😀 So, I don’t mind the larger data footprint.

      Over time, that is likely to change. Once I am more comfortable with the system, my deep archives will be likely be dumped to create space. But, for now, I sleep better knowing they are there.

      4. As I mentioned in “DAM Fundamentals”, this series is a guide, not a manifesto. It presents one approach out of hundreds of possible methods. I expect people to adjust as needed to suit their workflow and budget.



      • Doug,
        My point is, your footprint doesn’t need to increase 85% or 100%. (and I’m assuming that is an 85-100% increase on top of standard backup of original working file, on-site backup, offsite backup). Convert to DNG, and discard the RAWs. Use the DNGs through all the backup processes; they are just as good as the RAWs (a bit better: smaller and no sidecars).

        OR, skip the DNG conversion, and just use the RAWs throughout the working and backup processes. Which *does* give you the .XMP files to keep track of, too, but that should still be seamless in an automated backup.

        Each to her own, I reckon, but once the DNGs have been backed up on-site and off-site, the RAWs on the CF card are superfluous and don’t need to clutter up your archives. And…RAWs will be corrupted by bad clusters just as easily as DNGs! Which brings to mind Adobe’s new DNG Validation in Lightroom—run that once every couple weeks, and restore corrupted DNGs from the uncorrupted backups and resave Metadata to file. The backup software doesn’t report files corrupted by bad clusters. At least on Windows; haven’t had that problem on Mac yet. But the Validate DNGs, and Find Missing Photographs tools in Lightroom add a layer of safety, if used consistently.

        Speaking of which, time to go validate… 😉

        • MATT – I think I see the disconnect. When I say the footprint will double, I am talking about keeping the working file (DNG) and the “standard backup of original working file” (RAW) … in the repositories. Ultimately, one would end up with two copies of the working repository (on-site/off-site) and two copies of the source archive (on-site/off-site). And, if one is really paranoid, a third copy of both in the cloud.

          I am not suggesting that one keep all of the files on the CF cards permanently. Doing so would further increase both clutter and expense. Rather, I advocate keeping data on the external cards only until the organization and backup process is complete. All source data (CF, SD, field drives) are wiped in the CLEAR step.


Let us know your thoughts...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

About Doug Daulton

Storyteller; words, stills & motion. Bokeh, a sci-fi feature shot in Iceland, is Doug's current project and is now finishing post-production. When not telling stories of the fantastic, Doug loves putting the natural world – from waterfalls to wild horses – in front of his camera while traveling the world. For regular updates, follow Doug on Twitter, Instagram, facebook, Google+, tumblr or his blog.


Adobe, Apple, Business, Cinematography, Photography, Software, Technique & Tutorials


, , , , , , ,