Software Platform Backup Service Using Data Chunk Segmentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing data backup solutions for software platforms like content collaboration and issue tracking platforms are inefficient in terms of resource usage and complexity, making it difficult to restore data from specific points in time while minimizing storage and computational overhead.

Innovation Solution

A method that segments application data into chunks based on content attributes, generates unique identifiers for each chunk, and stores them with metadata for efficient retrieval and reconstruction, allowing for point-in-time data restoration with reduced storage and computational requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If data is backed up using conventional methods, then data can be restored from specific points in time, but storage requirements and computational overhead increase significantly

Engineering Contradiction:
Improvedata restoration capabilityVSAvoidstorage requirements
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent divides application data into discrete data chunks based on content attributes (stability, change frequency). Each chunk is independently backed up with a unique identifier, allowing selective restoration of only the necessary chunks rather than backing up entire datasets. This segmentation reduces storage requirements while maintaining point-in-time restoration capability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies different backup strategies to different data chunks based on their content attributes. Stable data chunks are backed up less frequently or with lower priority, while volatile data chunks are backed up more frequently. This local differentiation optimizes storage usage while ensuring critical data is preserved.

Inventive Principle:
Principle #3Local quality

2Reliability

If data is backed up using conventional methods, then data can be restored from specific points in time, but computational overhead and complexity increase

Engineering Contradiction:
Improvedata restoration capabilityVSAvoidcomputational overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

By segmenting data into chunks with unique identifiers and metadata, the system simplifies the backup and restoration processes. Instead of managing entire datasets, the system only needs to track and manipulate individual chunks, reducing computational complexity during both backup creation and restoration operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary analysis of data content attributes (stability, change frequency) before creating backups. This preliminary action allows the system to pre-determine which data should be segmented into which chunks and what backup strategy to apply, reducing computational overhead during the actual backup process.

Inventive Principle:
Principle #10Preliminary action

3Quantity of substance

If data is segmented into chunks based on content attributes, then storage requirements are reduced, but the complexity of data reconstruction increases

Engineering Contradiction:
Improvestorage requirementsVSAvoiddata reconstruction complexity
Core Design Contradiction:
Quantity of substanceVSDevice complexity

Solution Approach 1:

The system performs preliminary analysis of content attributes and creates metadata records that describe each data chunk's characteristics and relationships. This preliminary action provides the reconstruction system with pre-organized information about how chunks relate to the original data structure, simplifying the reconstruction process rather than increasing complexity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system uses metadata and unique identifiers as feedback mechanisms that track the relationship between data chunks and the original application data structure. During restoration, this feedback information guides the reconstruction process, making it systematic and manageable rather than complex.

Inventive Principle:
Principle #23Feedback

4Stability of the object's composition

If all data is backed up frequently, then data freshness is maintained, but storage and computational resources are wasted on stable data

Engineering Contradiction:
Improvedata freshnessVSAvoidcomputational resources
Core Design Contradiction:
Stability of the object's compositionVSUse of energy by moving object

Solution Approach 1:

The patent applies different backup frequencies and strategies to different data chunks based on their content attributes. Volatile data chunks (frequently changing) are backed up frequently to maintain freshness, while stable data chunks are backed up less frequently, reducing computational resource consumption on data that doesn't change often.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The system changes the backup parameter (frequency) based on the content attribute (stability) of each data chunk. This dynamic adjustment of backup parameters allows the system to optimize resource usage while maintaining data freshness for critical data.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12164472B2Backup service for a software platform
Publication Date: 2024.12.10 ATLASSIAN PTY LTD
  • US12164472B2 patent drawing
  • US12164472B2 patent drawing
  • US12164472B2 patent drawing

AI summary

Systems and methods for backing up data for a software platform include segmenting data objects from a software platform into data chunks, which are subsequently stored. Data chunks may include content from data objects having similar content attributes, such as content type and an estimated frequency at which the content changes. In various embodiments, pages from a content collaboration platform and issues from an issue tracking platform are grouped into chunks and stored for backup. A size of the chunks may be based on one or more content attributes associated with the pages or issues. Examples of content attributes include a relationship between text and non-text content, a number of associated users, and a number of comments.