SRM improves backup operations

Integrating storage resource management (SRM) tools with backup/recovery software streamlines the overall backup process.

By Raymond Chew

When you are looking at the business issues driving storage management, one thing is clear: Storage isn't just about data backup anymore. Business executives need to support applications for initiatives in such areas as CRM, accounting, communications, and regulatory compliance. IT needs to support those applications with an efficient storage infrastructure. While data protection and availability are critical components in supporting business objectives, efficient management requires a level of intelligence that can only be delivered via more holistic storage management.

Storage resource management (SRM) can provide intelligence about data that will streamline backup and decrease the inefficiencies associated with traditional backup methods. SRM can further improve the data-protection process through automation of backup and through in-depth analysis and reporting of backup operations.

Although storage administrators are expected to handle multiple tasks, they expect storage management software to help them accomplish as many tasks as possible. Therefore, storage administrators demand integrated solutions that can simplify the various aspects of data protection and storage management in general.

The current state of backup

Conventional data-protection practices are currently built around backup schedules. This means that backup operations are based on time-based guidelines. With schedule-driven backup, data protection is usually accomplished using a combination of backup methodologies—such as full, incremental, or differential—usually without reports on what has actually been backed up. Schedule-based backup usually forces backup operators to back up everything—from complete storage volumes to departmental shares, assuming sufficient time is available during the backup window.

The difficulty in backing up all data in the allottedwindow typically results in some level of unprotected data. Furthermore, backup operators often aren't sure whether their backups completed successfully.

The lack of insight into backup operations can be attributed to various factors. When the information is available, it may be too difficult to find in the various backup logs spread across multiple backup servers. Also, backup operations may lead to some files that may not be backed up because they were left open. This problem is especially thorny with backup software that does not include open file backup. And storage administrators constantly face the difficulties of managing multiple backup products, platforms, storage devices, and applications.

Driving backup with SRM

The next generation of data protection will go beyond today's rudimentary backup operations and occasional data-recovery test runs to help ensure that data can be easily recovered if disasters occur. The next steps in data protection will involve the backup of data using SRM intelligence. This approach takes data protection a step forward by incorporating various storage management technologies and strategies that protect data by integrating the information provided by SRM-oriented monitoring, analysis, and automation.

SRM-driven backup involves continuous, interrelated steps that revolve in an open-ended cycle.
Click here to enlarge image

SRM tools provide backup operators with extended visibility to files that have become vulnerable and may have to be backed up. Integration with backup tools enables SRM to scan and filter backup logs, backup data repositories, and activities to identify bottlenecks, pinpoint failures, and severity levels, and more. SRM also keeps track of the data that has been backed up, archived, or migrated so that administrators are aware of the location of the files that have moved and how to retrieve them when required.

Methodology for SRM-driven backup

SRM-driven backup involves three continuous, interrelated steps (see figure):
Step 1: Data classification by SRM for backup
Step 2: Kickoff of automatic backup operations
Step 3: Backup reporting and analysis

Step 1: Data classification by SRM for backup

Most SRM tools provide data analysis and classification to facilitate the grouping of data sets. Files can be analyzed based on various criteria to fit the parameters that will be used to streamline the data to be backed up. The criteria can be related to any file attributes, such as size, age, ownership, and access/modified time. For backup purposes, these criteria provide administrators with information to streamline data protection. SRM intelligence provides a more effective method of protecting data by backing up only the relevant changed files or data blocks instead of backing up the whole volume of data each time backup occurs. The backup of streamlined data sets provides efficient use of backup resources and the backup window since non-changed or non-business-related data is not included in the backup process, less media is required, and backup time is shorter due to smaller data sets.

Step 2: Kickoff of automatic backup operations

Upon collection and reporting on the file/data metadata, SRM provides backup operators with additional insight into how data status has changed since the last backup. SRM reports on which files were accessed and modified, when the files were accessed, where the files are located, who accessed the files, and additional details. This information keeps storage administrators apprised of vulnerable data that has not been backed up.

Storage administrators can use SRM-related intelligence to streamline the volume of data that has to be backed up, giving them a better chance of making it through the allotted backup window.

In addition, SRM enables storage administrators to kick off backup and archival based on capacity thresholds. When volume usage breaches a threshold, SRM can automatically notify the administrator and/or automatically kick off pre-defined actions such as the data-archival process.

The next step involves transferring the reports of relevant files based on selected criteria (e.g., file age, file access/modified dates, access frequency rates, and file ownership) to the backup/recovery tool. These reports provide the building blocks for the necessary backup policies in backup/recovery tools.

Step 3: Backup reporting and analysis

Upon completion of SRM-driven backup activities and other normal backup operations, SRM can provide heterogeneous backup and media reporting and management support. Integrated with multiple vendors' backup/recovery tools, SRM provides the following:

  • Centralized reporting of backup jobs;
  • Centralized monitoring of backup servers, clients, and activities;
  • Backup event monitoring;
  • Centralized, aggregated log viewing and scanning; and
  • Device and media status reporting.

SRM analytical capabilities enable users to perform effective backup planning and analysis so that the backup success rate can be optimized. Backup analysis includes

  • Backup throughput evaluation using SRM's trend analysis;
  • Backup window analysis (e.g., start and end time of backup jobs);
  • Backup coverage analysis (what is and isn't protected); and
  • Restore-media analysis to determine the set of media required for a restore.

SRM provides centralized reporting and trend analysis on the present status and history of backup events, media, and overall performance. For users with multiple backup vendors' products, SRM can provide a single interface. SRM can also facilitate reporting on a backup environment comprising multiple, geographically dispersed backup domains and servers. This capability simplifies backup resource management for administrators who can't afford to get bogged down with repetitive reporting activities or deal with specific idiosyncrasies of each backup application.

SRM can scan and provide real-time reports on backup events. The backup events are "floated" to the event management interface so that administrators are informed of backup events that need to be addressed immediately upon notification. Pre-defined events can be populated in the event console as desired.

The backup events can then be shared or assigned to respective backup operators through SRM's role-based access designation. The assignment of backup event handling can contribute to backup management best practices.

SRM can also "scrub" the backup application's server logs to look for specific pre-defined events. Real-time backup log scanning enables users to get alert notifications when certain backup events occur, such as failed or incomplete backup jobs. SRM facilitates centralized and aggregated viewing and monitoring of multiple backup server logs and filters to look for specific event triggers. Log scanning capabilities enable users to analyze the performance of backup utility during predefined periods of operation.

In addition, SRM provides device and media management capabilities. The software provides centralized reporting on all backup media and usage patterns, current status of changers or media, backup servers that may be running out of media soon and will need replacement, and events such as tape failures, etc.

Benefits of SRM-driven backup

Integrating SRM with backup/recovery operations can provide benefits such as

  • Uniform data-protection policies;
  • Fast problem resolution relating to data protection;
  • An auditable record of data backup;
  • Effective deployment and reduced cost for regulatory compliance processes;
  • Accurate planning and budgeting for future capacity requirements;
  • Improved utilization of storage hardware resources by backing up only changed data;
  • Increased storage administrator productivity; and
  • Cost savings by reducing staffing requirements for data-protection activities.

Organizations that already have both SRM and backup/recovery tools, but have not yet integrated these capabilities, should consider the payback from the synergistic combination of technologies.

Raymond Chew is director, product management, of BrightStor solutions at Computer Associates (www.ca.com) in Islandia, NY.

This article was originally published on August 01, 2004