Change Block Tracking in Cloud Backup Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud orchestration systems face inefficiencies in backing up data due to file system-level snapshots being larger than necessary, requiring additional resources for processing and storage, while they are unable to utilize block-level changes provided by some data volumes.
Innovation Solution
Transforming block-level changes into a format that file system-level backup tools can interpret, allowing for the storage and restoration of snapshots in cloud orchestration systems, thereby enabling the use of more compact block-level changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If file system-level snapshots are used for backup, then compatibility with existing backup tools is maintained, but snapshot size increases and resource consumption increases
Solution Approach 1:
The patent segments the backup process into two distinct components: a change block tracker that captures only modified data blocks, and a file system-level backup tool that processes these changes. This segmentation allows the system to maintain file system-level compatibility while actually backing up only the changed blocks, thereby reducing snapshot size without sacrificing tool compatibility.
Solution Approach 2:
The patent introduces an intermediary component (the change block tracker) that sits between the data volume and the file system-level backup tool. This intermediary translates block-level changes into a format that file system-level tools can process, enabling the use of compact block-level tracking while maintaining compatibility with existing file system backup infrastructure.
2Adaptability or versatility
If file system-level snapshots are used for backup, then existing backup tools can be used, but additional resources are required for processing and storage
Solution Approach 1:
By segmenting the backup architecture into a block tracking component and a file system backup component, the system can leverage the efficiency of block-level tracking (reducing data volume) while maintaining compatibility with file system backup tools. This reduces the amount of data that needs to be processed and stored, thereby reducing resource consumption.
Solution Approach 2:
The intermediary change block tracker enables file system-level backup tools to operate efficiently by providing them with pre-processed block-level change information. This intermediary layer allows the existing backup tools to function without modification while benefiting from the reduced data volume provided by block-level tracking, thus reducing overall resource consumption.
3Quantity of substance
If block-level changes are tracked, then snapshot size is reduced and resource consumption decreases, but file system-level backup systems cannot process the changes
Solution Approach 1:
The patent introduces a change block tracker as an intermediary that captures block-level changes and translates them into a format that file system-level backup tools can understand and process. This intermediary enables the system to use compact block-level tracking while maintaining compatibility with existing file system backup infrastructure, thus resolving the incompatibility issue.
Solution Approach 2:
The patent changes the parameter representation of block-level changes by translating raw block change data into a format that file system-level tools can process. This parameter transformation allows the system to maintain the efficiency benefits of block-level tracking while ensuring compatibility with existing file system backup tools that expect file-system-level change formats.
Data Source
AI summary
Disclosed herein are system, method, and computer program products for storing a snapshot of block-level changes in a data volume using a file system-level backup tool. An embodiment operates by receiving the block level changes in the snapshot from the data volume stored in an application in a cluster. The embodiment creates a root directory for the snapshot. The root directory may have one or more subdirectories. The embodiment maps one or more block changes in the data volume onto the one or more subdirectories and creates a manifest for identifying the snapshot in the file system-level backup tool. The manifest may be associated with the root directory. The embodiment then instructs the file system-level backup tool to store the snapshot by storing the root directory in content-addressable object storage based on the one or more subdirectories and storing the manifest in a manifest storage.