# System Backup and Recovery

> Chapter 14 of the Courseiva LINUX-PLUS curriculum — https://courseiva.com/learn/linux-plus/system-backup-and-recovery

**Official objective:** 4.3 — Perform backup, restore, and recovery procedures

## Introduction

System Backup and Recovery. Without it, a single mistake — a deleted file, a crashed disk, a ransomware encryption — can destroy months of work in seconds. For the XK0-006 exam, you must understand not just how to take a backup but how to choose the right type, where to store it, and how to bring your system back to life when everything goes wrong.

## The House Fire Analogy

What would you grab if your house caught fire right now? That question forces you to decide what is truly irreplaceable: photos, legal documents, a hard drive. System backup and recovery asks the same question, but about a computer. Instead of a house, you have a server. Instead of fire, you have a hard drive crash, a ransomware attack, or an accidental deletion. The backup is the fireproof safe you keep in the garage, updated every week. The recovery is the process of walking into that safe, pulling out a fire-resistant box, and rebuilding your living room from its contents. 

 In the real world, you have multiple safes. One safe is in the same room as the server — a full system image on an external drive. Another safe is across town — an off-site backup at a different building. A third safe is in a different country — cloud storage that survives a regional disaster. Each safe has a different combination. Each safe holds a different copy of your data, taken at different times. When the fire alarm sounds — when the server fails — you run to the nearest safe and pull out the most recent copy that is not burning. That is recovery: selecting the right backup version and restoring it to a new machine or the repaired one. 

 The key lesson is that backups protect you only if you test the recovery. A safe that cannot be opened in the dark, with smoke in your eyes, is useless. A backup that fails to restore is just a waste of disk space. That is why IT professionals practise recovery drills — they simulate the fire so they know, without thinking, exactly which safe to open and how fast.

## Core explanation

Backup and recovery are the safety net of any IT system. A backup is a copy of data — files, databases, or even the entire operating system — stored separately from the original. Recovery is the process of restoring that copy back to a working state after the original is lost or damaged. Without backups, a company that loses its data goes out of business. 

 There are three main types of backups. A full backup copies everything — every file, every byte. It is the most reliable but also the slowest to create and uses the most storage space. To take a full backup of a server with 500 gigabytes of data, you need 500 gigabytes of free space. 

 An incremental backup copies only the files that have changed since the last backup of any kind. If you take a full backup on Sunday, then an incremental on Monday copies only Monday's changes. Tuesday's incremental copies only Tuesday's changes, not Monday's. This saves enormous time and space, but restoring requires the last full backup plus every incremental backup in sequence. If any incremental is missing, you lose data from that point on. 

 A differential backup copies everything that has changed since the last full backup. Using the same Sunday full backup, a Monday differential copies Monday's changes. A Tuesday differential copies both Monday's and Tuesday's changes, because the full backup is still Sunday's. Restoring a differential backup is faster than incremental — you need only the full backup and the latest differential. But differentials grow larger each day, so they take longer to create as the week progresses. 

 Where you store backups matters enormously. A local backup sits on a drive or tape physically connected to the server. It is fast to create and restore, but if the building burns down or the server is stolen, you lose both the original and the backup. An off-site backup is stored in a different building or data centre. It survives a local disaster but may take longer to access. A cloud backup is stored on remote servers accessed over the internet. Multiple copies are often held across different geographic regions, providing the best disaster protection, but the restoration depends on your internet speed. 

 Backups are not a set-and-forget process. You must plan the backup schedule — how often to take full backups versus incrementals. You must design a retention policy — how long to keep each backup. For example, you might keep daily backups for one week, weekly backups for one month, and monthly backups for one year. You also need to secure backups — encrypt them so that even if someone steals the tape or breaches the cloud account, they cannot read the data. 

 Recovery is the second half of the equation. A restore is copying the backup data back to a system. Recovery can be a full restore — replacing the entire server from scratch — or a partial restore — recovering a single deleted file. The recovery point objective, or RPO, is the maximum acceptable age of a backup. If you back up every hour, your RPO is one hour — you accept losing up to one hour of work. The recovery time objective, or RTO, is how quickly you need the system to be back online. If your RTO is four hours, your backup and restore procedure must complete within four hours of the failure. RPO and RTO are critical concepts on the XK0-006 exam. 

 Common backup tools on Linux include 'tar' (tape archive), 'rsync' (remote sync), and 'dd' (disk dump). 'tar' creates archive files, often compressed with 'gzip' or 'bzip2'. 'rsync' synchronises files locally or over a network, copying only the changed parts. 'dd' copies raw disk blocks, making an exact bit-for-bit clone of a disk. The exam expects you to know the basic syntax of these commands, including options to compress, verify, and exclude files during backup.

