Posey's Tips & Tricks
Should You Back Up Static Data?
There's another threat to consider when it comes to developing a backup strategy for static data on an active volume: bit rot.
One of the more interesting backup questions that I am sometimes asked is whether or not an organization should back up its static data.
Before I can answer this question, I think it is necessary to discuss what I mean by static data. Let me give you an example from my own organization.
I have been writing about technology since the mid-1990s and, as you can imagine, I have accumulated a pretty massive collection of Word documents and screen captures over the years. Believe it or not, I keep all of this data on a working volume because I sometimes have to refer back to an old article or to one of the books that I have written.
However, I have another volume on which I store the video-based courses that I have created over the years. Video takes up a lot more space than Word documents and screen captures, so I keep my old video courses in a separate location.
The volume containing my video courses isn't exactly an archive because it is online, readily accessible and performs just as well as my primary data volume. Even so, the data within that volume is relatively static. The old courses never change and I almost never add anything new to this volume.
So, back to the question at hand: Should the type of static data that I just described be backed up or not?
I think we would probably all agree that at least some type of backup is warranted. After all, I kept this data for a reason and obviously don't want to lose it. The only way to guard against data loss is to have multiple copies of the data, so a backup of the static data definitely has its place.
So maybe the better question is, should you keep backing up the data?
I'm not sure there is a universally accepted answer to this question, but my perception is that it is, indeed, a good idea to continue backing up the data -- but with some caveats. Let me explain.
The first step in developing a backup strategy is to determine what threats could potentially put your data at risk. These threats typically include things like volume failures or ransomware infections. When dealing with static data residing on an active volume, however, there is an additional threat that has to be considered: bit rot.
For those who might not be familiar with the term, bit rot refers to the slow degradation of storage media over time, thereby resulting in file corruption due to individual bits gradually becoming unreadable. Obviously, the threat of bit rot points to the need for one or more additional data copies, but there is more to consider.
You will also need to consider the backup media's reliability. Suppose that you created a static data volume 10 years ago and created a couple of backups at the same time. Let's also pretend that the data has not been changed since that time. Because the data hasn't been changed, it has not been backed up aside from the original backups that were made a decade ago.
In all likelihood, the storage infrastructure would have been upgraded a couple of times over the years, and the process of migrating the data from old storage to new storage would help to guard against bit rot. For the sake of argument, though, let's pretend that the original media has been in use all this time.
With that in mind, what is the state of the static data on the original storage? What about the backups? Since they haven't been touched in the last 20 years, has the backup media suffered bit rot of its own? If the data was backed up to an optical WORM disk, data loss probably hasn't occurred. Tapes also tend to have a really long shelf life as long as they are properly stored, but there is at least a potential for data loss to happen.
My approach to protecting static data is to back it up at least once a year, but with one of those caveats that I mentioned earlier. The caveat is that I never overwrite any of the previous backups. There is a very important reason for this.
Suppose that I decide to back up an aging static data volume, and I overwrite an existing backup of the volume. Let's also pretend that some degree of bit rot has occurred on the volume but has not yet been detected. That means that the backup operation is backing up at least some amount of corrupt data. If an old backup is being overwritten, then data that is potentially still good is being replaced by bad data. That's why I never overwrite aging backups of static data.
Obviously, every organization's needs are different, but if you have online volumes containing aging static data, then it's probably a good idea to periodically back that data up, even if the data set is not included in your regular backup jobs.
Brien Posey is a 20-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.