Incremental Data Backup Using XML Delta Capture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional SQL backup and restore methods in large distributed database systems require full database backups, periodic transaction log backups, resulting in high storage needs and poor recovery time objectives due to time-consuming and labor-intensive restore processes, and lack direct queryability of backup data.
Innovation Solution
The architecture eliminates the need for full backups by capturing and storing only incremental changes in a separate table, using triggers to track changes and store them in an XML format, allowing for efficient incremental recovery and rollback without downtime, with the ability to query and restore data to a previous state.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional full database backup is performed, then data protection is achieved, but storage requirements increase significantly
Solution Approach 1:
The patent extracts only the changed data rows from the full database backup process. Instead of backing up the entire database, triggers capture and store only the incremental changes (inserts, updates, deletes) in a separate backup table, significantly reducing storage requirements while maintaining data protection capability.
Solution Approach 2:
The backup process is segmented into capturing only the modified portions of data. The backup table stores discrete change records with timestamps, allowing selective backup of specific data changes rather than the complete database, thus reducing overall storage needs.
2Reliability
If full backup is restored followed by transaction log application, then data recovery is achieved, but recovery time becomes very long
Solution Approach 1:
The patent performs preliminary action by capturing and storing change data in a structured backup table during normal operations. The backup table pre-organizes change records with timestamps and row identifiers, so during recovery only the necessary changes need to be applied rather than restoring entire backup sets and sequentially processing transaction logs.
Solution Approach 2:
The recovery process extracts and applies only the relevant change records from the backup table based on timestamp ranges, rather than applying all transaction logs from a full backup. This selective application of changes dramatically reduces recovery time while ensuring data integrity.
3Quantity of substance
If binary format backup is used, then storage efficiency is achieved, but queryability of backup data is lost
Solution Approach 1:
The patent changes the format parameter of backup data from binary to a text-based format (such as XML or JSON). This allows the backup data to remain compact while being directly queryable and human-readable, eliminating the trade-off between storage efficiency and queryability that exists with traditional binary backup formats.
4Reliability
If periodic transaction log backup is performed, then lower recovery point objective is achieved, but storage requirements and complexity increase
Solution Approach 1:
The patent implements continuous capture of data changes through triggers that fire on every insert, update, or delete operation. This continuous capture mechanism eliminates the need for periodic transaction log backups, achieving low recovery point objectives while simplifying the backup system architecture by removing the complexity of managing periodic backup schedules and multiple backup types.
Data Source
AI summary
Architecture that eliminates the need for on-disk full backups of data retaining only changes that have occurred, in a separate table. Thus, the architecture provides for incremental recovery of incremental changes in a relational database (e.g., SQL). The architecture provides improved recovery time and recovery point objectives. By using the incremental capture of changed data (e.g., in an XML format), the capability is provided to capture schema changes, query the incremental change data and efficiently restore user data to an earlier point-in-time state. Changes (e.g., insert, update and delete operations) are tracked (e.g., continuously) by a set of triggers and the incrementally captured changed rows are inserted in a data capture table (a differential change “delta” table) in a human-readable format (e.g., XML). Rollback is also provided.