IntelliSnap Recovery Manager (IRM) - Best Practices

Security and Storage Policy Best Practices

Security Roles

The power of a Storage Array in providing fast full volume recovery changes data architectures and SLA alignment. Any technology providing fast sweeping recovery directly linked to production data can be potentially dangerous without proper controls. Revert operations are perfect for massive data corruptions on productions volumes that require fast recoveries, assuming the proper controls are in place to allow only those who understand what the defined action will do for/to the business. Typical script based tools lack these controls and expose environments to high risk side effects with very little oversight or reporting. A single miss-aligned scripted argument could bring an entire production database environment down and cause catastrophic data loss. Further, restoring data through array based reverts when a single file/database is all that is necessary can destroy entire collections of data resetting the environment back hours or days if done incorrectly. Recent mail, revenue transactions, business data, etc. would all be lost due to a simple mistake in operation.

Rather than risking the business to make or beat the backup window with scripts or standalone tool sets, an integrated data management platform should provide proper safety controls to allow critical actions to entrust the right users at the right time while ensuring a reporting and audit system to overlay the full end-to-end view. In most medium to large environments, application operational responsibilities, backup, DR, compliance and audit may be distributed functions that need to be coordinated into a single policy. The embedded role based security system native to Commvault automates this function.

For Example, a customer may have three specific roles within an operations environment:

• Backup Admins

• Application owners (DBAs)

• Audit & Business Compliance

Each of these roles “owns” specific responsibilities for managing and protecting the enterprise. Backup Admins are the typical day to day operators with access to perform standard backup and recoveries, manage media, issue reports, etc. However, the Backup Admin Role may not be the right team to execute application -level recoveries or have the capabilities to issue array-based reverts for recoveries due to knowledge and awareness of the application architecture. The Application Owner Role is not so concerned about the general day to day backup environment, but is laser focused on the application space they own. They need to know what tools are available to them and who has the capabilities to execute on those toolsets at any time as they manage the applications running the business. Any recovery operations involving their applications, especially powerful techniques such as Array reverts and snapshots must be managed from their group to mitigate any risk to the business. The Audit Role simply needs to eliminate red flag events and provide security, operational, and process proof of who can perform what and how.

To meet this requirement specific roles should be defined solely for the IntelliSnap and Application iDataAgents within the CommCell. An example of this basic security structure as defined in Security Roles as noted here:

Storage Policies

Managing proper retention on the snapshot copies becomes another critical requirement. Improper retention either increases the amount of tier 1 storage that is holding recovery points, or it causes the snapshots to fall short of fully meeting SLA requirements for the business. Storage Policies are broken down into copies for managing retention on the proper tier of storage. In the typical Storage Policy for IntelliSnap, three copies will be available, the Primary Snapcopy, the Primary backup to disk copy, and the Offsite disk/tape copy. Properly meeting SLA requirements for the business requires proper alignment for the retention characteristics of each of the storage tiers.

For example, SLAs for Sub 24hr RPO/RTO drastically lower the returns on leveraging snapshot technology on copies beyond 48 hours. The typical Best Practice for Storage Policy configuration will change from environment to environment. The standard retention should align with the recovery requirement for data residing in the Snapcopy or snapshot area of the array. The primary backup to disk and tape copies would then provide SLA coverage for complete Site based disasters. For Example, with the previous description retention may be set in the following way:

• Primary Snapcopy – 2days & 0 Cycles

• Primary Disk Copy – 28days & 1 Cycle

• Offsite Disk/Tape Copy – 60days & 1 Cycle

This definition allows snapshot retention on a 48 hour rotation providing multiple high-speed recovery points available on the array to meet the SLA requirement. This configuration requires storage space allocation to maintain two persistent days of change for the associated clients. By setting “cycles” to 0, the removal of old snapshots occurs regardless of success, so proper alerting and monitoring is required.

The other recommended option for Snapcopy retention sets the “days” variable to 0 and focuses solely on the Number of cycles. In this configuration full backups must occur frequently to allow for proper snap management. With this setup, the # of snapshots retained will be determined on the number of cycles configured. The scheduled frequency becomes very important to defining the environment conditions. If eight snapshots execute over a week timeframe, then 7 days of delta change must be available in the Array configuration. If eight Snapshots execute in a 48 hour period, only 48 hours of delta change must be available in the Array configuration. Fully understanding the schedule and process configurations enable making the proper retention setting when keying off of “cycles.” Improperly setting retention and effects of days and cycles can adversely affect the available recovery scenarios for the business applications.

This definition will then enable the Primary and Secondary backup to disk and tape copies. Backup Copies should follow that standard backup schedule for the production (i.e. – daily backups should equate into at least one Snap Copy Point in time to drive local and offsite backups). Remember, backup copies will execute synchronously, and the failure to “backup” Snap Copies to disk/tape will extend the storage requirement on the Array, as the snapshots will not prune until the selected recovery points execute in a Backup Copy to disk/tape copies. Application data will always be consistent on this data movement. Backup Copy operations will always use File System mechanisms to protect the properly quiesced applications except in the instance of RMAN Proxy’s in an Oracle configuration. The rest of the data aging follows the standard days and cycles rules for purging off data sets.

Snapshots may be deleted from the array due to factors like low disk space on the array and number of snapshots exceeds the threshold. The jobs that correspond to these deleted snapshots can no longer be used for any data recovery or backup copy operations. Use the reconciliation operation in the Array Management GUI button for on-demand reconciliation of snaps.