LFCA 70 🐧 Restoring from a Backup
The previous chapters covered tar and rsync — the tools that create backups. This chapter covers the step that matters most: restoring. A backup that has never been restored is not a backup. It is an unverified copy of data that may or may not be usable when you need it. The LFCA exam places backup and recovery under System Administration Fundamentals, which carries 20% of the total weight. The competency list explicitly includes “Disaster Recovery” and recovery planning . The exam does not just ask “how do you make a backup” — it asks “how do you get your system back.”
Restoring is a different skill from backing up. It requires knowing what to restore, where to restore it, and in what order. It requires understanding that the live system is running while you restore files over it, and that some files cannot be replaced while the system is up. It requires testing the restore long before you need it.
Key point: A restore is not the reverse of a backup. It is a separate operation with its own failure modes. The most common cause of restore failure is not a corrupted backup — it is an untested restore procedure. The second most common is restoring the wrong files to the wrong location. The discipline is to practice restoring to a test directory, verify the result, and then perform the actual restore with confidence .
Why restore planning matters
Every backup strategy has a restore strategy hidden inside it. If the restore is impossible or impractical, the backup is useless, no matter how well it was made.
The untested-backup problem. A backup archive that has never been opened may contain anything. The tar file may have been truncated when the disk filled. The rsync mirror may have been interrupted mid-transfer. The gzip stream may be corrupted. The only way to know is to extract the archive to a test directory and verify the contents . Until that happens, the backup is a promise, not a fact.
The wrong-file problem. A restore is only useful if you restore the right files to the right place. An administrator restoring /etc from a backup made three months ago will overwrite the current /etc/passwd with an outdated version, creating user accounts that should have been removed and removing accounts that were added since. Restoring /home from a week-old backup will lose a week of work. The decision of what to restore is as important as the restore itself .
The order problem. Not all restores are a single operation. A full system restore from tar and rsync requires restoring /etc, /home, /var, and application directories in the right order. If /etc is restored after the system is already running, services must be restarted. If /home is restored while users are logged in, their sessions will conflict with the restored files. The restore plan must account for what is running while the restore happens .
The permissions problem. System files are owned by root. A restore performed as a regular user will produce files owned by that user, which may cause services to fail. A restore performed as root preserves ownership. The -p flag for tar and the -a flag for rsync are essential for system restores .
The trade-off. Restoring is slower and more stressful than backing up. Backups run on a schedule, unattended, without consequences for mistakes. Restores happen under pressure, with consequences. The only way to make restores reliable is to practice them when there is no pressure — to restore to a test location periodically, to verify the procedure, and to write it down. The LFCA exam tests whether you understand this discipline .
a. The Restore Workflow
The restore workflow has four phases: identify, test, restore, and verify. Skipping any phase increases the risk of a failed restore.
Identify is the phase where you decide what needs to be restored. The answer depends on what failed. If a single configuration file was accidentally deleted, restore that one file. If a user’s home directory was corrupted, restore the home directory. If the system disk failed, restore everything. The scope of the restore determines which backup to use and how much work is involved.
Test is the phase where you extract the backup to a temporary location and verify that it contains what you need. This is the step that most administrators skip, and it is the step that saves the most time.
# Test a tar archive by listing it
tar -tzf /backup/full-2025-05-07.tar.gz | head -20
# Test by extracting to a temporary directory
mkdir -p /tmp/restore-test
tar -xzf /backup/full-2025-05-07.tar.gz -C /tmp/restore-test
ls /tmp/restore-test/etc/nginx/For an rsync backup, the test is simpler: the backup is already a directory tree. You can browse it directly with ls and cat, compare it against the current state with rsync --dry-run, or copy specific files from it.
Restore is the phase where the actual replacement happens. The correct command depends on the scope. A single file is restored with tar -xzf archive.tar.gz path/to/file -C /destination/ or with rsync backup/file /destination/. A directory is restored with the same commands targeting the directory. A full system restore requires the system to be booted from rescue media, because the running system’s files cannot be replaced while it is running.
Verify is the phase where you confirm that the restore worked. For a single file, this means checking that the file exists, has the correct content, and is owned by the correct user. For a directory, it means checking the file count, the permissions, and the ownership. For a full restore, it means booting the system, checking that services start, and verifying that data is accessible.
b. Restoring from tar
The tar command restores files by extracting them from an archive. The -x flag extracts, and the archive path and destination are specified.
# List the archive first
tar -tzf /backup/full-2025-05-07.tar.gz | grep "etc/nginx"
# Extract the entire archive to a test directory
mkdir -p /tmp/restore-test
tar -xzf /backup/full-2025-05-07.tar.gz -C /tmp/restore-test
# Extract a single file
tar -xzf /backup/full-2025-05-07.tar.gz etc/nginx/nginx.conf -C /tmp/single
# Extract a directory
tar -xzf /backup/full-2025-05-07.tar.gz etc/nginx/ -C /tmp/restore-nginxThe path specified after the archive name must match the path stored in the archive. This is why listing the archive first is essential — the path in the archive may include a leading directory or be relative to a different root than expected.
For a system restore as root, the -p flag preserves permissions and ownership. Without it, the restored files will be owned by root but lose the original permission bits and could break services.
# System restore as root
sudo tar -xzpf /backup/full-2025-05-07.tar.gz -C /mnt/restored-systemThe destination must exist. tar does not create the destination directory; it only extracts into it. For a restore to a mounted filesystem (like a failed system disk mounted at /mnt/restored-system), the destination is the mount point.
The --overwrite behavior of tar is important. By default, tar overwrites existing files during extraction. There is no confirmation prompt. A restore to the wrong directory will silently replace files. Use --keep-old-files or --skip-old-files to prevent this behavior when extracting to a location that already has data .
c. Restoring from rsync
The rsync restore is the reverse of the backup command. The source becomes the backup directory, and the destination becomes the location to restore to.
# Restore a single file
rsync -av /backup/2025-05-07/home/user/important.txt /home/user/
# Restore a directory
rsync -av /backup/2025-05-07/home/user/documents/ /home/user/documents/
# Restore the entire home directory
rsync -av /backup/2025-05-07/home/user/ /home/user/The trailing slash on the source determines whether the directory itself or its contents are restored. rsync -av /backup/2025-05-07/home/user/ /home/user/ restores the contents of user/ into /home/user/. Without the trailing slash, it would create /home/user/user/, which is almost never what you want .
The --delete flag is dangerous during a restore. If the backup contains fewer files than the current state — because files were added after the backup was made — then --delete will remove those files from the destination. This may be correct (to restore the system to the backup’s state) or incorrect (if the goal is to recover specific files without losing newer ones). Always dry-run with --delete before using it.
# Dry run to see what would change
rsync -avn --delete /backup/2025-05-07/home/user/ /home/user/For a system restore from a remote backup, the same command works over SSH:
rsync -avz user@backup-server:/backup/2025-05-07/home/user/ /home/user/The -z flag compresses the transfer. For a large restore, this can take a long time. The -P flag shows progress and supports resuming partial transfers, which is useful for restores over unreliable connections .
Complete Example Session
This session demonstrates restoring a single file, restoring a directory, restoring an entire system, and verifying the result.
# ============================================
# PART 1: RESTORING A SINGLE FILE FROM tar
# ============================================
# The user deleted nginx.conf
ls /etc/nginx/nginx.conf
# ls: cannot access '/etc/nginx/nginx.conf': No such file or directory
# Find the file in the archive
tar -tzf /backup/full-2025-05-07.tar.gz | grep nginx.conf
# etc/nginx/nginx.conf
# Extract it to a temporary location first
mkdir -p /tmp/restore-single
tar -xzf /backup/full-2025-05-07.tar.gz etc/nginx/nginx.conf -C /tmp/restore-single
# Verify the content
cat /tmp/restore-single/etc/nginx/nginx.conf
# Copy it to the correct location
sudo cp /tmp/restore-single/etc/nginx/nginx.conf /etc/nginx/nginx.conf
# Restart nginx
sudo systemctl restart nginx
# ============================================
# PART 2: RESTORING A SINGLE FILE FROM rsync
# ============================================
# The user deleted a document
ls /home/user/documents/report.odt
# ls: cannot access '...': No such file or directory
# Restore it from the latest rsync backup
rsync -av /backup/latest/home/user/documents/report.odt /home/user/documents/
# Verify
ls -l /home/user/documents/report.odt
# ============================================
# PART 3: RESTORING A DIRECTORY
# ============================================
# The entire documents folder was corrupted
mkdir -p /tmp/restore-docs
tar -xzf /backup/full-2025-05-07.tar.gz home/user/documents/ -C /tmp/restore-docs
# Verify the file count
ls /tmp/restore-docs/home/user/documents/ | wc -l
ls /home/user/documents/ | wc -l
# Restore the entire directory
rsync -av /tmp/restore-docs/home/user/documents/ /home/user/documents/
# ============================================
# PART 4: RESTORING FROM A DIFFERENTIAL BACKUP
# ============================================
# Restore the full backup first
mkdir -p /mnt/restore
tar -xzpf /backup/full-2025-05-07.tar.gz -C /mnt/restore
# Restore the most recent differential
tar -xzpf /backup/diff-2025-05-09.tar.gz -C /mnt/restore
# The two extracts together produce the state at the differential's time.
# ============================================
# PART 5: RESTORING FROM INCREMENTAL BACKUPS
# ============================================
# Restore the full backup
mkdir -p /mnt/restore
rsync -av /backup/rsync/full/ /mnt/restore/
# Restore each incremental in order
rsync -av /backup/rsync/inc-2025-05-08/ /mnt/restore/
rsync -av /backup/rsync/inc-2025-05-09/ /mnt/restore/
rsync -av /backup/rsync/inc-2025-05-10/ /mnt/restore/
# Every incremental must be applied in order.
# ============================================
# PART 6: THE FULL SYSTEM RESTORE (FROM RESCUE)
# ============================================
# Boot from a live USB or rescue media.
# Mount the failed system's disk
mkdir -p /mnt/restored-system
mount /dev/sda2 /mnt/restored-system
# Restore the system from the tar backup
tar -xzpf /backup/full-2025-05-07.tar.gz -C /mnt/restored-system
# Restore the bootloader if needed
mount --bind /dev /mnt/restored-system/dev
mount --bind /proc /mnt/restored-system/proc
mount --bind /sys /mnt/restored-system/sys
chroot /mnt/restored-system
grub-install /dev/sda
update-grub
exit
# Unmount and reboot
umount -R /mnt/restored-system
reboot
# ============================================
# PART 7: THE RESTORE TO A TEST LOCATION
# ============================================
# Always test a full restore first
mkdir -p /tmp/restore-verify
tar -xzpf /backup/full-2025-05-07.tar.gz -C /tmp/restore-verify
# Compare file counts
find /tmp/restore-verify -type f | wc -l
find / -type f 2>/dev/null | wc -l
# Verify key files exist
ls /tmp/restore-verify/etc/passwd
ls /tmp/restore-verify/etc/nginx/nginx.conf
ls /tmp/restore-verify/home/user/.bashrc
# ============================================
# PART 8: THE PARTIAL RESTORE
# ============================================
# Restore only a specific directory from the archive
sudo tar -xzpf /backup/full-2025-05-07.tar.gz \
var/www/html/ \
-C /mnt/restored-web
# This restores only the web content, not the whole system.
# ============================================
# PART 9: THE OVERWRITE GUARD
# ============================================
# Extract without overwriting existing files
tar -xzf /backup/full-2025-05-07.tar.gz -C /tmp/restore-test \
--keep-old-files
# If a file exists, tar will error rather than overwrite.
# Or skip existing files silently
tar -xzf /backup/full-2025-05-07.tar.gz -C /tmp/restore-test \
--skip-old-files
# ============================================
# PART 10: THE RESTORE VERIFICATION CHECKLIST
# ============================================
# After any restore:
# 1. File count matches the source
# 2. Ownership is correct (ls -la)
# 3. Permissions are correct
# 4. Services start successfully
# 5. Application data is accessible
# 6. Logs show no errors
# 7. The restore is documentedThe ten parts cover restoring a single file from tar, restoring a single file from rsync, restoring a directory, restoring from a differential backup, restoring from incremental backups, a full system restore, a restore to a test location, a partial restore, the overwrite guard, and the verification checklist.
Quick Reference
The Restore Commands
| Task | tar | rsync |
|---|---|---|
| List contents | tar -tzf archive.tar.gz | ls /backup/ |
| Extract all | tar -xzf archive.tar.gz -C /dest/ | rsync -av /backup/ /dest/ |
| Extract one file | tar -xzf archive.tar.gz path -C /dest/ | rsync -av /backup/path /dest/ |
| Extract one directory | tar -xzf archive.tar.gz dir/ -C /dest/ | rsync -av /backup/dir/ /dest/ |
| Preserve permissions | -p | -a |
| Dry run | tar -tzf | rsync -avn |
| Overwrite guard | --keep-old-files | --ignore-existing |
The Restore Phases
| Phase | Purpose | Action |
|---|---|---|
| Identify | Decide what to restore | Assess the failure |
| Test | Verify the backup is usable | List or extract to /tmp |
| Restore | Replace the failed data | Run the extract/copy |
| Verify | Confirm the restore worked | Check files, services, logs |
The Overwrite Behaviors
| Option | Behavior |
|---|---|
| Default (tar) | Overwrite existing files |
--keep-old-files | Error on existing files |
--skip-old-files | Skip existing silently |
| Default (rsync) | Overwrite existing files |
--ignore-existing | Skip existing files |
The Restore Order for System Backups
| Order | Component | Reason |
|---|---|---|
| 1 | Bootloader | System must boot |
| 2 | /etc | Configuration |
| 3 | /home | User data |
| 4 | /var | Application state |
| 5 | Application directories | Custom paths |
Best Practices
✅ Do This:
# List the archive before extracting
tar -tzf /backup/full.tar.gz | head -20 # ✅# Extract to a test directory first
mkdir -p /tmp/restore-test
tar -xzf /backup/full.tar.gz -C /tmp/restore-test # ✅# Preserve permissions on system restores
sudo tar -xzpf /backup/full.tar.gz -C /mnt/restore # ✅# Use --dry-run before rsync --delete restore
rsync -avn --delete /backup/2025-05-07/ /home/user/ # ✅# Test the restore long before you need it
# Practice restoring to a test location every quarter. # ✅❌ Don’t Do This:
# Don't restore to / without testing first
tar -xzf /backup/full.tar.gz -C / # ❌ overwrites live system# Don't restore system files as a regular user
tar -xzf /backup/system.tar.gz -C / # ❌ wrong ownership# Don't use --delete without --dry-run
rsync -av --delete /backup/ /home/user/ # ❌ deletes newer files# Don't skip the listing step
tar -xzf /backup/full.tar.gz # ❌ extracts to cwd# Don't assume the backup is good because it exists
# A backup that has never been tested is not a backup. # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Wrong files restored | Archive path different from expected | List first with tar -tzf |
| Ownership wrong | Missing -p flag | Use sudo tar -xzpf |
| Extra directory level | Missing trailing slash on rsync | Add / to the source |
| Files overwritten unintentionally | No overwrite guard | Use --keep-old-files or --skip-old-files |
| Newer files deleted | --delete used without dry-run | Run with -n first |
| Restore fails mid-way | Corrupted archive | Verify with tar -tzf > /dev/null |
| System won’t boot after restore | Bootloader not restored | Reinstall grub in chroot |
Real-World Examples
1. Restore a Single File from tar
tar -xzf /backup/full.tar.gz etc/nginx/nginx.conf -C /tmp/restore2. Restore a Single File from rsync
rsync -av /backup/latest/home/user/file.txt /home/user/3. Restore an Entire Directory
tar -xzf /backup/full.tar.gz var/www/ -C /mnt/restore4. Restore from Differential
tar -xzf /backup/full.tar.gz -C /mnt/restore && tar -xzf /backup/diff.tar.gz -C /mnt/restore5. Restore from Incrementals
rsync -av /backup/full/ /mnt/restore/ && rsync -av /backup/inc-1/ /mnt/restore/6. Full System Restore
tar -xzpf /backup/full.tar.gz -C /mnt/restored-system7. Chroot for Bootloader
chroot /mnt/restored-system grub-install /dev/sda8. Test Restore
mkdir -p /tmp/restore-test && tar -xzf /backup/full.tar.gz -C /tmp/restore-test9. Dry Run Restore
rsync -avn /backup/latest/ /home/user/10. Verify Archive
tar -tzf /backup/full.tar.gz > /dev/null && echo "OK"Visual
The Restore Workflow
┌──────────────────────────────────────────────┐
│ RESTORE WORKFLOW │
│ │
│ 1. IDENTIFY │
│ └─ What failed? What needs restoring? │
│ │
│ 2. TEST │
│ └─ List the archive / browse the backup │
│ └─ Extract to /tmp/restore-test │
│ └─ Verify the contents │
│ │
│ 3. RESTORE │
│ └─ Extract to the target location │
│ └─ Use -p for permissions │
│ └─ Use --keep-old-files if partial │
│ │
│ 4. VERIFY │
│ └─ File count, ownership, permissions │
│ └─ Services start, logs clean │
│ └─ Document the restore │
│ │
└──────────────────────────────────────────────┘The Restore Chain for Each Backup Type
┌──────────────────────────────────────────────┐
│ FULL BACKUP │
│ │
│ archive.tar.gz ──> Restore ──> Done │
│ │
├──────────────────────────────────────────────┤
│ DIFFERENTIAL BACKUP │
│ │
│ full.tar.gz ──> Restore │
│ │ │
│ ▼ │
│ diff.tar.gz ──> Restore ──> Done │
│ │
├──────────────────────────────────────────────┤
│ INCREMENTAL BACKUP │
│ │
│ full.tar.gz ──> Restore │
│ │ │
│ ▼ │
│ inc-1.tar.gz ──> Restore │
│ │ │
│ ▼ │
│ inc-2.tar.gz ──> Restore │
│ │ │
│ ▼ │
│ inc-3.tar.gz ──> Restore ──> Done │
│ │
│ Every file must be present and uncorrupted. │
│ │
└──────────────────────────────────────────────┘The Test-First Discipline
┌──────────────────────────────────────────────┐
│ TEST FIRST │
│ │
│ ┌────────────────┐ │
│ │ Backup archive │ │
│ └────────┬───────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ /tmp/restore- │ ← Extract here first │
│ │ test │ │
│ └────────┬───────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Verify: │ │
│ │ • file count │ │
│ │ • ownership │ │
│ │ • content │ │
│ └────────┬───────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ │ │ │
│ ▼ ▼ │
│ GOOD BAD │
│ │ │ │
│ ▼ ▼ │
│ Restore Find another │
│ for real backup │
│ │
└──────────────────────────────────────────────┘The System Restore Order
┌──────────────────────────────────────────────┐
│ SYSTEM RESTORE ORDER │
│ │
│ 1. Boot from rescue media │
│ │
│ 2. Mount the failed disk │
│ │
│ 3. Restore the filesystem │
│ └─ tar -xzpf or rsync -av │
│ │
│ 4. Mount /dev, /proc, /sys │
│ │
│ 5. chroot into the restored system │
│ │
│ 6. Reinstall bootloader │
│ └─ grub-install /dev/sda │
│ │
│ 7. Exit chroot, unmount, reboot │
│ │
│ 8. Verify services and data │
│ │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Restore workflow | Identify, test, restore, verify |
| tar extract | tar -xzf archive.tar.gz -C /dest/ |
| tar preserve | -p for permissions |
| tar overwrite guard | --keep-old-files, --skip-old-files |
| rsync restore | rsync -av /backup/ /dest/ |
| rsync dry run | rsync -avn |
| rsync overwrite guard | --ignore-existing |
| Differential restore | full + most recent diff |
| Incremental restore | full + every incremental in order |
| System restore | Boot from rescue, mount, extract, chroot, grub |
| Verification | File count, ownership, permissions, services |
Key takeaways:
- A backup is not a backup until it has been restored. Testing the restore is the only way to know the backup is usable. The most common cause of restore failure is not a corrupted archive — it is an untested procedure .
- The restore workflow has four phases: identify, test, restore, verify. Skipping the test phase is the most dangerous shortcut. Extract to a temporary location and verify before overwriting live data.
tar -xzfextracts;-ppreserves permissions. For system restores,-pis mandatory. Without it, the restored files will have the wrong ownership, and services may fail to start.rsync -avrestores by reversing the backup. The source becomes the backup directory, and the destination becomes the location to restore to. The trailing slash determines whether the directory or its contents are restored.--deleteduring a restore is dangerous. It removes files from the destination that are not in the backup. If files were added after the backup was made, they will be lost. Always dry-run with-nfirst.- Differential restores need two files: the full and the most recent differential. Incremental restores need the full plus every incremental in order. Missing any file in the chain causes the restore to fail.
- Full system restores require booting from rescue media. The running system’s files cannot be replaced while it is running. The bootloader must be reinstalled in a chroot before rebooting.
- Verify after every restore. Check the file count, the ownership, the permissions, and the content. Start the affected services and check the logs. Document what was restored and when.
Remember: Restoring is the operation that justifies the backup. Every backup strategy exists to make a restore possible. The discipline is to test the restore before you need it — to extract the archive to a temporary location, verify the contents, and know that the procedure works. Use -p for system files. Use --dry-run before --delete. Restore incrementals in order. Boot from rescue media for full system restores. And when the real restore happens, you will already know what to do.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!