Like Johan, I use Hazel on my Macs and it copies my Lr backup catalogs to an archive. That's especially helpful with say brackets of ETTR photos that have horrible looking previews out of the camera. And since it's designed to work with Lr, you can make WB, exposure, and some other changes before importing. So it's a good way to cull before importing into Lr and devoting the time to say 1:1 previews. It shows histograms of images based on the raw, and previews that are more accurate than Lr's. It doesn't have much in the way of backup or renaming or other management tasks, but it can copy to a drive and separate out the culls. I'd suggest FastRawViewer for those that want an ingester to supplement Lr. If you used the second copy as backup, then the chance of having a corrupted image without a good backup copy would be one in 10,000,000,000 images. To do the math: if we assume that the chance of corruption during copying is 1:100,000 (just for the sake of doing the math), then with a 'normal' backup system you would have one corrupted image per 100,000 images, that has no good backup copy either. If you would make a backup copy directly from the memory card on the other hand, then the chance that the same image gets corrupted again is virtually zero. If an image got corrupted during that first copy process, all your backups of that image will also be corrupted, no matter how many backups you make. The reason why I don't like it is because a backup of your main photo disk is a backup of images that have already been copied once (from the memory card to that disk). I use the second copy as intended like Jim and Cletus, but I have to admit that I don't like that the second copy can't be used to make a real backup with the same folder hierarchy. It's a workflow preference issue, and for my preference, I always like to know that my images are backed up prior to my working on them, as it provides me with peace of mind. Alternately, some of us looked to programs like IIP as they offered a one-stop solution prior to ingesting that allowed us to ingest and then proceed knowing that we have done what we need to do (backup our image files), but sometimes put off or forget about as we move ahead. Yes, it can be handled outside of LR, but if we want our backups done up front, as I would suspect is a good practice (and my personal preference), we have to leave LR and handle this backup process with other software. The issue I find frustrating is that Adobe offers you a variety of file handling features, like renaming and moving, when ingesting, so, to some of us, it would seem natural that they might offer to place the backups in a similar folder structure so we can proceed ahead knowing that we have taken appropriate precautions about managing and backing up our files before we begin working on them. Well, given the number of comments that I have seen over the years on this issue, I suspect that there are number of people in a number of camps on how they feel about this issue. I also think it would be a pity if the option was ever removed (which I doubt will happen). Personally, I don't particularly need it to be given any attention (other than to change the date format of the folder name to numeric), though I acknowledge that other users do, and I suspect that there are long-standing feature requests to that effect still lingering on the official Adobe site. That's all I think it was ever intended to be, unfortunately some users wanted to use it as their one and only backup and so were frustrated by the fact that they couldn't control the folder structure that was automatically created. It was always expected that users would indeed take responsibility for backing up their important data (including, but not restricted to, image files), so this "second copy" option was included to protect the card contents while allowing the card to be re-used.
![dim digital image mover dim digital image mover](https://www.saashub.com/images/app/context_images/121/4ixi6kdotha9/dim-digital-image-mover-alternatives-medium.png)
Thus two copies of the card data are created, which allows the card to be reformatted and reused if needed before the next "regular" system-wide backup is run. a copy of the contents of the source card. I do, but only in the context of what I believe was the original thinking, i.e.