| COLUMN |
Backups Are NOT Archives |
 |
 |
|
By Brian Sakovitch
06 Feb 2008 | SearchStorage.co.uk
|
|
While working in more backup environments than I care to count, I occasionally come across a documented operation referred to as 'archive.' But it never is.
These operations are, more often than not, a simple data dump performed by an enterprise backup application directly to tape and then taken somewhere up in the mountains, until someone decides they need access to it later. I'm regularly informed that this is the business's "archiving solution." This process is neither 'archiving' nor any kind of 'solution' to good data management.
Archiving itself is still a relatively immature form of data management, but that's exactly what it is – data management. Though enterprise backup applications are capable of an incredible number of tasks these days, backups are taken to satisfy the need for data protection, not for archiving purposes.
You take a backup to protect an important document that you've created so that the next day, when it eventually becomes corrupt, you can go back and magically copy the bits and bytes of your previous day's work over the garble that your document has become. You work has been 'protected' because a 'copy' was made from a previous version.
Archives are not data copies. Archiving isn't going to help bring your database back to life in the event of a disaster. Where backups can be (very) simply described as a copy operation, archives are a move.
Businesses typically employ an archiving solution to accomplish two main goals; regulatory compliance, and to cut storage costs. While we are obligated to comply with industry regulations, every IT organisation is focused on cutting storage costs.
Basically, archiving moves data that is of a certain age, and infrequently accessed, off primary storage pool and into one that costs less. This move may occur a number of times within a given near-line archiving solution until the data is, or nearly is, immutable and rarely accessed. It is then moved to the cheapest form of storage admissible (usually tape) and shipped to an off-line location.
This cycle requires fewer requisitions of primary storage capacity, and frees up the resources on that primary storage for better performance. The first point directly drives cost reduction in a strictly budgetary manner, the latter can dramatically slow the increasing access times of the primary storage pool saving time (time = ££). The latter is also especially important for those giant, high profile databases and their search functions. A backup creates a copy of a portion of data, and having more of the same data lying around most definitely does not decrease the costs of the storage environment.
Administering a backup environment is essentially an officially permissible form of extortion. Application owners are forced to pay for protection services, or else they face roving bands of data corruptors at their own risk. Archiving is more like hiring well organised movers to wrap your data in boxes with lots of tape, get it out of your way, and keep it in a secure storage locker close by until you need it again or can throw it out. Of course, both backups and archives provide many complicated and wonderful services.
In the end though, they are most definitely NOT interchangeable. That old "archiving solution" - backing up old data to tape and then sending it to an offsite location indefinitely - may work well enough for certain pools of structured data, but is merely a long-term backup and should be named as such.
About the author: Brian Sakovitch, senior consultant at Glasshouse Technologies (UK), has followed a 6 year path in backup technologies ranging from hands-on installation and implementation, to design and theory. Three of those years have been with GlassHouse US focusing on a number of predominantly backup related engagements for companies of all shapes and sizes.
|
