Snapshots, Lab Reset Strategies, and Course Conventions

1. Recovery is part of the lab design

Snapshots are convenient, but they are not the same as independent backups or reproducible builds. A robust lab uses several recovery layers because each protects against different failures.

2. A disciplined checkpoint lifecycle

flowchart TD
  B["Verify clean baseline"] --> C["Create named checkpoint"]
  C --> E["Run bounded experiment"]
  E --> V["Verify expected result"]
  V --> K{"Keep the state?"}
  K -->|"Yes"| N["Document new baseline"]
  K -->|"No or failed"| R["Restore checkpoint"]
  R --> Q["Run reset verification"]
  Q --> B

A checkpoint without a verification procedure is only a hope. Record what “clean” means: release, kernel, hostname, network mode, disk usage, failed services, package state, and expected lab files.

3. Recovery methods by environment

4. Snapshot rules for the primary VM

• Shut down the guest for the most conservative filesystem-consistent snapshot unless the platform explicitly provides a trusted application-consistent workflow.
• Name checkpoints by sequence, purpose, and date—not “snapshot1”.
• Keep a small number of meaningful checkpoints; long chains consume storage and complicate recovery.
• Do not treat snapshots as archival backup. Hypervisor metadata or the entire host disk can still fail.
• Before reverting, preserve any logs or files needed to understand the failed experiment.

Recommended checkpoint names

00-clean-install-updated
01-chapter02-lab-ready
02-before-permissions-labs
03-before-storage-partitioning
04-before-firewall-hardening

Record beside each checkpoint:
- guest shutdown or live state
- distribution and kernel
- reason for creation
- expected restore test
- files that exist outside the snapshot

5. DevOps Academy Linux lab conventions

6. Command risk labels used in later lessons

7. Safe shell patterns for labs

# Establish a predictable lab directory.
chapter="02"
lesson="05"
lab="$HOME/devops-academy/linux/chapter${chapter}/lesson${lesson}"
mkdir -p -- "$lab"
printf 'Lab directory: %q\n' "$lab"
cd -- "$lab"

# Refuse to continue if the path is not under the expected course root.
case "$PWD" in
  "$HOME/devops-academy/linux/"*) ;;
  *) printf 'Refusing unexpected directory: %s\n' "$PWD" >&2; exit 1 ;;
esac

# Capture evidence before modifying a file.
cp -a -- example.conf "example.conf.before-$(date +%Y%m%d-%H%M%S)" 2>/dev/null || true

# Preview a generated target list before any removal.
printf '%s\n' ./*.tmp
# Only after verifying the list would a later lesson remove those exact files.

Quotes, -- option terminators, explicit paths, and guard conditions are not decoration. They reduce ambiguity when variables, filenames, or copied commands behave unexpectedly.

8. Create a machine-readable baseline manifest

A simple text manifest makes resets testable. It is not a full backup, but it records enough state to detect an incomplete restore.

baseline_report() {
  printf 'timestamp=%s\n' "$(date --iso-8601=seconds 2>/dev/null || date)"
  printf 'hostname=%s\n' "$(hostname)"
  printf 'kernel=%s\n' "$(uname -r)"
  printf 'architecture=%s\n' "$(uname -m)"
  printf 'boot_id=%s\n' "$(cat /proc/sys/kernel/random/boot_id)"
  printf 'virtualization=%s\n' "$(systemd-detect-virt 2>/dev/null || printf unknown)"
  printf 'failed_units=%s\n' "$(systemctl --failed --no-legend 2>/dev/null | wc -l)"
  printf 'root_usage=%s\n' "$(df -P / | awk 'NR==2 {print $5}')"
  printf 'primary_route=%s\n' "$(ip route show default | head -n 1)"
}

lab="$HOME/devops-academy/linux/chapter02/lesson05"
mkdir -p "$lab"
baseline_report > "$lab/chapter02-baseline.env"
cat "$lab/chapter02-baseline.env"

The boot ID changes after reboot and should not be compared as a fixed identity. It is useful evidence that a reboot or restore actually occurred. Define which fields must match and which should only be present.

9. Reset verification procedure

10. Hands-on lab: prove that your reset works

Perform this only after creating the Chapter 2 checkpoint. The exercise changes a file in your home directory, verifies it, restores the checkpoint, and confirms the marker disappeared.

lab="$HOME/devops-academy/linux/chapter02/lesson05"
mkdir -p "$lab"
marker="$lab/reset-test-marker.txt"

printf 'created_at=%s\n' "$(date --iso-8601=seconds 2>/dev/null || date)" > "$marker"
printf 'marker=%s\n' "$marker"
cat "$marker"

# STOP HERE.
# 1. Confirm the marker exists.
# 2. Restore the Chapter 2 clean checkpoint using the platform UI or safe
#    platform-specific restore process.
# 3. Reopen the terminal and run the verification commands below.

test ! -e "$marker" && printf 'PASS: marker removed by reset\n' || {
  printf 'FAIL: marker still exists after reset\n' >&2
  exit 1
}

cat "$HOME/devops-academy/linux/chapter02/lesson05/chapter02-baseline.env" 2>/dev/null || true
systemctl --failed --no-pager 2>/dev/null || true
ip route show default

11. Common recovery mistakes

12. Knowledge check

13. Chapter summary

Chapter 2 established a safe Linux laboratory: a deliberate distribution choice, a complete VM, a productive WSL option, disposable environments for bounded exercises, and a tested reset strategy. The remaining course can now include controlled system changes because the learner has a known baseline and recovery procedure.

14. Further reading

• Your hypervisor’s official snapshot, clone, and export documentation.
• Microsoft WSL export/import and distribution-management documentation.
• Cloud-provider image, snapshot, backup, and infrastructure-as-code documentation.
• GNU Bash Reference Manual — quoting, expansion, redirection, and shell safety.
• Linux manual pages for cp, test, date, systemctl, ip, and systemd-detect-virt.