## Real-world context

Imagine you work as a junior IT administrator for a small e-commerce company. The company runs its website on a single Linux server in a local data centre. Every night, a full backup of the server runs at midnight using 'tar' and writes the compressed archive to a network-attached storage device in the server room. That backup is then automatically copied to a cloud storage bucket in the same region. 

 One Tuesday morning at 9 AM, the server's hard drive fails completely. The website is down. The CEO calls, furious. You must restore the server to a working state as fast as possible. Here is the step-by-step process you follow: 

 - Step 1: Diagnose the failure. The server does not boot. You check the BIOS and confirm the hard drive is not detected. You replace the failed drive with a new one of equal or larger capacity. 
 - Step 2: Install a minimal Linux operating system on the new drive from a USB stick. This gives you a working environment to run the restore commands. 
 - Step 3: Mount the network-attached storage device that holds the latest backup. Copy the backup archive to the local server using 'scp' or 'rsync'. Because the backup is encrypted, you decrypt it with the stored key. 
 - Step 4: Extract the 'tar' archive into the root filesystem. Use 'tar -xzf backup.tar.gz -C /' to overwrite the minimal installation with the full server contents. 
 - Step 5: Reboot the server. The full system, including the website, database, and configurations, is restored. You verify the website loads, run a test order, and check the logs for errors. The entire process takes three hours. The RTO was four hours, so you succeeded. 

 The real-world lesson is that you must test this procedure before a disaster hits. If the backup is corrupted, or if the encryption key is lost, or if the network-attached storage device fails to mount, you discover those problems in the middle of a crisis. That is why companies perform quarterly disaster recovery drills. During a drill, you simulate the failure and restore a test server. You measure the actual time and identify bottlenecks. Maybe restoring from the cloud is slower than expected, so you decide to keep a local copy as well. 

 Another common scenario is accidental file deletion. A senior developer deletes a critical configuration file. You do not need a full server restore. Instead, you mount the backup and copy only that single file back to the server. With 'tar', you can extract individual files using 'tar -xf backup.tar.gz /path/to/file'. With 'rsync', you can synchronise the missing file from the backup server. These partial restores are fast and minimise downtime.

## Exam focus

The XK0-006 exam tests backup and recovery in several specific ways. You must know the differences between full, incremental, and differential backups cold. They will give you a scenario — for example, a backup that takes 10 hours on Sunday and 2 hours every subsequent day — and ask you to identify which backup type is being used. The answer is incremental because it only copies changes from the previous day. 

 Another common question type: given a disaster, which backup set do you need to restore? For a full backup plus five incrementals, you need all six. For a full backup plus two differentials, you need only the full backup and the most recent differential. The exam loves to present a sequence of backup times and ask what data loss occurs if a particular backup fails. Memorise the principle: incremental = need all; differential = need the last one. 

 Command-line proficiency is tested. Expect one or two questions asking what 'tar -czf backup.tar.gz /home' does: it creates a compressed archive of the /home directory. The option '-c' creates, '-z' compresses with gzip, '-f' specifies the filename. They may also test 'rsync -av /source /destination' — '-a' preserves permissions and timestamps, '-v' shows verbose output. The 'dd' command often appears in performance or disk-cloning contexts: 'dd if=/dev/sda of=/dev/sdb bs=4M' clones the entire disk sda to disk sdb. Know that 'bs' sets block size for efficiency. 

 Traps to avoid on the exam: 

 - They might describe a backup that copies all data each time but uses compression and call it 'differential'. That is wrong — it is still a full backup. 'Full' means copying all data, regardless of compression. 
 - They may ask about RPO and RTO. Remember: RPO is about data loss (how old is the backup?), RTO is about downtime (how fast can we restore?). Mixing these up is a common error. 
 - A question might give you a backup stored on the same server as the data and ask what risk it addresses. The correct answer: almost none — it protects against accidental deletion but not against hardware failure or ransomware that encrypts the entire server. A backup must be on a separate device or location. 
 - 'image-based' versus 'file-based' backups: image-based copies the entire disk (using 'dd'), file-based copies individual files (using 'tar' or 'rsync'). Image-based is faster for full restores but less flexible for single-file recovery. The exam may ask which to choose based on a scenario. 

 Finally, the exam expects you to know that backup encryption is a security requirement. They might ask about using 'gpg' with 'tar' to encrypt archives. Also know that 'dump' and 'restore' are legacy Linux tools for file system backups, though they are less common. Focus on 'tar', 'rsync', 'dd', and the concepts of RPO and RTO.

