Recovering a Deleted /etc Directory on a VPS with Borg Snapshot Restore -

When a VPS loses its /etc directory, the system can become unbootable or at least unusable until the configuration files are restored. If you have been running Borg backups (the recommended tool for incremental, deduplicated snapshots) the recovery path is clear: locate the snapshot that contains the last good /etc, extract it, and replace the missing directory. This walkthrough shows the exact commands, trade‑offs, and security checks you should perform on a current 2026 VPS environment.

1. Verify the Damage

Before touching any data, confirm that /etc is indeed missing or corrupted.

ls -ld /etc
# or
stat /etc

If the directory is gone, the command will return “No such file or directory.” If it exists but is empty or incomplete, note which files are missing. A quick sanity check:

test -f /etc/passwd && echo "passwd present" || echo "passwd missing"

2. Prepare the Environment

Root access – You need sudo or root to replace /etc.
Borg repository – Ensure the backup repository is reachable. It might be on an external volume, a network share, or a cloud bucket.
Encryption – If your repo is encrypted, you’ll need the passphrase.
Read‑only mount – Mount the repo read‑only to avoid accidental writes during inspection.

sudo borg create --list --progress \
  /mnt/backup/repo::snapshot-{now:%Y%m%d%H%M%S} \
  /etc

(The above line is only for illustration; you should already have a repo.)

3. Locate the Latest Good Snapshot

Borg stores snapshots with a name you choose. Common patterns are snapshot-YYYYMMDDHHMMSS or daily-YYYYMMDD. Use borg list to see what’s available.

sudo borg list /mnt/backup/repo

Look for the most recent snapshot that predates the deletion. If you have a naming convention, you can filter:

sudo borg list /mnt/backup/repo | grep '^snapshot-' | tail -1

Tip: If you’re unsure which snapshot contains the correct /etc, you can inspect the contents of a snapshot without extracting it:

sudo borg list /mnt/backup/repo::snapshot-20260925T123456Z /etc

4. Inspect the Snapshot (Optional)

Before extracting, you might want to verify that the snapshot is intact. Borg can perform a quick integrity check:

sudo borg check /mnt/backup/repo::snapshot-20260925T123456Z --progress

If the check reports “All files are OK,” you can proceed. If it reports corruption, you may need to restore from an older snapshot or rebuild the repo.

5. Extract `/etc` Safely

There are two primary ways to bring back /etc:

Method	Command	Pros	Cons
`borg extract`	`sudo borg extract /mnt/backup/repo::snapshot-20260925T123456Z /etc`	Simple, preserves metadata	Overwrites existing files; no mount point
`borg mount`	`sudo borg mount /mnt/backup/repo::snapshot-20260925T123456Z /mnt/backup-mount`	Inspect files, copy selectively	Requires extra space, mount time

5.1 Using `borg extract`

sudo borg extract /mnt/backup/repo::snapshot-20260925T123456Z /etc

This command restores the entire /etc tree into the live system. Borg preserves file permissions, ownership, and timestamps. If /etc was partially present, Borg will overwrite only the missing parts.

Caution: If you have made configuration changes after the snapshot, those changes will be lost. Consider backing up the current /etc first:

sudo cp -a /etc /etc.bak-$(date +%Y%m%d%H%M%S)

5.2 Using `borg mount`

If you prefer to inspect the files before copying:

sudo borg mount /mnt/backup/repo::snapshot-20260925T123456Z /mnt/backup-mount

Now you can ls, cat, or diff against the live system. When ready:

sudo rsync -aAXv /mnt/backup-mount/etc/ /etc/

rsync preserves permissions, ownership, and SELinux contexts (-X), and the -A flag preserves ACLs. After copying, unmount:

sudo borg umount /mnt/backup-mount

6. Verify the Restored Files

After extraction, double‑check that critical files exist and have the correct attributes.

# Basic sanity
test -f /etc/passwd && echo "passwd OK" || echo "passwd missing"

# Permissions
stat -c "%n %U %G %a" /etc/passwd /etc/group

# SELinux context (if enabled)
sestatus && ls -Z /etc/passwd

If any files are missing or have wrong ownership, you can manually copy them from the backup or use rsync again with the --inplace flag.

7. Reload Systemd and Restart Services

Most services read their configuration at startup. After restoring /etc, reload systemd and restart affected units.

sudo systemctl daemon-reload
sudo systemctl restart sshd
sudo systemctl restart network

If you’re unsure which services rely on /etc, a quick check:

systemctl list-unit-files | grep enabled | grep -v disabled

For services that fail to start, inspect logs:

journalctl -u sshd -b

8. Post‑Restore Checks

Network – Verify that /etc/hosts, /etc/resolv.conf, and /etc/network/interfaces (or Netplan) are correct.
Users – Ensure /etc/passwd and /etc/group contain all expected accounts.
SSH – Test key‑based login.
Package Manager – Run apt update (Debian/Ubuntu) or dnf check-update (RHEL/CentOS) to confirm /etc/apt/sources.list or /etc/yum.repos.d are intact.

9. Harden the Backup Strategy

After the dust settles, double‑check that your backup schedule covers /etc. A single missing snapshot can leave you in a similar pickle.

Retention policy: Keep daily snapshots for at least a week and weekly snapshots for a month.
Test restores: Periodically pick a snapshot and restore to a test VM.
Off‑site copy: If your repo lives on the VPS itself, consider mirroring it to a remote server or cloud bucket.
Encryption: If you’re not already encrypting, add --encryption=repokey to your borg create command.

10. Final Thoughts

I’ve seen this go wrong when people assume the last backup is perfect and skip the integrity check. Borg’s check command is a cheap safety net that saves a lot of headaches. Also, never forget that /etc is the heart of the system; a single missing line can bring the whole stack down. Keep your backups up‑to‑date, test them, and you’ll be back up in no time.