Punch Command Replication for Storage Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional data protection systems face challenges in minimizing downtime during data recovery and keeping pace with high data transaction rates, as they often require system shutdowns and can lead to a backlog of un-logged transactions due to the overhead of journaling, which is not adaptable to dynamic transaction rates.
Innovation Solution
Implementing a punch command in a replication environment to free storage by applying it to the replication site and writing data to an undo stream of a journal, allowing for efficient storage resource management and adaptation to changing transaction rates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If journaling is used to enable continuous data protection and rollback to previous points in time, then data recovery capability is improved, but the backup site cannot keep pace with high data transaction rates at the production site, causing a backlog of un-logged transactions
Solution Approach 1:
The patent extracts the journaling overhead from the critical data transaction path. By implementing asynchronous journaling where journal entries are created and logged without blocking production site transactions, the system separates the reliability function (journaling) from the productivity path (data transactions), allowing high-speed transactions to proceed while journaling occurs in the background
Solution Approach 2:
The patent introduces an intermediary journaling layer that mediates between the production site and backup site. The journal acts as a buffer that captures transaction metadata and changes asynchronously, allowing the backup site to process journal entries at its own pace without constraining the production site's transaction rate, thus resolving the contradiction between recovery capability and transaction speed
2Reliability
If the backup site processes all data transactions synchronously to maintain data consistency, then data accuracy is improved, but the production site is forced to slow down due to the overhead of journaling
Solution Approach 1:
The patent implements dynamic journaling where the system adapts its operation mode based on conditions. The journaling process can operate asynchronously during normal high-speed transactions, but switches to synchronous confirmation when needed to maintain consistency, allowing the system to be both fast and reliable under different operational states
Solution Approach 2:
The patent performs preliminary journaling actions at the production site without waiting for backup site confirmation. By pre-logging transactions locally and then asynchronously replicating them to the backup site, the system maintains data consistency while avoiding the speed penalty of synchronous processing, as the preliminary action is already completed before replication
3Quantity of substance
If tape backup drives are used for periodic data storage, then storage cost is reduced, but the system requires shutdown during backup and limits recovery points to only those scheduled backup times
Solution Approach 1:
The patent implements continuous data protection through asynchronous journaling that operates continuously in the background without requiring system shutdowns. The journaling process continuously captures and replicates data changes, enabling recovery to any point in time within the journal retention period, eliminating the downtime and recovery point limitations of periodic tape backups while using cost-effective storage
Data Source
AI summary
The punch command may be replicated in a replication environment including a production site and a replication site. The solution includes implementing a punch command to free storage received at a replication site in a replication environment by applying the punch command to storage at the replication site and writing data being freed from the storage at the replication site to an undo stream of a journal at the replication site. If the punch command is not supported, a command to write zeros may be used. Further, an unpunch command is provided for properly undoing a punch command and storing data written to the volume before the punch command freed the storage. Additionally, large punch commands may be split into a plurality to smaller punch commands for efficient journal management. Additionally, volume space may be reclaimed by writing a punch command to the journal instead of zeros.