Automated Data Restoration via Client File Fingerprinting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current client-based backup systems face inefficiencies in detecting and replacing corrupted files, as the number of files increases, leading to higher likelihoods of corruption and manual efforts required to locate and replace corrupted files, which can propagate errors and are inefficient.

Innovation Solution

An apparatus and method for data restoration that identifies missing or corrupt files by generating a file fingerprint using MD5 or SHA-2 hash functions, determines if clients have a copy, and requests the file from clients, utilizing a metabase and content database to manage file information and storage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual methods are used to locate and replace corrupted files, then administrators can identify and fix file corruption, but the process becomes inefficient and time-consuming as the number of clients grows

Engineering Contradiction:
Improvefile corruption detectionVSAvoidmanual lookup time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The backup system automatically detects corrupted files using hash verification and self-repairs them by retrieving clean copies from other clients, eliminating the need for manual administrator intervention. The system performs self-diagnosis through hash comparison and self-healing by automatically requesting and restoring files from peer clients.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system continuously monitors file integrity by comparing hash values of backed-up files against original hashes stored in the metadata database. When corruption is detected through hash mismatch, the system triggers an automatic repair process that queries other clients for clean copies, creating a closed-loop feedback mechanism for maintaining data integrity.

Inventive Principle:
Principle #23Feedback

2Reliability

If copies of backup system storage are made to prevent file corruption, then data redundancy is increased, but storage costs increase and corrupt files may be propagated

Engineering Contradiction:
Improvedata redundancyVSAvoidstorage capacity
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

Instead of creating physical copies of entire backup storage, the system creates virtual redundancy by distributing file copies across multiple client machines. When a file is backed up, the system stores it centrally but maintains awareness of which clients have local copies through metadata tracking, enabling rapid restoration without duplicating storage infrastructure.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The system combines the backup storage function with available client storage resources. Rather than maintaining separate redundant backup copies, the system leverages clients' existing storage capacity to hold file copies, merging the backup infrastructure with client resources to reduce overall storage requirements.

Inventive Principle:
Principle #5Merging (Combining)

3Quantity of substance

If the number of files in backup storage increases, then more data is protected, but the likelihood of file corruption increases

Engineering Contradiction:
Improvedata volumeVSAvoidfile corruption risk
Core Design Contradiction:
Quantity of substanceVSReliability

Solution Approach 1:

The system performs preliminary hash verification on files during the backup process and continuously monitors stored files for corruption. By detecting corruption early through hash comparison before it propagates or affects multiple systems, the system prevents the accumulation of corrupted data as the backup repository grows.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system replaces physical inspection and manual verification methods with cryptographic hash functions for file integrity verification. This substitution enables automated, error-free detection of file corruption across large volumes of data without the limitations of manual checking, maintaining reliability even as data volume increases.

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

4Ease of repair

If administrators manually request new copies of corrupted files from clients, then file restoration is possible, but the process is inefficient and error-prone

Engineering Contradiction:
Improvefile restorationVSAvoidmanual intervention level
Core Design Contradiction:
Ease of repairVSExtent of automation

Solution Approach 1:

The backup system automatically detects corrupted files through hash verification and initiates self-repair by querying the metadata database to identify clients with clean copies. The system autonomously requests and restores files without administrator intervention, making the repair process both easier and fully automated.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system maintains preliminary records in the metadata database of which clients have which files and their hash values. This preliminary information preparation enables rapid automated restoration by immediately identifying suitable source clients when corruption is detected, eliminating the need for manual client lookup and file request processes.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9990254B1Techniques for data restoration
Publication Date: 2018.06.05 COHESITY INC
  • US9990254B1 patent drawing
  • US9990254B1 patent drawing
  • US9990254B1 patent drawing

AI summary

Techniques for data restoration are disclosed. In one particular exemplary embodiment, the techniques may be realized as an apparatus for data restoration. The apparatus may comprise a module to identify a missing or corrupt file. The apparatus may also comprise a module to determine a file fingerprint of the missing or corrupt file from one or more associated databases and a module to determine if one or more clients has a copy of the missing or corrupt file. The apparatus may further comprise a module to request the missing or corrupt file from one or more of the one or more clients.