Abstract: Snapshot-based disaster recovery (DR) orchestration systems and methods for virtual machine (VM) failover and failback do not require that VMs or their corresponding datastores be actively operating at the DR site before a DR orchestration job is initiated, i.e., before failover. An illustrative data storage management system deploys proprietary components at source data center(s) and at DR site(s). The proprietary components (e.g., storage manager, data agents, media agents, backup nodes, etc.) interoperate with each other and with the source and DR components to ensure that VMs will successfully failover and/or failback. DR orchestration jobs are suitable for testing VM failover scenarios (“clone testing”), for conducting planned VM failovers, and for unplanned VM failovers. DR orchestration jobs also handle failback and integration of DR-generated data into the failback site, including restoring VMs that never failed over to fully re-populate the source/failback site.

Abstract: Snapshot-based disaster recovery (DR) orchestration systems and methods for virtual machine (VM) failover and failback do not require that VMs or their corresponding datastores be actively operating at the DR site before a DR orchestration job is initiated, i.e., before failover. An illustrative data storage management system deploys proprietary components at source data center(s) and at DR site(s). The proprietary components (e.g., storage manager, data agents, media agents, backup nodes, etc.) interoperate with each other and with the source and DR components to ensure that VMs will successfully failover and/or failback. DR orchestration jobs are suitable for testing VM failover scenarios (“clone testing”), for conducting planned VM failovers, and for unplanned VM failovers. DR orchestration jobs also handle failback and integration of DR-generated data into the failback site, including restoring VMs that never failed over to fully re-populate the source/failback site.

Abstract: Systems described herein may dynamically add one or more proxy agents to a cloud data storage system to process an information management job, such as restore job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy agents and/or the virtual machines on which the proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). The system takes into account currently existing proxies or virtual machines when processing a restore request to determine the need for new proxies to service the restore request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: An illustrative storage management appliance is interposed between client computing devices and one or more cloud storage resources. The appliance uses cloud storage resources in conjunction with a network attached storage device configured within the appliance to provide to the client computing devices seemingly unlimited network attached storage on respective network shares. The storage management appliance monitors data objects on the network shares and when a data object meets one or more criteria for archiving, the storage management appliance archives the data object to a cloud storage resource and replaces it with a stub and preview image on the network share. When access to the stub and/or preview image is detected, the storage management appliance restores the data object from the cloud storage resource. The criteria for archiving flexibly allow individual data objects to be archived to cloud storage without archiving frequently-accessed “neighboring” data objects on the same network share.

Abstract: A data storage management system comprises features for initiating failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment. Backed up data that is stored persistently in the cloud computing environment may be rapidly restored within the cloud computing environment for use in disaster recovery and/or in test and verification scenarios. This approach may be contrasted to systems where a failover system is “always on” at the failover destination, such as having failover resources always up and running in the cloud computing environment. Such resources typically include a failover virtual machine (VM), a virtual machine datastore for the restored data, and one or more computing resources for restoring an auxiliary copy to the VM's datastore. The cloud-based failover resources are deactivated or taken down once the failover event ends.

Abstract: An illustrative storage management appliance is interposed between client computing devices and one or more cloud storage resources. The appliance uses cloud storage resources in conjunction with a network attached storage device configured within the appliance to provide to the client computing devices seemingly unlimited network attached storage on respective network shares. The storage management appliance monitors data objects on the network shares and when a data object meets one or more criteria for archiving, the storage management appliance archives the data object to a cloud storage resource and replaces it with a stub and preview image on the network share. When access to the stub and/or preview image is detected, the storage management appliance restores the data object from the cloud storage resource. The criteria for archiving flexibly allow individual data objects to be archived to cloud storage without archiving frequently-accessed “neighboring” data objects on the same network share.

Abstract: A data storage management system comprises features for initiating failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment. Backed up data that is stored persistently in the cloud computing environment may be rapidly restored within the cloud computing environment for use in disaster recovery and/or in test and verification scenarios. This approach may be contrasted to systems where a failover system is “always on” at the failover destination, such as having failover resources always up and running in the cloud computing environment. Such resources typically include a failover virtual machine (VM), a virtual machine datastore for the restored data, and one or more computing resources for restoring an auxiliary copy to the VM's datastore. The cloud-based failover resources are deactivated or taken down once the failover event ends.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: Snapshot-based disaster recovery (DR) orchestration systems and methods for virtual machine (VM) failover and failback do not require that VMs or their corresponding datastores be actively operating at the DR site before a DR orchestration job is initiated, i.e., before failover. An illustrative data storage management system deploys proprietary components at source data center(s) and at DR site(s). The proprietary components (e.g., storage manager, data agents, media agents, backup nodes, etc.) interoperate with each other and with the source and DR components to ensure that VMs will successfully failover and/or failback. DR orchestration jobs are suitable for testing VM failover scenarios (“clone testing”), for conducting planned VM failovers, and for unplanned VM failovers. DR orchestration jobs also handle failback and integration of DR-generated data into the failback site, including restoring VMs that never failed over to fully re-populate the source/failback site.

