The essentials of storage back-up and restore

As the need to keep data and information safe have gained greater importance over the years—companies having realised their importance in business success and competitiveness—so has the need for back-up and restore solutions. V Vivekanand offers a guide on the essentials of storage back-up and restore

Companies that survive on data and information consider them to be the most important assets, rather than just by-products of business processes. This scenario has rendered extreme importance to storage resources and protection of these resources. Keeping data and information safe is critical to their business success and competitiveness. Consequently, backup and restore become the most important components of protecting information. It is a known fact that data storage requirements are skyrocketing, so is the complexity and cost of managing data. In such a scenario it is important that companies choose their back-up and restore solutions very carefully. As a result back-up and restore have become the largest component of the total cost of storage ownership. According to Gartner, back-up and restore costs account for 32 to 54 percent of the total cost. These costs will further increase for companies that work on a 24x7x365 basis.

Besides, the increasing use of collaborative computing applications such as Lotus Notes and MS Exchange, data warehousing/decision support systems and business automation applications like ERP/ CRM drastically increase the need for disaster recovery solutions. Each of these systems needs back-up and restore with varying degrees of complexity. For instance, business process automation systems run on relational databases that provide a single view of the entire organisation from the shop floor to the boardroom. In such cases, back-up and restore solutions command very high value in order to protect the operational environment of the business.

Enterprise storage systems score high

But while discussing this issue it is important to understand what kind of storage environments are most suitable for implementing effective back-up and restore functionalities. Analysts from IDC feel that enterprise storage systems are most apt for deploying back-up and restore functions. Cost is a very important consideration for enterprises deploying enterprise storage solutions. When we use the word ‘enterprise storage’, it implies a consolidated storage system that is capable of supporting multiple operating systems and multiple mainframe, UNIX and NT servers on a single storage system. IDC analysts also note that cost comparisons between enterprise storage systems and distributed storage systems indicate that TCO is lesser in case of enterprise storage systems rather than distributed storage systems. One might be surprised as enterprise storage systems incur higher hardware and labour costs. However, it is important to notice that lowering of storage management costs more than offset the hardware and manpower costs. IDC further observes that the justification of storage on a mere $/MB basis is not enough. The justification comes from improvement in storage management efficiencies, avoidance of costly losses, and enhancement of business value. This kind of an approach makes storage back-up and restore all the more important. Other IDC studies have also revealed that restore is 99 percent successful in enterprise storage as compared to 25-75 percent success in distributed and desktop servers.

In an enterprise storage system the complexity and cost of back-up/restore functions varies, depending upon whether it is conducted at the volume-, file-, database- or application-level. The lower levels of back-up may be the easiest to execute from a hardware standpoint, but may be the most expensive in terms of management costs and downtime required to recover the applications, which are dependent on that data.

Consider volume-level back-up/restore for instance. This may seem to be the easiest to perform from a software and hardware point of view. But while undertaking this it has to be ensured that controls are implemented to enable logical and temporal consistency of the data on the volume along with the application view of the data. In order to ensure this consistency, a volume-level back-up requires that all applications be stopped and data in the memory and cache be flushed to the disk. If this volume is part of an application database, it must be coordinated with the back-up of the application’s logs, indices, repository, updates, exports, and recovery scripts, spread across multiple volumes or generations of volumes.

File-level back-up/restore

When we look at file-level back-up/restore, it is more difficult to perform, as it requires the back-up software to know and communicate information on the locations and extents of a dataset or file. Further file-level back-up between platforms requires a communication between a back-up agent on the client system that can interrogate the file system, and a back-up agent on the server that records the file-control information that can be used for retrieval. Since it is done over a network, it has to be ensured that the speed of the network is not constrained and back-up time is minimised by transferring data at channel/bus speeds rather than at network speeds.

While performing database level back-ups two modes are usually followed. They are ‘cold’ and ‘hot’ back-ups of databases. In ‘cold’ back-ups of databases, the applications running against the databases must be stopped and all the in-flight data must be flushed to the disk before back-up is started. The applications must be stalled until the back-up is complete, thereby resulting in downtime. In order to reduce this downtime, companies use database utilities to do ‘hot’ back-ups. Online or ‘hot’ back-ups still require downtime. However, on-ce applications are stalled and the data is flushed back to the disk and a sync point is established, applications can resume in a read access mode. Online database back-ups require speed and the longer it takes to do the back-up, the more new transactions accumulate in the logs, and the longer it takes to re-sync the database after the back-up . In order to reduce downtimes of this nature there are solutions offered by many storage vendors that take snapshot copies for back-up of mainframe data.

Application back-up/restore

However, when we look at application back-up/restore it is dynamically different. Application back-up and recovery involves the back-up and recovery of logically related groups of database objects across multiple databases. Back-ups must be synchronised to generate a consistent recovery point across multiple servers. This requires that all transactions active against target objects be placed on hold, and the objects be switched to read-only mode until the back-up is completed. Application back-up requires a central management server to control and coordinate back-up and recovery.

The recovery process

Having looked at the complexities involved in back-up and restore functions across different levels, let us now take a look at the issues involved in the end-to-end recovery process. The process of recovery is initiated once a failure has been detected in the system. Failure detection in high availability middleware can be detected automatically and the hardware connections for data services automatically switch over to a stand-by system. However, once the hardware is recovered, a number of steps are required to be followed.

If a file system was in use it must be recovered. Further, if a database instance has failed it must be restarted and the configuration files must be read. The recovery of a database begins with a roll-forward, which involves reading through the redo log files, and rebuilding and reapplying each applicable transaction. Further, after roll-forward recovery is completed, a roll-back recovery is done to undo any uncommitted or incomplete transactions that belonged to the failed system. If disk mirroring was in use, the consistency of mirrors must be checked. If they are not in sync they must be reconstructed from the logs. This step can be avoided through use of disk arrays. Finally, once the database is recovered, the application must go through its own recovery and this depends upon the application itself.

Consequently, organisations that want to implement enterprise storage systems should choose solutions that address back-up/restore requirements adequately and reduce the total cost of ownership. The storage solutions to be deployed should enable creation of snapshot copies for near-instantaneous back-up. The solutions should also be able to deliver high-performance volume-level back-up of open systems data. Lastly, the installation of the back-up/restore solution must be properly planned to ensure complete and timely recovery.

The author is business development manager for India with Hitachi Data Systems.

He can be contacted at vivek.anand@hds.com