Well, I am not the kind of guy who is impressed by cool charts and I found two flaws in Chase workflow.
Flaw 1: Archive the cards, not the file!
First, I would remove Aperture from the On Location process. A better way to import data from CF Card is to create disk images of these cards. This is a trick I picked from the book From Still to Motion. It is a better way to organize files by keeping all related data in the same place (DMG). Also, if you archive the physical cards, it makes the matching of virtual archives to the physical ones trivial. I never really though about keeping CF Cards until Shane Hulrbut mention it and with the decreasing cost of CF cards, it makes a lot of sense.
Flaw 2: Live work backuped with Time Machine? WTF!
First off, don’t get me wrong. Time Machine is good, very good. It is a set and forget kind of thing: it will backup files that have changed between two drives every x minutes. That is its strength but also its weakness: it does the copy based on time and not on milestones.
Lets take a worst case scenario: Time Machine just copied your project, then you decide to make three variations of one of your file. A few minutes later, you are done and while waiting for the automatic backup to happen, disaster strike: HD failure!
Here is another scenario: in the span of an hour, you modify a file three times then realize that you need version #2 which was not backuped by Time Machine (it saved #1 & #3). What can you do?
These are two example of how time based backup can (and will!) fail. While they are very good a copying stuff when you would not think about it, they dont have a notion of what is important for you to backup. Losing an hour of work on a file does not always mean that you will be able to get it back by spending another hour on it. Creativity and inspiration are not a function of time.
The classical approach to this kind of problem is to “save as” every minute and create a multitude of copies of a single file and manually backup this file on another drive. Not very practical.
Fortunately, there is a better solution. It is free, powerful and easy to use! And you know the best part? You don’t even need a complex IT infrastructure to make it work. I would never dare to say that I am the first to think about it, but according to Google, I am the first to blog about it: using GIT as a version control/backup system for your visual assets!
What is GIT
GIT is a distributed code versioning system. It is used by programmers to keep an history of all the modifications done to each file and distribute these files/change. In plain English, it means that it tracks changes to files, can go back to any milestones in its history and can apply all the modifications done on workstation to all the others.
GIT is the industry standard in the IT field and while its features set is an overkill, its performance and ease of use makes it a mandatory tool for every paranoid virtual asset owner.
How to use GIT
Understanding how to use GIT is out of the scope of this article. I am planning to publish a detailed article on the subject soon. If you can’t wait, and want your work to be meteor-proof, go take a look at the GIT Ready website. While the content is targeted at programmers, it will teach you the basics (tips: just read the sections about the init, add, commit, push and clone commands).
If there is one thing I hope you learned from this post is that a full featured backup solution is not simply about having multiple copy of your (RAW) files in various location. That is only part of the equation (which is fully covered in Chase video). The other part is making sure that you will also be able to access the version (live work) that is important to you (which I will cover in an upcoming article).