Entities often generate and use data that is important in some way to their operations. This data can include, for example, business data, financial data, and personnel data. If this data were lost or compromised, the entity may realize significant adverse financial and other consequences. Accordingly, many entities have chosen to back up some or all of their data so that in the event of a natural disaster, unauthorized access, or other events, the entity can recover any data that was compromised or lost, and then restore that data to one or more locations, machines, and/or environments.
While data backup is a valuable and important function, the ever increasing volume of data that is generated presents significant problems. In particular, many companies today find their backup and recovery process strained as data growth in enterprise IT environment continues to accelerate at exponential rates, while data-protection solutions have struggled to keep pace. Backup performance is crippled by the needs of up-to-date and online business applications. Snapshot and replication operations of application data are key strategies to meet very demanding Service Level Objectives (SLO) such as Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).
In challenging environments such as these, conventional approaches to data backup typically fall short for any of a variety of reasons. For example, many legacy backup solutions are hard coded and thus lack flexibility. This lack of flexibility causes inefficiencies in that it can result in overutilization of some backup resources, and underutilization of other backup resources.
Another concern with conventional backup approaches is that they often require significant user involvement in the selection and configuration of resources for the backup. This user involvement can lead to user errors, miscalculations and misinterpretations. Moreover, user involvement can significantly slow the selection of systems and devices for a backup configuration and, accordingly, the speed with which the backup can be taken. More particularly, most backup applications ask users to create resources, define schedules, define mapping between a selected source and target device, define the actions and workflow, and define topologies. Because these functions must be performed manually by the user, user errors, delayed decisions and inefficient use of resources often result.
Finally, and as will be apparent from the foregoing, the customer experience with conventional backup approaches is not satisfactory. That is, such backup approaches require significant user involvement, and are not particularly easy to use.
In light of problems and shortcomings such as those noted above, it would be useful to be able to take a backup while automatically taking into account ongoing variations in system configurations and asset availability. It would also be useful to be able to take a backup using the best configuration available at the time of the backup. Finally, it would be useful to be able to define one or more acceptable configurations in advance of the backup.