Block-Level Incremental Storage Volume Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional block-level incremental recovery methods for storage volumes are time-consuming and inefficient, particularly when restoring a source volume to a specific incremental backup, as they often require copying data from all previous backups, including unchanged blocks, which can lead to unnecessary data overwriting and prolonged restoration times.
Innovation Solution
The proposed solution involves using a volume snapshot facility to track changed blocks and create incremental backups that only include modified data, allowing for selective restoration by leveraging valid data and change block tracking data to avoid writing over unchanged blocks, thereby reducing the time required for restoration.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional block-level incremental recovery copies all blocks from all previous backups in chronological order, then complete restoration is achieved, but restoration time is excessively long
Solution Approach 1:
The patent extracts only the changed blocks from incremental backups using change block tracking data, rather than copying all blocks. The system identifies and copies only those blocks that have changed since the selected incremental backup point, eliminating unnecessary data transfer and significantly reducing restoration time while maintaining complete restoration reliability.
Solution Approach 2:
The patent performs preliminary tracking of changed blocks during the backup process using change block tracking data. This preliminary action records which blocks have changed, so that during restoration, only the necessary blocks need to be copied. The change block tracking is established in advance, enabling efficient selective restoration without chronological sequential copying.
2Reliability
If all blocks are copied from previous backups, then data completeness is ensured, but data overwriting of unchanged blocks occurs unnecessarily
Solution Approach 1:
The system extracts and identifies changed blocks using change block tracking data, separating them from unchanged blocks. Only the changed blocks are copied from the incremental backup to the source volume, while unchanged blocks are left intact. This prevents unnecessary data overwriting and reduces the amount of data processed during restoration.
Solution Approach 2:
Instead of performing a complete copy of all blocks (excessive action), the patent performs a partial copy of only the changed blocks that are necessary for restoration. This partial action is sufficient to achieve data completeness while avoiding the waste of copying unchanged blocks.
3Productivity
If block-level incremental backup is used, then backup efficiency is improved, but recovery complexity increases due to multiple backup versions
Solution Approach 1:
The patent introduces change block tracking data as an intermediary that simplifies the recovery process. This intermediary data structure records which blocks have changed, serving as a guide during restoration. Instead of complex logic to determine which blocks need copying from multiple backup versions, the system simply follows the change block tracking data, significantly reducing recovery complexity while maintaining block-level incremental backup efficiency.
Data Source
AI summary
A source volume is restored to the time of a selected incremental backup volume without writing over all of the data blocks in the source volume. If the source volume has valid data blocks and there are valid records of the changes to these valid data blocks and the valid records are consistent with the state of the source volume and indicate that certain valid data blocks did not change since the selected incremental backup, then the restoration does not write over the valid data blocks that did not change since the selected incremental backup. Otherwise, data blocks are recovered from the selected incremental backup and one or more backups prior to the selected incremental backup. For example, data blocks are recovered by scanning incremental backups in reverse chronological order to find the most recent version of the block in these backups.