Name: The Foundation of Iron — Week 14 — High Availability and Backup
Author: Amine RAITI

RATIO

THE FOUNDATION OF IRON · COURSE MATERIAL · WEEK 14

◆◆◆

HIGH AVAILABILITY
AND BACKUP
Week 14 of 26 · Block 5 — Bare Metal OS
8h theory · 27h practice

◆

◆ WEEKLY LEARNING OBJECTIVES

1. Understand RPO and RTO
2. Configure a simple two-node cluster on the hypervisor
3. Test automatic VM failover on node failure
4. Implement a GFS (Grandfather-Father-Son) backup strategy
5. Automate backups and test restoration

◆◆◆

⚠ WARNING — SHELF LIFE OF VERSIONS REFERENCED HERE

Cluster and HA mechanisms evolve with hypervisor versions. This material presents generic concepts; the instructor adapts the specific procedures to the tool in use.

◆

Amine RAITI · Infrastructure Architect & SRE
Public document · CC BY-NC-SA 4.0 · AI Powered by Amine
Opération Dindon

RATIO

COURSE OUTLINE · 8H

THEORY GUIDING THREAD

◆

14.1 · RPO, RTO and service continuity2h

— RPO (Recovery Point Objective): what is the maximum acceptable data loss?
— RTO (Recovery Time Objective): how long can the service be unavailable?
— These two parameters define the backup and HA strategy to implement — have trainees calculate RPO and RTO for a provided business scenario

14.2 · Cluster and high availability3h

— Cluster principle: several physical hosts sharing a resource pool, with automatic VM failover in case of a host failure
— Quorum concept: why an odd number of nodes is recommended (recall the voting logic from Week 3 — Boolean applied to cluster decisions)
— Shared storage or synchronous replication as a HA prerequisite

14.3 · Backup strategies3h

— Difference between full / incremental / differential backup — advantages and drawbacks of each
— GFS (Grandfather-Father-Son) strategy: rotating backup sets across daily, weekly and monthly periods
— 3-2-1 rule: 3 copies, 2 different media, 1 offsite copy

RATIO

EXERCISE 1 · CLUSTER AND AUTOMATIC FAILOVER · 14H

Equipment: two physical nodes or two VMs acting as hypervisor nodes, shared storage (NFS or minimal Ceph if available) or replication depending on the hypervisor version.

(3h) Configuring the two-node cluster: adding the second node, checking the quorum, exploring the cluster management interface.

(3h) Migrating a VM from one node to the other (live migration if shared storage is available, cold migration otherwise) — observing VM behaviour during migration.

(4h) Failure simulation: deliberately cutting a node's network or power, observing the cluster's reaction (detection delay, automatic VM failover to the surviving node).

(2h) Analysing the cluster's event logs during the simulated failure and recovery, identifying the actual failover delay.

(2h) Writing a table documenting the observed RPO and RTO during the test, comparing against the objectives set at the start.

SOLUTION — EXERCISE 1

Expected failover test results: the node failure detection delay is typically a few seconds to a few minutes depending on the cluster configuration (heartbeat timeout). The VM must restart automatically on the surviving node, with an effective RTO corresponding to this detection delay plus the VM's boot time.

Teaching point on RPO: in a failure scenario without shared storage, data not saved since the last snapshot or backup is lost — the RPO is directly tied to backup frequency, not to HA configuration alone.

RATIO

EXERCISE 2 · AUTOMATED BACKUP STRATEGY · 13H

Equipment: hypervisor configured in Exercise 1, external storage space (NAS or dedicated disk).

(3h) Configuring external backup storage on the hypervisor, verifying connectivity and available space.

(3h) Scheduling an automatic daily backup of the test VM, with retention configured according to the GFS strategy (7 daily, 4 weekly, 3 monthly backups).

(3h) Full restoration test from a backup: delete a VM, restore it from the most recent backup, verify the restored system's integrity.

(2h) Restoration from an older backup (simulating recovery from a state prior to a data corruption), documenting the actual data loss (real RPO).

(2h) Writing the final backup plan documenting the implemented strategy, retention periods, and tested restoration procedures.

SOLUTION — EXERCISE 2

Expected backup plan: the document must explicitly state the RPO (what is the maximum data loss if a restore is needed, based on backup frequency), the RTO (how long a full restore takes, measured during the exercise), and the total backup retention duration.

◆ SUMMARY SHEET — WEEK 14 SELF-ASSESSMENT

1. I can define RPO and RTO and calculate them for a given scenario.

2. I can configure a two-node cluster on a hypervisor.

3. I can migrate a VM from one node to another.

4. I can test and measure the automatic failover delay.

5. I can explain the GFS backup strategy.

6. I can schedule automated backups with retention.

7. I can restore a VM from a backup and validate its integrity.

8. I can document a backup plan with measured RPO and RTO.