RHCSA (029): Season 2 - Scenario 4 of 25: The Haunted Archive Recovery

Episode 029 Executive Summary

The Haunted Archive Recovery simulates a stalled backup process that leaves your file system in an inconsistent state with scattered files and corrupted data. This specific type of gray area frequently trips up RHCSA candidates because exam instructions rarely pinpoint the exact failure. You are stepping into a server where a previous automation failure has left oversized log files and a corrupted archive in its wake. My goal is to give you a safe sandbox to practice the forensic work required to identify these phantom files and the technical precision to clean them up without causing further data loss.

The core of this challenge forces you to master the interaction between storage restrictions and file retrieval. I intentionally locked down the staging directory, your temporary workspace, with incorrect ownership and restrictive permissions to mimic a neglected corner of a production server. You cannot simply move files here. You must first diagnose the permission blockage and then execute a precise command to surgically extract only the logs that meet specific size and time criteria. This sequence is designed to harden your understanding of standard Linux permissions and filter syntax so that these commands become second nature during the pressure of a timed exam.

We finish with a critical restoration task that validates your ability to handle sensitive file metadata. The exam frequently tests your ability to restore data without stripping away security contexts, which are the invisible labels that control file access. This is why the archive requires the preservation of both extended attributes and SELinux labels. You will verify that every restored file lands with its original security posture intact before executing a zero-trace cleanup to remove all temporary artifacts. By the end of this episode, you will have transformed a chaotic and broken environment into a pristine state which is the ultimate proof of competence for any Red Hat system administrator.

Keywords: RHCSA, Red Hat Enterprise Linux, RHEL, EX200, tar command, find command, archive restoration, SELinux contexts, extended attributes, xattrs, file permissions, chmod, chown, system troubleshooting, log management, backup recovery, Linux file system, command line practice, sysadmin training, disaster recovery

Episode Info

• Season: 2 | Difficulty: High
• Objectives: Primary [1.6, 1.8, 1.10]; Secondary [10.5]
• Lab Focus: tar, find, permissions, xattrs, selinux, archive-restoration

1. Scenario Brief (The Problem)

An automated backup script on the production server app-server failed, leaving behind a corrupted archive and several misplaced log files. As the senior architect, you must locate all log files larger than 10MB modified in the last 24 hours, move them to a secure staging area, and then restore a legacy archive while preserving all extended attributes and SELinux contexts. The previous administrator left the staging directory with incorrect ownership and restrictive permissions, preventing any write operations.

2. Task Analysis (The "Why")

• [1.6]: Archiving and unpacking files using tar is the standard method for data migration and restoration in RHEL 10.
• [1.8]: Moving misplaced files and performing cleanups (`rm`) ensures the file system remains organized and compliant.
• [1.10]: Modifying standard ugo/rwx permissions is required to fix the "broken" state of the recovery directory.
• [10.5]: Verifying SELinux contexts is critical when restoring files to ensure security labels are not stripped during extraction.

3. Solution Steps

Step 1: Environment Setup (Root Only)

Run the following commands to create the "broken" initial state for the lab.

# Define staging area for consistency
STAGING=/var/tmp/recovery_staging

# Define archive location
ARCHIVE=/var/tmp/legacy_data.tar

# Create a broken initial state
mkdir -p $STAGING
chmod 555 $STAGING
chown nobody:nobody $STAGING

# Create the dummy error log
touch /var/log/oversized_error.log
truncate -s 15M /var/log/oversized_error.log

# Create the source archive with SELinux and Extended Attributes
tar --selinux --xattrs -cpvf $ARCHIVE /etc/hostname /etc/resolv.conf

Step 2: Core Implementation (Execute as Root)

Execute the recovery sequence.

# Fix directory permissions and ownership
chown root:root /var/tmp/recovery_staging
chmod 755 /var/tmp/recovery_staging

# Locate and move oversized logs modified within the last day
find /var/log -type f -size +10M -mtime -1 -exec mv {} /var/tmp/recovery_staging/ \;

# Extract archive while preserving SELinux and Extended Attributes
tar --selinux --xattrs -xpf /var/tmp/legacy_data.tar -C /var/tmp/recovery_staging/

Technical Breakdown:

• -size +10M: Selects files strictly greater than 10MiB.
• -mtime -1: Selects files modified within the last 24 hours.
• --selinux: Specifically instructs tar to include/extract SELinux contexts.
• --xattrs: Includes all extended attributes such as ACLs.
• -C: Changes to the target directory before performing the extraction.

Pro-Tip: On the RHCSA, using tar with --selinux is the modern requirement; always verify the extraction directory is writable before starting.

Step 3: Verification (The "Proof of Work")

# Check if the log file was moved successfully
ls -lh /var/tmp/recovery_staging/oversized_error.log
# EXPECTED: -rw-r--r--. 1 root root 15M (Date) /var/tmp/recovery_staging/oversized_error.log

# Verify the extraction and SELinux contexts
ls -Z /var/tmp/recovery_staging/etc/hostname
# EXPECTED: system_u:object_r:etc_t:s0 /var/tmp/recovery_staging/etc/hostname

# Confirm the source log is gone
ls /var/log/oversized_error.log
# EXPECTED: ls: cannot access '/var/log/oversized_error.log': No such file or directory

4. Comprehensive Cleanup (Zero-Trace)

rm -rf /var/tmp/recovery_staging
rm -f /var/tmp/legacy_data.tar