[Spike] Investigate backup handling and symlink relevance for current and previous dotCMS versions

Parent Issue

No parent issue identified.

User Story

As a team, we need to investigate and determine how previous versions of dotCMS handle backup storage and whether the current implementation of the symlink for the backup directory is still necessary. This spike will help us understand the evolution of the backup process and whether the symlink can be safely removed in more recent versions of dotCMS.

Problem Statement

Historically, dotCMS would attempt to archive and store assets and other backup items in a directory within the container using ephemeral storage. This led to issues in environments with large asset volumes, such as:

• Pods running out of storage.
• Disk pressure on the underlying node, potentially causing pod evictions.

To address this, a symlink was introduced, storing the backup directory on a persistent volume (e.g., EFS) to avoid storage limitations and prevent backups from duplicating themselves in a recursive loop.

For current versions of dotCMS, the backup function no longer buffers and archives on the local filesystem but streams the data instead. Therefore, the symlink may no longer be necessary, but this needs verification to ensure compatibility with both current and previous versions of dotCMS.

Acceptance Criteria

1. Investigate and verify:

   • How previous versions of dotCMS handle backup storage.
   • Whether the symlink for the backup directory is still required for current and older versions of dotCMS.

2. Identify which versions of dotCMS require the symlink, if any.

3. Provide clear documentation of findings and recommendations for managing backups in both current and older versions of dotCMS.

Proposed Objective

Research and Validation

Proposed Priority

Priority 2 - Important

dotCMS Version

Applicable to both current and previous versions of dotCMS.

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No external links provided.

Assumptions & Initiation Needs

1. Backup processes in older versions of dotCMS may still rely on local storage for buffering and archiving.
2. The symlink's relevance needs to be confirmed for both legacy and current implementations.

Quality Assurance Notes & Workarounds

• Validate the backup process in environments with large asset volumes to ensure no regressions.
• Ensure any proposed changes do not negatively impact customers using older versions of dotCMS.

Sub-Tasks & Estimates

• [ ] Investigate the backup process for previous versions of dotCMS.
• [ ] Verify the current implementation of the backup function in recent dotCMS versions.
• [ ] Document findings and identify any required changes or deprecations.
• [ ] Update related documentation and provide recommendations based on findings.