This article can also be found in the Premium Editorial Download "Storage magazine: Better disaster recovery testing techniques."
Download it now to read this article plus other related content.
Value of data: Another key risk is being unable to ascertain the value of data under your management. If data hasn't been valued, it's unlikely to be managed appropriately and may not be available when needed. Inevitably, the value of data is equivalent to the value of the business application accessing it.
In many organizations, once an application has been implemented, its associated data is identified and placed into complex command lines of various backup engines. Over time, all trace of ownership becomes lost and no one knows what application owns a particular file. It's critical to be able to tie data to an application and to tie that application to the business unit it services.
The key identifier of data--its application and related business owner--must be maintained in a manner similar to that of an asset register. This register should include data interdependencies, both parent and sibling. Without an understanding of where data comes from and where it goes, application interdependency can't be determined. Without application interdependency, recovery of a logically verifiable point becomes extremely difficult, if not impossible. This means that while applications and data may be recoverable, the combined application functionality may fail because dependencies weren't synchronized and managed during the recovery process.
Archiving awareness: With the emphasis on information lifecycle management and compliance, many organizations
Data retention: Retention policies are often created without close consultation with business units or are based on rudimentary compliance requirements. Organizations often institute an across-the-board retention policy. In years past, data volumes weren't high enough to warrant particular differentiation and there were few compliance requirements beyond IRS retention rules. Today, data is growing at an annual rate of 50%-plus and company lawyers are increasingly tempted to mandate keeping everything forever to avoid the consequences of non-compliance. In this environment, it's critical to develop a retention class of service with attributes identifying retention periods for various legislative initiatives, as well as required immutability, rendering, integrity and security attributes. Addressing these complex issues outside the framework of a class of service can lead to significant complexity, which could impact administration costs and lead to potential legal exposure in retention, retrieval and security compliance.
Recovery objectives: Unrealistic recovery point objectives (RPOs) and recovery time objectives (RTOs) are a major risk exposure. In an attempt to respond to business needs, RPO and RTO commitments may be made that don't adequately consider the realities imposed by logistics and technologies. From a logistics perspective, any RTO of less than 12 hours will probably require an automated failover. It's impractical to expect people to evaluate and declare a disaster, initiate DR at alternate points, notify the DR team and sequence the recovery, resynchronization and restart of applications in less than 12 hours.
On the technical side, the infrastructure needed to support a one-hour RTO is the same as for a four-hour or eight-hour RTO. It's only when the delta hits 24 hours that significant differentiation in the support infrastructure is required, except perhaps in very small organizations with a limited number of servers. Getting the DR team to the alternate site is one major challenge; sequencing the multitude of servers that need to be brought back is another. Once physical recovery has been completed, additional effort is required for logical synchronization that can blow out the most practical recovery objectives. DR tests that use a Dev/Test/QA infrastructure to bring applications into actual production mode (i.e., operated by users) for a 24-hour test period will reveal any exposures in this area.
Data integrity: At some point in any compliance investigation, you must prove that your data hasn't been changed by unauthorized people/functions and hasn't been corrupted by intent/malfunction. The policies and SOPs supporting the protection of data integrity must include audit-agreed checkpoints and controls. It's not enough to have data archived on WORM media. Your SOPs and related controls must demonstrate a chain of custody that protected data from change the moment it reached a status that demanded immutability. A great example of this need is when to capture immutable copies of received and sent e-mails. Certainly, it must precede any capability for deletion or modification; the SOP must demonstrate--through completion, compliance and quality metrics--the consistent accomplishment of stated goals.
This was first published in October 2005