Incremental Backup in Transactional File Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional backup systems fail to effectively perform incremental backup operations in transactional file systems due to the delay in updating file system metadata, leading to missed data changes during multi-stage data modifications, where changes are not reflected until the transaction is committed.

Innovation Solution

A system that includes a change tracking module to detect data changes during open transactions and update changed block metadata, ensuring that modified blocks are identified and backed up only after the transaction is committed, using a combination of changed block metadata and non-protected block metadata to accurately select data for incremental backups.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional backup systems use traditional incremental backup methods, then backup operations are simpler and faster, but data changes during uncommitted transactions are missed leading to data loss

Engineering Contradiction:
Improvedata integrityVSAvoidbackup system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by detecting and tracking data changes during open transactions before the transaction is committed. The change tracking module monitors write operations and updates changed block metadata in advance, ensuring that when the transaction commits, all modifications are already recorded and ready for backup. This preliminary tracking prevents data loss while maintaining systematic complexity through structured metadata management.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces changed block metadata and non-protected block metadata as intermediary structures between the transactional file system and the backup system. These metadata structures act as mediators that capture and hold information about data changes during uncommitted transactions, allowing the backup system to accurately identify which blocks need to be backed up without directly interfering with the transaction processing mechanism. This intermediary layer resolves the conflict between transaction integrity and backup accuracy.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the system tracks all data changes including uncommitted transactions, then data integrity is maintained, but the complexity of tracking and metadata management increases

Engineering Contradiction:
Improvebackup accuracyVSAvoidmetadata management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the metadata management into distinct components: changed block metadata for tracking modified blocks, non-protected block metadata for tracking blocks that need backup protection, and transaction metadata for monitoring open transactions. Each segment serves a specific function in the backup process. This segmentation reduces overall complexity by organizing tracking responsibilities into manageable, specialized data structures rather than a monolithic tracking system.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The change tracking module automatically detects data changes and updates the appropriate metadata structures without requiring manual intervention or complex external coordination. The system self-services by monitoring its own state, identifying modified blocks, and maintaining the metadata that enables accurate incremental backups. This self-service capability reduces the operational complexity of managing backup tracking across multiple transactions.

Inventive Principle:
Principle #25Self-service

3Reliability

If incremental backups are performed frequently, then data loss risk is reduced, but the overhead of tracking changes increases

Engineering Contradiction:
Improvedata protection levelVSAvoidbackup processing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs partial action by conducting incremental backups only on blocks that have been identified as changed through the metadata tracking mechanism. Rather than backing up all data or performing excessive full backups, the change tracking module precisely identifies which blocks require backup by examining changed block metadata and non-protected block metadata. This partial action approach reduces backup processing time while maintaining high data protection levels through frequent, targeted incremental backups.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent replaces the mechanical approach of scanning and analyzing all data blocks during backup with a metadata-driven system. Instead of mechanically examining each block to determine if it has changed, the system substitutes this with a lookup in the changed block metadata and non-protected block metadata structures. This substitution dramatically reduces the time and computational resources required for incremental backups while enabling more frequent backup operations to enhance data protection.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS9690666B1Incremental backup operations in a transactional file system
Publication Date: 2017.06.27 COHESITY INC
  • US9690666B1 patent drawing
  • US9690666B1 patent drawing
  • US9690666B1 patent drawing

AI summary

Various systems and methods for performing incremental backups in transactional file systems. For example, one method involves performing the first stage of a multi-stage write operation, where the write operation writes a data block. The method then involves performing a backup operation. However, the backup operation does not backup the modified block, since not all stages of the multi-stage write operation have been performed. The method involves updating metadata to indicate that though the data block was modified and a backup operation was performed, the data block was not included in the backup operation. After all stages of the multi-stage write operation have completed, e.g., a transaction is committed, a subsequent backup operation is performed. The data block is backed up during the subsequent backup operation.