Cascading Recovery Framework for SaaS Data Integrity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data management systems face challenges in providing effective backup and recovery services for software-as-a-service (SaaS) data due to its hierarchical nature and the use of multiple application programming interfaces (APIs) for access.

Innovation Solution

A cascading recovery framework is introduced that maintains hierarchical relationships between computing objects and tables, allowing for the cascading restore of SaaS applications. This framework identifies computing object hierarchies, associated APIs, and organizes tables based on API usage to enable efficient backup and restore operations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional backup methods are used for SaaS data, then backup operations can be performed, but the hierarchical relationships between computing objects and tables cannot be maintained, resulting in incomplete or inconsistent data recovery

Engineering Contradiction:
Improvedata recovery completenessVSAvoidrecovery framework complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments SaaS data into hierarchical computing objects (parent objects and child objects) with defined relationships. Each computing object is further segmented into associated tables that can be independently identified and restored while maintaining their hierarchical connections. This segmentation enables selective recovery of specific data portions while preserving overall data integrity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by establishing and storing the hierarchical relationships between computing objects and their associated tables before backup operations. The framework pre-identifies parent-child relationships and API associations, creating a recovery map that guides the restoration process. This preliminary structuring ensures that when recovery is needed, the hierarchical integrity is automatically maintained without requiring complex real-time analysis.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If multiple APIs are used to access SaaS data, then comprehensive data access is achieved, but the complexity of identifying and managing associated computing objects increases

Engineering Contradiction:
Improvedata access capabilityVSAvoidAPI management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system creates a universal framework that works across multiple different APIs by identifying common patterns in how SaaS applications expose data through APIs. The hierarchical computing object model serves as a universal abstraction layer that can map to various API structures. This allows the same recovery framework to handle different SaaS applications and their respective APIs without requiring application-specific customizations for each API type.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The hierarchical computing object model acts as an intermediary layer between the multiple APIs and the backup/recovery system. Instead of directly managing the complexity of multiple APIs, the system uses computing objects as mediators that abstract away API-specific details. The framework identifies and manages relationships at the computing object level, which then maps to the appropriate API calls, simplifying the overall management of multi-API environments.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If hierarchical relationships are maintained during backup, then data integrity is improved, but the time required for backup and restore operations increases

Engineering Contradiction:
Improvedata integrityVSAvoidbackup and restore time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system applies local quality by allowing selective restoration of different hierarchical levels. Users can restore entire computing object hierarchies when full data integrity is needed, or restore only specific parent or child objects when partial recovery suffices. The framework maintains the capability to restore at any level of the hierarchy, enabling optimization of restore time based on actual needs while preserving the option for complete integrity restoration when required.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The framework enables partial restoration actions where only the necessary portions of the hierarchical data structure are restored. Instead of always restoring complete hierarchies, the system allows selective restoration of specific computing objects or tables based on recovery needs. This partial action approach reduces restore time for common scenarios while maintaining the capability for full hierarchical restoration when complete data integrity is required.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS20250165356A1Recovery framework for software-as-a-service data
Publication Date: 2025.05.22 RUBRIK INC
  • US20250165356A1 patent drawing
  • US20250165356A1 patent drawing
  • US20250165356A1 patent drawing

AI summary

Methods, systems, and devices for data management are described. Software-as-a-service (SaaS) applications may host their customers' information in a distributed environment that is not directly accessible to the customers. SaaS applications may store data in the form of relational tables, meaning that data is organized in tables that have hierarchical parent and child relationships. Snapshots for SaaS applications may maintain hierarchical relationships between computing objects and tables to enable cascading recovery of SaaS applications. Based on a request to restore a computing object of a relational SaaS application, a data management system (DMS) may identify the associated computing objects to be recovered with the requested computing object based on the stored hierarchical information, and may call the relevant application programming interfaces (APIs) to restore the requested computing object and the associated computing objects to be recovered with the requested computing object.