Ubuntu VPS Backup and Restore: A Static-Site Recovery Drill
A backup becomes useful when you can retrieve it outside the VPS and recover the expected files. This Ubuntu VPS backup and restore exercise archives a static page and one Nginx configuration, copies them to another computer and verifies the restored bytes without touching a running website.
In this guide
Define the small recovery exercise
Use Bash, GNU tar, sha256sum and OpenSSH on Ubuntu or a Linux/WSL client. Run server-labelled commands in one server terminal and client-labelled commands in one terminal on a separate computer. Keep each terminal open so its variables remain available. Stop after any command error.
The exercise uses two disposable files under your home directory. It does not change Nginx, firewall rules or live content, and extraction never runs as root. Start with the fixtures below; the optional substitution uses only the two files from the static HTTPS deployment walkthrough.
For a larger site, inventory its assets, redirects, included configuration, DNS records and dependencies separately. This two-file example is not a complete machine or application backup.
Prepare two files without changing the website
On the server, create a private practice directory. The configuration below is a file to archive, not a service configuration to activate.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"Optional: to back up the tutorial's real page and server block instead, replace only these disposable copies using the commands below. Both source files must be readable by your account. Inspect the configuration for secrets first, and pause deployments while collecting the files so they represent the same release. Skip this block for the fixture exercise.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"These commands read the live sources without modifying them. They do not copy certificate private keys or entire system directories. A real site may need additional files; add them deliberately to both the inventory and checksum manifest.
Create the archive and two levels of checksums
On the server, record checksums of the selected files, create an archive with relative paths, then checksum the archive. Keep the payload unchanged during this step.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"The listing should contain site/, nginx/, the two selected files and SHA256SUMS. The archive checksum detects changes to the transferred archive; the internal manifest checks the extracted files. Neither checksum authenticates a backup if someone can replace both data and the expected checksum.
Copy the backup to a separate computer
On your client computer, set remote_backup to the exact export directory printed by the server. Replace the sample address, account and key filename with your working SSH details. The address 203.0.113.10 is reserved for documentation; REPLACE is a placeholder, not the directory suffix generated by mktemp.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "[email protected]:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "[email protected]:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Verify the SSH host fingerprint through a trusted channel before accepting a new host. If copying fails because SSH fails, use the SSH troubleshooting guide. Do not disable host-key checking to make the transfer succeed.
SCP protects the transfer through SSH. The tar.gz file itself is compressed, not encrypted: protect the destination account and storage, and use encryption at rest when the data requires it. A second directory on the same VPS does not provide an off-server copy.
Verify and restore into a new empty directory
On the client, check the archive before extracting it. Continue only when sha256sum reports OK. A failure needs investigation or a fresh transfer; do not overwrite the expected checksum to conceal it.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Extract this trusted archive into a newly created directory. Keep-old-files refuses to replace existing files, while no-same-owner avoids restoring archived ownership. Never change the destination to / or extract with sudo.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"Expect OK for both site/index.html and nginx/first-site.conf and the recovered page heading. This verifies file contents, not production ownership, ACLs, service availability or every dependency of the website.
Separate file recovery from service recovery
The restored configuration is still an inactive text file. Before using it, review paths, includes, modules, permissions and certificates on a separate replacement server. Validate the assembled Nginx configuration there before reloading, then check HTTP/HTTPS externally. A syntax check of an unchanged live server does not validate this restored copy.
This archive deliberately excludes TLS private keys. Plan certificate reissuance or a separately protected certificate backup. Do not copy active database files with this tar recipe: use the database's supported consistent backup and restore procedure.
Provider snapshots can help with machine recovery, but check their retention, failure domain and restore procedure. A snapshot's existence does not demonstrate that your exported site files can be recovered on a replacement host.
Record recovery objectives and the result
RPO describes acceptable data loss measured in time; RTO describes the target time to restore the service. For a small static information site, you might choose a 24-hour RPO and a 60-minute RTO. These are illustrative business targets, not measured results from this exercise. Daily backups meet the intended schedule only when copies succeed and remain recoverable.
Scroll sideways to see the full table
| Record | What it demonstrates |
|---|---|
| Backup time and release identifier | Which version you can recover |
| Independent destination and retention | Where the copy survives and how long it remains |
| Archive and file checksum results | Whether the selected bytes were recovered |
| Restore start and finish times | Time spent on the defined recovery steps |
| Missing files, permissions or dependencies | Work still needed before service recovery |
| External HTTPS verification on the replacement | Whether the website actually returned |
Time the full replacement process before treating an RTO as achievable, including access, provisioning, configuration, certificates and DNS where needed. A fast local extraction is not an outage-recovery benchmark. Keep several suitable restore points and check failed backup jobs. Compare storage retention and restore support in the hosting recovery criteria.
Questions and answers
Can I remove the original website to prove the backup works?
You do not need to delete it. Restoring into a separate empty directory and checking the manifest tests the file copy without creating an outage. Test the complete service on a separate replacement environment.
Does a successful checksum mean the whole website is backed up?
It confirms the files listed in this manifest. It cannot discover an omitted asset, database, secret or DNS setting. Maintain an inventory and exercise the website's actual functions after service restoration.