Virtual Disk Change Tracking via Epoch Counters
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional backup methods are inefficient and complex, particularly during boot processes, and fail to handle changes accurately across multiple backup applications, leading to issues like incomplete backups and high storage costs due to the use of archive bits, redo logs, and timestamps.
Innovation Solution
The implementation of a virtualization-based method that tracks changes in a virtualization software layer, using an epoch counter and change log to identify modified blocks since the last backup, allowing multiple backup applications to efficiently and accurately backup storage devices by incrementing a counter and storing change information, thereby reducing I/O overhead and minimizing storage costs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional backup drivers are implemented for each operating system, then change tracking can be performed, but the device complexity and implementation difficulty increase significantly
Solution Approach 1:
The patent introduces a virtualization software layer as an intermediary between the virtual machine and the backup application. This layer intercepts and tracks all write operations to virtual disks, providing a universal change tracking mechanism that works across different operating systems without requiring OS-specific drivers. The virtualization layer acts as a mediator that standardizes the backup interface while maintaining compatibility with various guest OSes.
Solution Approach 2:
The patent separates the backup functionality into distinct layers: the virtualization software layer handles change tracking by intercepting write operations, while the backup application layer handles the actual backup process. This segmentation allows each layer to specialize in its function, reducing overall system complexity while maintaining reliable change tracking.
2Ease of operation
If archive bits are used to track file changes, then backup identification is simplified, but storage space is wasted when entire files are backed up despite only partial changes
Solution Approach 1:
The patent divides files into smaller units called blocks and tracks changes at the block level rather than the file level. Each block has an associated change counter that is incremented when the block is modified. This segmentation enables the backup system to identify and backup only the specific blocks that have changed, rather than entire files, thereby reducing storage space waste while maintaining simple change tracking.
Solution Approach 2:
The patent applies different tracking mechanisms to different parts of the storage system. Instead of using a uniform file-level archive bit approach, the system uses block-level change counters that provide granular tracking information. This local quality approach allows precise identification of changed blocks within files, enabling efficient incremental backups that minimize storage waste.
3Reliability
If redo logs are used to capture all disk changes, then complete change tracking is achieved, but additional disk space and operational overhead increase significantly
Solution Approach 1:
The patent extracts the change tracking function from the traditional redo log mechanism and implements it directly in the virtualization software layer. Instead of maintaining separate redo logs that duplicate disk data, the system uses change counters stored in the virtualization layer to track which blocks have been modified. This extraction eliminates the need for additional redo log storage while maintaining complete change tracking.
Solution Approach 2:
The patent uses a simplified copying mechanism where change counter information is copied from the virtualization layer to the backup application, rather than copying actual data blocks. The backup application queries the change counters to identify which blocks need backup, then retrieves only those blocks. This approach minimizes storage requirements while ensuring complete change tracking.
4Loss of time
If timestamps are used for change tracking, then backup timing information is available, but storage and processing overhead increase
Solution Approach 1:
The patent changes the tracking parameter from timestamps (continuous time values) to change counters (discrete integer values). Each block has an associated counter that is incremented when the block is modified. The backup application queries these counters to determine which blocks have changed since the last backup. This parameter change reduces storage requirements (integers vs. timestamps) and simplifies processing (counter comparison vs. timestamp comparison) while maintaining accurate change detection.
5Measurement precision
If checksums are computed for incremental backups, then accurate change detection is achieved, but computational cost and processing time increase
Solution Approach 1:
The patent performs preliminary action by maintaining change counters that are incremented at the time of each write operation. This pre-computed counter information is stored in the virtualization layer and can be queried by the backup application without requiring any computation during the backup process. The counters provide accurate change detection information in advance, eliminating the need for expensive checksum computations during backup operations.
Data Source
AI summary
Systems and methods for tracking changes and performing backups to a storage device are provided. For virtual disks of a virtual machine, changes are tracked from outside the virtual machine in the kernel of a virtualization layer. The changes can be tracked in a lightweight fashion with a bitmap, with a finer granularity stored and tracked at intermittent intervals in persistent storage. Multiple backup applications can be allowed to accurately and efficiently backup a storage device. Each backup application can determine which block of the storage device has been updated since the last backup of a respective application. This change log is efficiently stored as a counter value for each block, where the counter is incremented when a backup is performed. The change log can be maintained with little impact on I/O by using a coarse bitmap to update the finer grained change log.