Zero-Trust Remote Replication Using Snapshot Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing data replication systems struggle to detect malicious encryption or corruption in asynchronously replicated data due to low latency requirements, which complicates the identification of compromised storage arrays and spreads damage during ransomware attacks.
Innovation Solution
Implementing delta sets for asynchronous replication, generating crash-consistent snapshots before applying changes, and validating these snapshots using host application instances to detect data corruption and malicious encryption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If asynchronous replication is implemented to maintain data availability, then data loss prevention is improved, but detection of malicious encryption or corruption is delayed
Solution Approach 1:
The system generates a snapshot of the replicated data before applying changes from the primary storage array. This preliminary snapshot is then validated independently before the replication is completed, allowing detection of malicious encryption or corruption before the damaged data is fully propagated to the secondary array.
Solution Approach 2:
The replication process is segmented into distinct phases: snapshot generation, validation, and data application. By separating the validation step from the replication execution, the system can verify data integrity without blocking the overall replication latency, thus maintaining data availability while enabling timely detection of compromised data.
2Reliability
If validation is performed on replicated data, then detection of data corruption is improved, but replication latency increases
Solution Approach 1:
Validation is performed on a snapshot of the replicated data before the actual replication is completed. This preliminary validation checks for corruption or malicious encryption in advance, allowing the system to reject bad data without delaying the overall replication process for valid data.
Solution Approach 2:
A snapshot serves as an intermediary between the primary and secondary storage arrays during replication. The snapshot can be validated independently without blocking the main replication data flow, acting as a buffer that enables verification while maintaining replication speed.
Data Source
AI summary
A disaster recovery site storage array causes an instance of a host application or selected executables running on a host server to validate changes to an asynchronously updated replica of a storage object. Snapshots of the replica are generated before and after each set of changes to the replica are received from a remote storage array. Validation is performed by mounting snapshots to the instance of the associated host application and causing the host application instance to validate the data. If a snapshot is determined to be invalid, then the replica to recovered with the most recent known-valid snapshot. Alternatively, if each set of changes is validated prior to being applied to the replica, invalid changes are not applied to the replica. Unvalidated snapshots may be accumulated and validated independently from application of sets of changes to the replica, thereby decoupling validation from replication.