Perhaps some might think this is a rhetorical question. One of the more traditional responses to this question is “a backup is a copy of data”. The general problem with most definitions of “backup”, including this common response, is the failure to mention the actual reason why backups are made: recovery.

Backups require a healthy dose of paranoia and therefore no matter how much they are automated, they still have to be monitored to make sure they succeed. They have to be tested periodically to ensure that components that were working weeks or months ago still work now. They usually involve the highest number of removable parts and are, for many organizations, one of the least correctly funded parts of the IT environment. Being responsible for backups can also be one of the most thankless tasks in an environment, as for many organizations they are not considered until something fails — i.e., the only time the backup administrator gets attention is when there are problems. Therefore, even backup consultants might say that “backups are a pain”.

A backup is a copy of any data that can be used to restore the data as/when required to its original form. That is, a backup is a valid copy of data, files, applications, or operating systems that can be used for the purposes of recovery.

By using a definition of backups that includes the purpose of the backup — that being recovery — I force attention not only onto backups, but such critical activities as recovery, recovery testing, archival, disaster recovery, and disaster recovery testing. Too often, consideration of “backup systems” neglects these critical activities until they are required!

The purpose of backup systems should be entirely self-evident. Unfortunately this is frequently not so. For instance, a known ploy of outsourcing firms is to have Service Level Agreements (SLAs) that focus only on backup requirements, rather than recoveries. While it’s certainly the case that recovery targets can only be accurately set when created on a per-system basis, this deliberate obfuscation of the purpose of the backup system can only create trouble for the company whose data is (or is not) being protected.

The problem with so many supposed “backup systems” in enterprises today is that they are put in as an afterthought. Entire systems will be installed without any backup planning, and when it is finally considered, there is either insufficient interest or insufficient budget to install an acceptable backup solution. A system with, say, 100 GB of storage might have a DDS-5 tape drive attached to it just before it becomes “production ready”. In short, this has no testing, no capacity planning, and no chance of working acceptably. As default storage capacities on systems continue to grow by orders of magnitude, this problem only continues to grow with the industry.

Unfortunately, once one or two of these “not quite barely good enough” systems slip into an environment, it sets a precedent that can be difficult and perhaps costly to break. However, what should be seen is that the cost exists only at the initial capital investment, and in fact the cost from not changing to a properly designed enterprise backup system could be disastrous.

It should be understood that ongoing spending on a backup system mostly falls into operational expenditure rather than being a continuous exercise in capital investment. That is, each deployed enterprise backup system will have an initial investment followed by periodic expenditure. For smaller organizations, this differentiation may not make much of a difference, but for larger organizations, this can make a considerable improvement in how budget is allocated.

In reality, the backups themselves have a life span that exceeds that of the system(s) they are protecting, something that is not necessarily considered as part of the planning process of a system. For instance, we can describe the life span of a production server on the basis of how (and when) backups are performed over its entire life cycle. This might resemble the following:

1. Installation
2. Development cycle
3. Test cycle
4. Production operations
5. Post-production

What this should demonstrate is that backups for a system may start weeks or sometimes even months before end users first touch the system, and will continue to be maintained in some fashion possibly for years after users have ceased using the system.

This level of planning is rarely seen in organizations, usually due to a misunderstanding of the purpose of backups. Too many companies focus on backups as if they themselves are the end requirement — an ongoing budgetary black hole whose results are rarely needed.

Instead, we need to remain focused at all times on the real definition for backups — that being something that facilitates recoveries. Indeed, considering the most severe of circumstances, we can define the purpose of backups as follows:

Backups are performed to allow a company to continue to operate, rather than going out of business, in the event of a failure occurring.

Maintainers of backup systems often face a persistent struggle for budget, compared to the budget allocation processes for other departments within an organization — even in comparison to procurement within other sections of an IT department. When considering the purpose of backups, this is not sensible; from a corporate continuance perspective, to give short shrift to the backup budget is potentially disastrous.

It is commonly the case that people only know about their system administrators when something goes awry. The best system administrators are therefore often seen as the ones whom end users don’t know. Similarly, in an optimum operating environment where no problems occur, few people will know of the backup administrator, yet that doesn’t mitigate the need for backups.

Share/Bookmark