i2CDM captures production data block-by-block, with initial full-system protection saved as a virtual disk image on the backup server. Incremental data updates the QCOW2 image file via CBT, and snapshots are generated per user-defined policies. For recovery, a new virtual disk format copy is created using snapshot chaining and cloning technology for virtual machine creation on virtualization platforms.
Block replication involves deploying a program on the production system that intercepts IO write requests between the file system and disk driver layers, capturing block device ID, write start sector, length, and data.
A bitmap data structure tracks disk segment changes, with each bit representing a 64K disk space. For a 1TB disk, 2M bitmap space is managed in kernel memory. When a policy is created, the kernel allocates bitmap space based on the device's capacity, updating it whenever disk blocks change.
The listening module calculates and sets bits in the bitmap for protected block devices based on sector and length combinations. CBT captures block-level changes and updates them to the backup server as incremental backups.
When the production environment fails, the virtual machine can be launched directly on the virtual platform for emergency takeover through the takeover function. The virtual machine can have customized CPU, memory, hard disk, network, and other configurations before takeover.
After generating data copies with the whole-machine CDM function, a virtual machine can be created for this data copy through the drill function, allowing availability verification of the data copy. This function can also quickly set up environments for development, testing, data analysis, etc. The virtual machine can have customized CPU, memory, hard disk, network, and other configurations before the drill.
After each data copy is created, an automatic drill function can automatically create, validate, and recycle virtual machines for the generated data copies on the target virtual platform. The drill strategy and various validation methods, such as ping, TCP, and custom script validation, can generate drill reports for user inquiry. It can monitor whether the backup rules and production servers are running normally at any time.
Whole-machine copy data can be remotely replicated to a remote appliance based on rules and can be taken over or restored from the remote appliance, achieving remote disaster recovery for the appliance.
Whole-machine copy data can be migrated to a remote appliance based on rules, addressing scenarios where backup data needs to be moved due to insufficient disk space on the local appliance and satisfying the horizontal scaling scenario for CDM appliances.
Whole-machine CDM data can be restored to the target host using the LiveCD or WinPE boot system.
If the recovery scenario does not require emergency takeover of the business system, and the user wishes to quickly recover data files from a certain point in time on any host system, it can be achieved through the mount recovery function.
The implementation principle of the mount recovery function is that the source-side disk is saved to the disaster recovery appliance through block replication technology, and the target data is saved in the QCOW2 virtual disk format. The QCOW2 image of a certain state can be mapped to a Network Block Device (NBD). Since the disaster recovery appliance integrates the iSCSI target program (iSCSI Target), this network block device can be further mapped to the backend block device of the iSCSI Target.
The recovery host configures the iSCSI initiator program (iSCSI Initiator), connects to the iSCSI target over the network, discovers the disk, and mounts the discovered disk in the recovery host system, enabling volume-level or file-level quick recovery.