Selective Retention Locking With Subdirectory Exclusion for Backup Metadata

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Non-integrated backup applications face issues with automatic retention locking (ARL) as metadata modifications lead to subsequent backup job failures, and implementing separate Mtrees for metadata and backup data complicates workflows and reduces Mtree availability, while integrating retention-locking capabilities requires significant resources.

Innovation Solution

A system and method for selective auto retention locking at the directory level, allowing non-integrated backup applications to store non-locked metadata files with locked backup data in the same ARL-enabled Mtree, using directory-level exclusion policies and inode metadata to manage retention lock attributes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If automatic retention locking is enabled at the Mtree level, then backup data is locked for retention compliance, but metadata files become locked and subsequent backup jobs fail

Engineering Contradiction:

Improveretention lock reliabilityVSAvoidbackup job continuity

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The patent segments the Mtree into different namespaces: one for backup data with ARL enabled and another for metadata with ARL disabled. This allows selective application of retention locking to only the necessary data portions while leaving metadata modifiable, thus resolving the contradiction between retention reliability and backup job continuity.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent applies different retention locking qualities to different regions within the Mtree. Backup data directories receive full ARL protection while metadata directories are excluded from ARL. This local differentiation enables both locked backup data and modifiable metadata to coexist in the same Mtree, maintaining both retention reliability and operational productivity.

Inventive Principle:

Principle #3Local quality

2Ease of operation

If separate Mtrees are used for metadata and backup data, then metadata can be modified without locking issues, but Mtree availability is reduced and workflows become complex

Engineering Contradiction:

Improvemetadata modification easeVSAvoidMtree structure complexity

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent merges the metadata namespace and backup data namespace into a single Mtree structure while applying different ARL policies to each. This consolidation eliminates the need for separate Mtrees and complex workflow management, allowing both metadata and backup data to coexist in one unified namespace with differentiated locking behaviors.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The Mtree is designed to serve multiple functions simultaneously: storing both modifiable metadata and locked backup data within the same structure. By making the Mtree universal and capable of handling different data types with different retention requirements, the system avoids the complexity of maintaining separate Mtrees while preserving ease of metadata modification.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Reliability

If ARL is applied to the entire Mtree, then all data receives retention protection, but non-integrated backup applications cannot function properly

Engineering Contradiction:

Improveretention protection coverageVSAvoidbackup application compatibility

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the ARL application scope within the Mtree, enabling it to be applied selectively to backup data namespaces while excluding metadata namespaces. This segmentation allows non-integrated backup applications to write and modify metadata without triggering ARL, while backup data still receives full retention protection, thus improving application compatibility without sacrificing protection coverage.

Inventive Principle:

Principle #1Segmentation

4Productivity

If manual locking is used instead of automatic locking, then no cooling period is needed, but explicit lock operations are required for every file

Engineering Contradiction:

Improvelock operation speedVSAvoidlock management simplicity

Core Design Contradiction:

ProductivityVSEase of operation

Solution Approach 1:

The system implements self-service automatic retention locking for backup data through the ARL mechanism, which automatically locks files after the cooling period without requiring explicit user actions. This maintains the productivity advantage of ARL while the selective namespace approach simplifies management by automatically excluding metadata from locking requirements.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS12547588B1Selective auto retention locking through sub-directory level exclusion policy

Publication Date: 2026.02.10 DELL PROD LP

AI summary

A selective automatic retention lock system defines, as attributes, an automatic retention lock (ARL) period specifying an amount of time to lock the file, and a cooling (COP) period specifying an amount of time within the first ARL after which the file will be locked if no modifications are made to the file during the first COP. An entire directory tree can be designated as ARL enabled, and certain sub-level directories within the namespace can be excluded from ARL by appropriate labeling so that files in the directory cannot be auto retention locked under the ARL policy of the entire directory tree.