Snapshot-Based Block Change Tracking for Backup Efficiency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional backup methods are time-consuming and resource-intensive, especially for large data storage systems, as they require full backups at infrequent intervals and incremental backups, which can be burdensome and result in data loss if not performed frequently enough.
Innovation Solution
The method involves generating snapshots of storage volumes to track changed blocks, allowing for incremental backups by identifying and copying only the changed blocks, thereby reducing the time and resources required for backup procedures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If full backup procedures are performed at infrequent intervals, then storage space is utilized efficiently, but the time required to perform backups becomes increasingly burdensome and data loss increases
Solution Approach 1:
The backup process is segmented into full backups performed at infrequent intervals and incremental backups performed frequently in between. The system divides the backup operation into identifying changed blocks only and copying those specific blocks, rather than backing up the entire storage volume each time. This segmentation allows efficient storage utilization while reducing backup time through targeted incremental operations.
2Reliability
If incremental backups are performed frequently, then data loss is reduced, but the time and resources required for backup procedures increase
Solution Approach 1:
The system extracts only the changed blocks from the storage volume for backup operations. By using change tracking mechanisms to identify which blocks have been modified since the last backup, the system extracts and copies only those specific blocks rather than the entire volume. This extraction approach reduces backup procedure time while maintaining reliability by ensuring all changed data is captured in frequent incremental backups.
Solution Approach 2:
The system performs partial backup actions by copying only the necessary changed blocks rather than the complete storage volume. This partial action is sufficient to maintain data reliability for recovery purposes while significantly reducing the time and resources required for each backup operation. The change tracking mechanism ensures that the partial backup captures all necessary data for reliable recovery.
3Measurement precision
If hash-based replication cycles are used to track changed blocks, then backup accuracy is maintained, but CPU and I/O resources are excessively consumed
Solution Approach 1:
The system introduces change tracking mechanisms as intermediary components that monitor and identify changed blocks without requiring full hash-based analysis of all blocks. These intermediaries (such as change tracking data structures or metadata mechanisms) enable the system to detect block changes with high accuracy while consuming minimal CPU and I/O resources, avoiding the expensive operation of calculating hashes for every block in the storage volume.
4Productivity
If filter drivers are installed on the protected system to track modified blocks, then incremental backup efficiency is improved, but system complexity and potential points of failure increase
Solution Approach 1:
The system enables self-service for change tracking by utilizing existing storage volume metadata, change tracking data structures, or built-in mechanisms that automatically identify modified blocks without requiring external filter drivers. The storage system or backup software itself performs the tracking function, eliminating the need for additional driver-layer components. This approach maintains incremental backup efficiency while reducing system complexity and potential failure points.
Data Source
AI summary
Writes to blocks of a protected storage volume that occur between the beginning of a prior backup interval and the beginning of a current backup interval are tracked using a first snapshot that is maintained through the current backup interval. At the beginning of the current backup interval, a second snapshot is generated. Blocks that are indicated by a dirty block list of the first snapshot as having been changed are read from the snapshot volume for the second snapshot and copied to a backup storage volume. For the next backup interval, the second snapshot or alternatively, a newly generated third snapshot, is used to track writes to blocks of a protected storage volume that occur between the beginning of the current backup interval and the beginning of a next backup interval.