## Step by step

1. **Assess the Disaster** — Identify what went wrong — hard drive failure, accidental deletion, ransomware. Determine whether you need a full system restore or just a single file recovery. Check the last good backup timestamp to set expectations for data loss.
2. **Prepare the Recovery Environment** — Boot the server from a rescue disk or live USB. Install a minimal operating system if necessary. Mount the backup storage — either a local drive, network share, or cloud bucket. Ensure network connectivity for off-site backups.
3. **Locate and Verify the Backup** — Select the correct backup set: for a full backup, pick the most recent one. For incremental restores, gather the last full backup and all subsequent incrementals in order. Verify the backup file integrity using checksums or by listing its contents with 'tar -tf'.
4. **Perform the Restore** — Extract or copy the backup to the target location. For tar archives, use 'tar -xzf backup.tar.gz -C /'. For rsync, use 'rsync -av /mnt/backup/ /'. For dd, use 'dd if=backup.img of=/dev/sda bs=4M'. Watch for errors in the output.
5. **Validate and Verify** — Reboot the restored system. Run application tests, check logs, and verify data integrity. Confirm that services start and the system behaves as expected. Document the restore time and any issues for future improvements.

## Comparisons

### Full Backup vs Incremental Backup

**Full Backup:**
- Copies all data every time
- Largest file size and longest to create
- Restore requires only one file

**Incremental Backup:**
- Copies only data changed since last backup
- Smallest file size and fastest to create
- Restore requires full plus all incrementals

### Incremental Backup vs Differential Backup

**Incremental Backup:**
- Copies changes since last backup of any type
- Restore requires full plus all incrementals in order
- Each incremental is small

**Differential Backup:**
- Copies changes since last full backup only
- Restore requires full plus one differential
- Each differential grows larger over time

### Local Backup vs Off-site Backup

**Local Backup:**
- Stored on same premises or directly attached
- Fast to create and restore
- Vulnerable to same disasters as the original

**Off-site Backup:**
- Stored in a different physical location
- Slower to access, especially over network
- Survives local fires, theft, and floods

### Recovery Point Objective (RPO) vs Recovery Time Objective (RTO)

**Recovery Point Objective (RPO):**
- Measures acceptable data loss in time
- Example: 1 hour RPO means up to 1 hour of lost work
- Dictates backup frequency

**Recovery Time Objective (RTO):**
- Measures acceptable downtime duration
- Example: 4 hours RTO means system must be up in 4 hours
- Dictates restore speed and infrastructure

## Diagram

_A flowchart showing the three main backup types and the restore requirements for each, plus storage location options._

```mermaid
flowchart TD
    A[Backup Types] --> B[Full Backup: copies everything]
    A --> C[Incremental: changes since last backup]
    A --> D[Differential: changes since last full]
    B --> E[Restore: needs only full]
    C --> F[Restore: needs full + all incrementals]
    D --> G[Restore: needs full + last differential]
    H[Storage Locations] --> I[Local: fast but risky]
    H --> J[Off-site: safe from local disasters]
    H --> K[Cloud: geographically redundant]
```

## Common misconceptions

