Feeling secure about your backup strategy?

Backing up one’s project data is, as every knows, really important. Having a solid, recent backup can save you when things go wrong, and files get deleted or corrupted. However, have you given enough thought to the recovery process and the timing of your backup.

I use Git as my revision control system for all my projects, hardware, software, and writing. Committing often and commenting those changes is the first step in planning for recovery of poor editing decisions and dead-end code ideas. I keep both local and remote repositories for each of my projects. For some client work the remote repository is on their GitHub or GitLab account. For those clients not using Git I keep their projects in private repositories under my GitHub account. Git repositories, properly maintained, provide not only a nice backup strategy, the commit history, messages, and descriptions permit rolling back to previous versions of the project very easy. Plus, if one uses a flexible Git client, my preferred client is GitKraken, browsing the history of a project is easy to do. If you are relatively new to Git I would highly recommend downloading the free version of GitKraken and taking it for a ride. Use this link to download the free version of GitKraken.

In addition to using Git for my projects I also run FreeFileSync to local make a backup of important data, including the project files, onto a local Network Attached Storage (NAS) device. At the end of each day, I start up FreeFileSync set it to shut down the computer when it is done and walk away.

The above strategy has worked well for me for many years, most of my file recovery/reversion has been done using GitKraken, however, occasionally a file that was not tracked using Git requires recovery and the image of my data created by FreeFileSync came to the rescue.

Until just a couple of days ago!

I have not been able to reproduce the actions I took that caused the loss of a new project’s data. The data represented about 10-15 hours of work and had been dutifully committed to Git many, many times over that period of time. Somehow, still unknown, my actions lost the whole local repository and it had not been pushed to a remote repository. At the end of my workday the project, a schematic design, was about 95% complete and committed to Git; as I closed my office I ran the backup.

The following day a few mores hours on the schematic and it was just about completed. Whatever I did after that, late in the day, the project disappeared from my computer. I was mortified, this had never happened to me before during a career spanning multiple decades. Being late in the day I decided I would address the issue the next day, after a good night’s sleep. Before closing the office, I ran the backup.

While having my morning coffee the next day I realized what a huge mistake taking a backup of the project files the previous evening was. My backup synchronizes an external drive with a set of folders on my computer and the most recent backup had done just that! Prior to running that backup, the external drive had the 95% project on it. After that last, fatal, backup the project was also gone on the external drive.

Thinking about my backup strategy I now realize that at a minimum one should back up to alternating destination folders, in this way I would have still had access to my lost project. In fact, if the external drive has enough space, I would recommend having set of destination folders to give more historical backups.

The majority of the time backup data is not required, however, it must be easily accessible. So, think about not only your Source Code Management (SCM) strategy, but also the scenarios where you may need multiple sets of historical backup data.