An illustrative approach accelerates file indexing operations for block-level backup copies in a data storage management system. A cache storage area is maintained for locally storing and serving key data blocks, thus relying less on retrieving data on demand from the backup copy. File indexing operations are used for populating the cache storage area for speedier retrieval during subsequent live browsing of the same backup copy, and vice versa. The key data blocks cached while file indexing and/or live browsing an earlier backup copy help to pre-fetch corresponding data blocks of later backup copies, thus producing a beneficial learning cycle. The approach is especially beneficial for cloud and tape backup media, and is available for a variety of data sources and backup copies, including block-level backup copies of virtual machines (VMs) and block-level backup copies of file systems, including UNIX-based and Windows-based operating systems and corresponding file systems.

A system determines that a primary event processor, included in a primary data center, is associated with a failure. The primary event processor is included in the primary data center and configured to process first events stored in a main event store of the primary data center. The system identifies a secondary event processor, in a secondary data center, that is to process one or more first events based on the failure. The primary event processor and the secondary event processor are configured to process a same type of event. The system causes, based on a configuration associated with the primary or secondary event processor, the one or more first events to be retrieved from one of the main event store or a replica event store. The replica event store is included in the secondary data center and mirrors the main event store of the primary data center.

Described are examples for deploying workloads in a cloud-computing environment. In an aspect, based on a desired number of workloads of a process to be executed in a cloud-computing environment and based on one or more failure probabilities, an actual number of workloads of the process to execute in the cloud-computing environment to provide a level of service can be determined and deployed. In another aspect, a standby workload can be executed as a second instance of the process without at least a portion of the separate configuration used by the multiple workloads, and based on detecting termination of one of multiple workloads, the standby workload can be configured to execute based on the separate configuration of the separate instance of the process corresponding to the one of the multiple workloads.

A determination is made that a relational database management system (RDBMS) is configured as a distributed availability group. The distributed availability group spans first and second availability groups. Each availability group includes a cluster of servers hosting replicas of a database. One of the first or second availability groups functions as a primary availability group. Another of the first or second availability groups functions as a secondary availability group that is available as a failover target should the primary availability group become unavailable. A name of the distributed availability group is obtained. A first server in the first availability group is directed to backup a replica of the database being hosted by the first server. The directing includes instructing the first server to index the backup against the name of the distributed availability group.

A computer-implemented method for testing failover may include: determining one or more cross-regional dependencies and traffic flow of an application in a first region of a cloud environment, wherein the one or more cross-regional dependencies include a dependency of the application in the first region of the cloud environment to one or more applications in at least one other region of the cloud environment; determining a risk score associated with performing failover of the application to a second region of the cloud environment at least based on the determined one or more cross-regional dependencies and traffic flow of the application; comparing the determined risk score with a predetermined risk score; in response to determining that the determined risk score is lower than the predetermined risk score, performing failover of the application to the second region of the cloud environment; isolating the second region of the cloud environment from the first region of the cloud environment for a predetermined period of time; and monitoring operation of the application in the second region of the cloud environment during the predetermined period of time.

A logical grouping of subgroups of server clusters forms a failover super-cluster. A logical grouping of groups of servers provides high availability by, upon failure of an entire group (site), failing over an entire subgroup to a different subgroup. Yet within each subgroup local failovers continue to maintain application high availability during instances in which the site remains operational.

A first server and a second server use a virtual address to mount the storage synchronous area in a storage by the NFS. The first server obtains a snapshot of memory content of a virtual system operated as an active system and transmits the snapshot to the second server. The first server replicates content of the storage synchronous area in the storage to a storage synchronous area in a storage. When a failure occurs in the first server, the second server sets a virtual address to the storage and uses the virtual address to mount the storage synchronous area in the storage by NFS. The second server uses the snapshot received from the first server to execute the application on the virtual system.

Examples provided herein describe a method for reducing recovery time for an application. For example, a first physical processor of a computing device may monitor, based on a first application instance of the application running in a first mode, for failure detection of the first application instance running on a first computing device. The first physical processor may determine that the first application instance is to be changed from the first mode to a second mode. Based on the determination, the first physical processor may validate that a second application instance can run in the first mode by performing a data integrity compliance check. Responsive to validating that the second application instance can run in the first mode, the first physical processor may facilitate running of the second application instance in the first mode.

A data management and storage (DMS) cluster of peer DMS nodes manages data of an application distributed across a set of machines of a compute infrastructure. A DMS node associates a set of machines with the application, and generates data fetch jobs for the set of machines for execution by multiple peer DMS nodes. The DMS node determining whether each of the data fetch jobs for the set of machines is ready for execution by the peer DMS nodes. In response to determining that each of the data fetch jobs is ready for execution, the peer DMS nodes execute the data fetch jobs to generate snapshots of the set of machines. The snapshots may be full or incremental snapshots, and collectively form a snapshot of the application.

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.