Abstract: Snapshot-based disaster recovery (DR) orchestration systems and methods for virtual machine (VM) failover and failback do not require that VMs or their corresponding datastores be actively operating at the DR site before a DR orchestration job is initiated, i.e., before failover. An illustrative data storage management system deploys proprietary components at source data center(s) and at DR site(s). The proprietary components (e.g., storage manager, data agents, media agents, backup nodes, etc.) interoperate with each other and with the source and DR components to ensure that VMs will successfully failover and/or failback. DR orchestration jobs are suitable for testing VM failover scenarios (“clone testing”), for conducting planned VM failovers, and for unplanned VM failovers. DR orchestration jobs also handle failback and integration of DR-generated data into the failback site, including restoring VMs that never failed over to fully re-populate the source/failback site.

Abstract: A data storage management system comprises features for initiating failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment. Backed up data that is stored persistently in the cloud computing environment may be rapidly restored within the cloud computing environment for use in disaster recovery and/or in test and verification scenarios. This approach may be contrasted to systems where a failover system is “always on” at the failover destination, such as having failover resources always up and running in the cloud computing environment. Such resources typically include a failover virtual machine (VM), a virtual machine datastore for the restored data, and one or more computing resources for restoring an auxiliary copy to the VM’s datastore. The cloud-based failover resources are deactivated or taken down once the failover event ends.

Abstract: An illustrative storage management appliance is interposed between client computing devices and one or more cloud storage resources. The appliance uses cloud storage resources in conjunction with a network attached storage device configured within the appliance to provide to the client computing devices seemingly unlimited network attached storage on respective network shares. The storage management appliance monitors data objects on the network shares and when a data object meets one or more criteria for archiving, the storage management appliance archives the data object to a cloud storage resource and replaces it with a stub and preview image on the network share. When access to the stub and/or preview image is detected, the storage management appliance restores the data object from the cloud storage resource. The criteria for archiving flexibly allow individual data objects to be archived to cloud storage without archiving frequently-accessed “neighboring” data objects on the same network share.

Abstract: An illustrative report server interoperates with one or more enhanced storage managers to evaluate whether backup operations and restore operations meet their recovery point objectives (RPO) and recovery time objectives (RTO), respectively. RTO is evaluated using a tiered approach based on past performance of restore and/or backup operations. The illustrative storage manager executes pre-defined queries that extract relevant information from an associated database that houses information about storage operations. The report server recommends alternative kinds of backup operations for data that fails to meet its RTO using traditional backups. The report server is configured to analyze and report RPO and RTO readiness for several levels of data entities, including multiple systems, single system, groups of clients, single clients, and subclients.

Abstract: The systems and methods provide for migrating database management system (DBMS) applications to cloud storage by automating a continuous replication of changes made to the DBMS from the DBMS to an associated cloud instance. For example, the systems and methods facilitate the migration of the DBMS via multiple processes performing in parallel—a process to create and provision a new machine instance (e.g., an EC2 instance), a process to clone and transfer parameters of the operating system/software of the DBMS, and a process that backs up and/or captures the application data of the DBMS. In some embodiments, the systems and methods, utilizing parallel processes, and combining outputs of the processes to a synchronization process, efficiently and quickly migrate DBMS applications to cloud storage, among other benefits.

Abstract: An illustrative storage management appliance is interposed between client computing devices and one or more cloud storage resources. The appliance uses cloud storage resources in conjunction with a network attached storage device configured within the appliance to provide to the client computing devices seemingly unlimited network attached storage on respective network shares. The storage management appliance monitors data objects on the network shares and when a data object meets one or more criteria for archiving, the storage management appliance archives the data object to a cloud storage resource and replaces it with a stub and preview image on the network share. When access to the stub and/or preview image is detected, the storage management appliance restores the data object from the cloud storage resource. The criteria for archiving flexibly allow individual data objects to be archived to cloud storage without archiving frequently-accessed “neighboring” data objects on the same network share.

Abstract: An illustrative “VM heartbeat monitoring network” of heartbeat monitor nodes monitors target VMs in a data storage management system. Accordingly, target VMs are distributed and re-distributed among illustrative worker monitor nodes according to preferences in an illustrative VM distribution logic. Worker heartbeat monitor nodes use an illustrative ping monitoring logic to transmit special-purpose heartbeat packets to respective target VMs and to track ping responses. If a target VM is ultimately confirmed failed by its worker monitor node, an illustrative master monitor node triggers an enhanced storage manager to initiate failover for the failed VM. The enhanced storage manager communicates with the heartbeat monitor nodes and also manages VM failovers and other storage management operations in the system. Special features for cloud-to-cloud failover scenarios enable a VM in a first region of a public cloud to fail over to a second region.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.