I am a photographer myself, this is what I do: I store all my photos (both RAW+JPEG) in a Subversion repository (I guess Git could be used as well, however, I started doing this way back, before Git existed). I have a workstation on which I do post-processing of my photos. The photos I work with are in a Subversion Working Copy. I "commit" the photos to the Subversion Repository which runs on a small server with some external USB 3 harddrives on my local network. I also have a two spare external hard drives that I periodically copy the Subversion Repository onto. One of these drives is always stored at my parents' place. My parents live a few hundred miles away. Every time I visit them, I bring the other extra hard drive with me and switch it for the one at my parents. This way, I always have an off-site backup at my parents'.
My workflow is this:
This gives me several advantages:
- Automatic versioning of photos. I can edit a picture and save it and if I weeks later regret my editing, I can always restore it back to the original. Without me having to manually manage multiple copies of the same picture.
- A guarantee that nothing will ever be deleted -- even if I delete something and commit, I can get it back by checking out a previous revision without having to resort to backup
- A multi-level backup strategy: Files exist in the working copy on my workstation, in the Subversion Repository, and in the backup. It is extremely easy to get files back from the first level "backup" (the repository).
- I can easily check out (a portion of) my photos everywhere if I want to via Subversion.
I notice the following disadvantages:
- Performance: Subversion is not particularly fast on large binary files. This is not a problem on modern hardware though. My current Subversion server is an Intel Atom and it handles it nicely while at the same time doing SSL encryption + LUKS encryption. My old server had a very small AMD Geode embedded CPU that did have hardware support for AES, but choked on the Subversion. This, however, was an extremely slow CPU. Most modern, low-end smart phones will run circles around it.
- Disk usage: Subversions working copy format is not very space efficient. The working copy will use about 2x the actual size of the photos. In practice, this is easily solved though by having a working copy by year. So that you would normally only keep 2012 and maybe 2011 folders in your working copy. When you need to work on older photos, checkout the relevant part in a new working copy. Another option is to use a non-standard working-copy format. I forgot the name, but there is a working copy format that allows for 1x disk usage. This means the your working copy will not take up more space than the original files. Only if you change a file locally, it will take up more space.