- **Misconception:** A backup on the same hard drive works just as well as one on a separate drive. **Reality:** A backup on the same drive is destroyed when the drive fails. It only protects against accidental file deletion, not hardware failure. (People think 'I copied the file to a different folder' is a backup. It is not — the same physical disk can fail completely.)
- **Misconception:** Once you create a backup, you are protected forever. **Reality:** Backups become outdated as data changes. You need a schedule — daily, weekly, or hourly — to keep the backup current. (Beginners treat backup like a one-time insurance policy. In reality, stale backups are nearly useless in an active business.)
- **Misconception:** Restoring from a backup always brings your system back exactly the way it was. **Reality:** Restores fail if the backup is corrupted, the hardware is incompatible, or the restore process is missing a step. Test restores are essential. (It feels logical that the copy is identical, but corruption, version mismatches, and incomplete backup sets are common. Only testing proves the backup works.)
- **Misconception:** Incremental and differential backups are the same thing. **Reality:** Incremental copies changes since the last backup of any type; differential copies changes since the last full backup. Differential restores need only two files; incremental restores need all of them. (The names sound similar, and both are smaller than full backups. Beginners forget which one requires only the last full backup plus a single file.)
- **Misconception:** Cloud backups are always the safest option. **Reality:** Cloud backups are safe from local disasters but depend on internet speed for restore, may incur high egress costs, and are subject to vendor lock-in or account compromise. (Cloud is marketed as infinitely safe, but beginners overlook the practical restore time and cost constraints.)

## Key takeaways

- A full backup copies all data; an incremental backup copies only changes since the last backup; a differential backup copies all changes since the last full backup.
- Always store backups on a separate device or location to protect against hardware failure and physical disasters.
- The recovery point objective (RPO) defines how much data loss you can tolerate; the recovery time objective (RTO) defines how quickly you must restore service.
- You must test your restores regularly — a backup that fails to restore is worthless.
- Use 'tar -czf' to create compressed archives, 'rsync -av' to synchronise files, and 'dd' for disk-level cloning.
- Encrypt your backups with tools like 'gpg' so that stolen media or compromised cloud accounts do not expose your data.

## FAQ

**What is the difference between a backup and a restore?**

A backup is the act of copying data to a safe location. A restore is the act of copying that data back to its original location after loss or damage. Think of backup as saving a file to a USB stick, and restore as copying it back to your computer.

**Can I use the same hard drive for the backup and the original data?**

No, you should never store backups on the same physical drive as the original data. If the drive fails, you lose everything. Always use a separate drive, a network location, or cloud storage.

**How often should I take backups?**

It depends on your recovery point objective (RPO). If you cannot afford to lose more than one hour of work, take backups hourly. For most businesses, daily backups are common, with weekly full backups and daily incrementals.

**What does the 'tar' command do in Linux?**

The 'tar' command creates or extracts archive files. It is the most common tool for Linux backups. Use 'tar -czf archive.tar.gz /folder' to create a compressed archive, and 'tar -xzf archive.tar.gz -C /destination' to restore it.

**Why do I need to test my backups?**

Backups can be corrupted, incomplete, or unreadable due to media errors, software bugs, or misconfiguration. Testing a restore ensures the backup actually works when you need it. Without testing, you might not know your backup is useless until a disaster strikes.

**What is a full system image backup?**

A full system image backup copies every byte on a disk, including the operating system, boot loader, applications, and data. It is created with tools like 'dd' or specialised imaging software. It allows you to restore the entire system onto a new disk exactly as it was.

## Check your understanding

1. **You take a full backup on Sunday and an incremental backup on Monday. On Tuesday, you suffer a disk failure. Which backup files do you need to restore the system?**

   Answer: You need the full backup from Sunday and the incremental backup from Monday.

2. **What is the primary difference between an incremental backup and a differential backup?**

   Answer: An incremental backup copies changes since the last backup of any type; a differential backup copies all changes since the last full backup.

3. **Which Linux command would you use to create a compressed archive of the /var/log directory for backup?**

   Answer: Use 'tar -czf backup_logs.tar.gz /var/log' to create a compressed archive.

4. **If a backup is stored on the same hard drive as the original data, what type of failure does it NOT protect against?**

   Answer: It does not protect against hard drive failure, because the backup is lost when the drive fails.

5. **What do RPO and RTO stand for?**

   Answer: RPO stands for Recovery Point Objective (acceptable data loss in time); RTO stands for Recovery Time Objective (acceptable downtime).

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/linux-plus/system-backup-and-recovery