This little essay is for those traveling or working in the field who want to ensure that their photos are backed and are using a camera, not a phone. For me, backup is essential; losing photos because of equipment or card failure, or theft, or anything else, is unacceptable. Most vacationers probably aren't as concerned as I am, so they don't need backup this extensive. Professional photographers on assignment probably do.
Some might reason that backup is unnecessary in the field since the chances of losing photos are very small and it has never happened to them. However, the purpose of backup is to protect against rare events, so that argument is faulty.
With those preliminaries out of the way, here's how I backed up on a recent three-week trip to Greece and why I found it unsatisfactory:
My phone has a ridiculous 512GB of internal storage, so I got a card reader for it and copied each day's images to the phone. These were raw files but I found I could review them with the mobile version of Lightroom. I didn't do any editing, just viewing. My phone was with me at all times, but, of course, phones can get lost, damaged, wet, etc.
Each night I also backed up to a small SSD connected to a NewQ Filehub AC750, which is a little device with a card reader and a USB port for the SSD. After a bunch of annoying initialization, you press a button and the contents of the card are copied to a folder on the SSD. (The phone need not be involved.) If you want, you can then connect the SSD directly to the phone to review the images and check that the backup went OK, since the NewQ has no screen or any other way to examine the contents of the SSD.
This all worked, but I didn't like it, for these reasons:
-
My phone and the SSD were devices I traveled with. I could keep the SSD in my suitcase and my phone in my pocket, but, still, they were vulnerable.
-
Hassling with my phone and the NewQ at the end of the day when I was tired and short of time (dinner awaits!) was a nuisance. Each device required lots of clicking on screen or physical buttons and it was very easy to accidentally fail to backup.
-
Neither the phone nor the NewQ gave me a confirming messaged that the backup went OK.
-
The NewQ creates a new folder each day, so, for example, if you have a 32GB card, you take up several times 32GB if you leave the card in the camera for multiple days. You could, of course, change cards every day, but that's a lot of cards. The NewQ doesn't do incremental backups. This didn't matter for this trip since I had a 1TB SSD, but it could matter in the future, especially if I shot lots of video. Or, for you if you have a smaller SSD.
-
I really wanted to back up to the cloud, and I found an app for my phone, PhotoSync, that claims to be able to do it. But, when I tried it, the app stopped with a timeout error after a few dozen photos and the upload needed to be restarted. That's totally unworkable; since it takes many hours, I wanted it run at night while I slept. In the morning I want a confirmation message, not an error box.
While still in Greece, in my idle moments, I designed in my head the ideal field-use backup device. You put the card in the card reader, press a single button, and it copies the images to the device and to the cloud. It doesn't matter how many times the cloud upload times out, since the device automatically restarts. There's a viewing screen to review the photos.
When I got back, I created the device which I call FieldBackup. Its bigger and heavier than I would have liked, but I tried in on my next trip and it worked perfectly.
FieldBackup is actually the name of a computer program I wrote that runs on a computer running MacOS or Windows, although I only tried it on Windows. You insert the card in the card reader and press a button on the screen. From there, it's all automatic.
First, FieldBackup ingests what's on the card to folders in its internal storage that are named by date. If a photo is already ingested, it's skipped.
Next, FieldBackup verifies the internal backup by calculating a checksum (a type of MD5 called ETag) for the file on the card and compares it to the checksum of the internal copy. Any errors are reported so they can be fixed. Errors like this are very rare and, since the ingestion and verification are fast (compared to the cloud upload, anyway), it makes sense to just report them so they can be corrected right away by deleting the internal copy and rerunning the ingestion.
After verification, the internal files are copied to an Amazon AWS S3 cloud bucket. This might take hours, so you just leave FieldBackup running until it's finished. I've always had internet in my hotel room when I've traveled, but using my phone as a hotspot works OK, too. If you have no internet access at all (e.g., African safari), cloud backup has to wait until you do.
FieldBackup could be changed to use cloud services other than AWS S3, but I didn't care about that.
In my experience, there are lots of timeouts during the very long cloud upload. On one occasion the process errored-out 57 times, but FieldBackup automatically restarted it 57 times and it eventually finished.
After a file is uploaded, the S3 checksum maintained by AWS (ETag) is compared to that of the internal copy and any errors are reported. I haven't seen any such errors, but in theory they could occur.
If a file has already been uploaded, it isn't uploaded again, but the checksum is verified.
Now for the hardware: I certainly don't want to travel with my regular laptop. It's expensive and has far too much on it for identity thieves to plunder. Also, despite its cost, it doesn't have a card reader.
So, I bought an HP 14-dq0760dx laptop for $200. It has a weak processor, only 4GB of memory, and 128GB of storage, but it does have an SD card reader. The processor and memory are more than enough to run FieldBackup and IrfanView, which I use for viewing. Nothing else is installed beyond what came on the computer, and I removed much of that (e.g., Microsoft Office). For most of my travel, the internal storage is enough, but, of course, I can connect that 1TB SSD if I want. If you get a cheap laptop without a card reader, just use an external card reader.
A much smaller, lighter device with more storage would be better, but, even if such a device existed, I'm sure it would cost way more than $200.
Now about security, which is a big issue for traveling with a laptop and uploading to the cloud, because passwords are unavoidable. Here's what I did:
I have a Gmail account just for FieldBackup. I receive and send no email on this account. It exists only because Microsoft and Amazon AWS require an email address. This AWS account is used only for FieldBackup and is distinct from my regular AWS account, which has lots of important stuff. Additionally, I never browse the web with the FieldBackup computer and never, ever, log into a website. Thus, the only password on the entire computer is for AWS access. The computer isn't logged into my Windows Account; that was just to get the computer up and running.
A thief could get that AWS password. If they do, they have a copy of my photos. They could also go to town using lots of AWS services. But, I'll know if the laptop goes missing, and I can use my phone or any other computer to delete the AWS credentials. It's really hard to imagine that an identity thief will want to use free AWS services for a few hours until the account goes away. Not much to be gained with that. (The AWS credentials can't be used to gain access to the underlying AWS account.)
Another approach is to try to protect the AWS credentials with encryption, which is what most programmers would probably try to do, but my approach is better. Let them have the credentials but don't have a pot of gold at the end of the rainbow.
The laptop is big, but it's flat. It easily slides into a pouch in my carry-on bag.
So, there it is: My perfect field backup solution.
(I'll send you the FieldBackup program for free it you want it, but you have to agree to two conditions: Personal use only, and you won't ask any questions about what it does or what's wrong when it doesn't work for you; I'm retired and want to stay that way. You need to be an experienced Python programmer who's familiar with the AWS S3 API. I'd be very happy if someone would take FieldBackup and commercialize it; contact me if you have the capability to do that.)
Marc Rochkind mrochkind.com
The code is here.