SnapProtect - SnapProtect for Open Systems C-Mode - Optimized Block Level Replication
Traditional block level replication calculates all used blocks that have changed for a volume since the last backup, using the SHA-1 checksum mechanism and a checksum database to transfer only the changed blocks to the destination file server. For a given volume, all backups, except the first, are incremental. This means that the calculation of the blocks that have changed involves reading the complete volume for every backup, which can be time and resource consuming.
In order to optimize the calculation of which blocks have changed, the optimized block level replication feature engages a block level filter driver that monitors the volume and tracks any changes to the blocks. Written blocks are tracked as changed blocks.
The application agent queries the driver during every job to get the list of blocks that changed since the last backup. During the backup job, it transfers just the changed blocks. The optimized block level replication speeds up the replication job considerably and consume less resources, since there is no need to scan the entire volume for every backup.
For more information on the installation and configuration of the Optimized Block Level Replication feature, refer to Optimized Block Level Replication.
Cases Where Replication Uses the Checksum Method
There are some cases where the replication job for a subclient cannot be optimized, even if the Optimized Block Level Replication feature is enabled. In the following cases, the checksum incremental job is the method applied. Subsequent jobs after such jobs are optimized.
- The first job after the Optimized For block level replication (SnapProtect for Open Systems C-Mode) check box is selected at client level
- The first job run after a subclient is associated from one storage policy to another
- The first job run after rebooting a client computer on UNIX platform
- The first job after the driver updates are installed on the client computer
- On Windows, the first job after a volume’s GUID changes
- On Microsoft Windows Cluster, the first job after a cluster failover that causes a shared volume’s GUID to change
- The first job after a volume is resized (extended or shrunk)
- Every full job for the File System agent