Certain embodiments described herein relate to an improved block-level replication system. One or more components in an information management system may receive a request to perform a block-level replication between a source storage device and a destination storage device, and depending on the specific replication mode requested, (i) store block-level changes directly to the destination storage device or (ii) first to a recovery point store and then later to the destination storage device.

A data backup method of a storage device which includes a storage controller, a buffer memory, and a plurality of nonvolatile memory devices, the method including: detecting a power-off event of an external power provided to the storage device; deactivating a host interface of the storage controller in response to the detection of the power-off event: moving data stored in the buffer memory to a static random access memory (SRAM) in the storage controller; blocking or deactivating a power of the buffer memory; setting an interleaving mode of the plurality of nonvolatile memory devices to a minimum power mode; and programming the data moved to the SRAM to at least one of the plurality of nonvolatile memory devices.

A storage manager for an information management system determines whether one or more predetermined conditions have been met for transferring metadata of previously performed backup jobs stored in a first management database. A backup job may correspond to a backup operation of a primary storage device of a first client computing device. In response to a determination that one or more of the predetermined conditions have been met, the storage manager may transfer metadata for a second plurality of backup jobs to a second management database of a recovery manager. The recovery manager may receive a request to restore data to the primary storage device of the first client computing device based on the metadata of the second plurality of backup jobs. A media agent managed by the recovery manager may then restore the requested data to the primary storage device of the first client computing device.

In an embodiment, two or more storage systems are requested to prepare respective local checkpoints for a dataset, wherein each of the two or more storage systems stores portion of the dataset. The two or more storage systems are determined to have established the checkpoint. In response to determining that the local checkpoints have been established, a coordinated checkpoint is completed.

An identification of a primary snapshot created for a primary storage system is received. A first request for a first metadata of a first file directory structure object associated with the primary snapshot is issued. A second request for data content of the first file directory structure object associated with the primary snapshot is determined to be sent to a recipient device based on a received response to the first request. A third request for a second metadata of a second file directory structure object associated with the primary snapshot is determined to be sent to the recipient device. Timing and ordering of issuance of a plurality of requests that at least includes the second request and the third request to the recipient device are managed based on a determined performance metric of the recipient device and corresponding relative impact to the performance metric of the recipient device.

In some embodiments, a method implements a Byzantine fault tolerant protocol. A first replica detects a condition to cause a view change procedure to move from a current view to a next view. The first replica sends a message indicating the first replica wants to leave the current view. Also, the first replica receives a set of messages from second replicas indicating a respective second replica wants to leave the current view. The first replica determines when a property is received to the leave the current view based on the set of messages from the set of second replicas. When it is determined the property is received, the first replica performs a process to leave the current view. When it is determined the property is not received, the first replica stays in the current view and participating in processing a request from a client in the current view.

Methods and systems of scanning for resources for resource classification in a multi cloud environment are disclosed. For a combination of a cloud account, a cloud region, and a resource type, a percentage of protected existent resources hosted on the cloud computing platform is determined. A cycle skip count is set based on the determined percentage of the protected existent resources hosted on the cloud computing platform. The percentage of the protected existent resources and the cycle skip count associated with the combination are stored in a catalog. For the combination of the cloud account, the cloud region, and the resource type, the protected existent resources hosted on the cloud computing platform are periodically scanned for based on the cycle skip count.

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for selectively creating high frequency data backups. One of the methods includes maintaining configuration data that indicates a backup frequency at which backups are scheduled to be made for a database, and third party data that identifies one or more predicted events in a geographic area in which the database is physically located; determining, using the third party data, whether a predicted likelihood that the database will experience data loss during a future time period satisfies a threshold likelihood; in response to determining whether the predicted likelihood satisfies the threshold likelihood, selectively changing the backup frequency in the configuration data to be a second, different value that is different than a first value or determining to skip updating the backup frequency; and initiating, using the backup frequency, a backup of at least a second portion of the database.

A reference snapshot of a storage is stored. Data changes that modify the storage are received. The data changes are captured by a write filter of the storage. The received data changes are logged. The data changes occurring after an instance time of the reference snapshot are applied to the reference snapshot to generate a first incremental snapshot corresponding to a first intermediate reference restoration point. The data changes occurring after an instance time of the first incremental snapshot are applied to the first incremental snapshot to generate a second incremental snapshot corresponding to a second intermediate reference restoration point.

A “backup services container” comprises “backup toolkits,” which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is “over-equipped” with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node. All configurations and embodiments are suitable for cloud and/or non-cloud computing environments.