The job finished. The recovery is still untested.
Imagine a nightly backup that reports success. Later, you need to rebuild the site. The uploaded images are there, but the database is missing. The copy worked; the recovery cannot.
A successful Linux backup job tells you that its configured operation completed without a reported failure. It does not, by itself, prove that you saved everything the application needs or that you can restore it. That takes a recovery test.
“Completed” answers a smaller question
A backup tool can copy exactly the directories you selected and still leave out the data you need. It cannot infer that your WordPress installation also depends on a database, an external upload bucket, or a secret stored elsewhere.
Read the result in layers. Each check adds evidence, but each answers a different question.
Did the configured operation report success? Read its warnings and confirm which paths it covered.
Can you read it, and does the tool’s integrity check pass? Inspect whether the expected content is present.
Can you restore into a separate location and use the recovered files or application?
An archive listing checks names. A checksum checks bytes against a reference. Neither, alone, proves an application will start.
Back up what you need to rebuild
Start with one question: if this VPS disappeared, what could you download again, and what would be gone? Packages may be easy to reinstall. Customer uploads, database records, local configuration and private keys usually need a deliberate recovery plan.
| Keep track of | Examples | Check before relying on the copy |
|---|---|---|
| Application data | Uploads, documents, locally stored content | Find the actual storage paths, including mounted or external storage. |
| Databases | Posts, accounts, orders, application state | Use a database-supported backup method and test its restore procedure. |
| Configuration | Web server settings, service units, environment files | Include local changes and record required software versions. |
| Recovery access | Decryption keys, backup credentials, account recovery methods | Keep protected recovery access available independently of the failed server. |
| Rebuild instructions | Package list, deployment steps, permissions, DNS changes | Record the order of operations and how to confirm the application works. |
You do not need to archive every Linux path indiscriminately.
Directories such as /proc and /sys expose
runtime kernel information; they are not ordinary application data.
Caches may be rebuildable. Logs may still matter for operations or
incident investigation. Choose deliberately.
Five ways a successful copy can fail you
-
The right files were never selected
A new application writes uploads to a different directory, but the backup still covers the old one. Compare the backup inventory with the running application after storage or deployment changes.
-
The files changed while being copied
A live database is not a static folder. Copying its files one by one can capture incompatible moments in time. Use the database’s documented export, physical backup or coordinated snapshot procedure. PostgreSQL documents specific requirements for filesystem-level backups; an ordinary copy of its running data directory is not enough.
-
The original and copy shared the same failure
An archive in
/backupson the same disk may help recover an accidentally deleted file. It will not survive the loss of that disk. An attached backup location may also be reachable by an attacker who controls the server. -
The usable version was already gone
A single overwritten copy can replace good data with a newer, damaged version. Keep recovery points long enough to cover the delay between a mistake and its discovery. Check the actual retention policy rather than assuming “daily” means “historical.”
-
The data returned, but the application did not
Wrong ownership, missing permissions, an unavailable decryption key or an incompatible database version can block recovery. A restore test should include the environment and access the application needs, not just successful extraction.
A second location needs a second look
Store a recovery copy outside the server you are protecting. Then ask what can delete it. A separate bucket with the same broadly privileged credentials may still share the same compromise risk. Offline copies or correctly configured immutable retention can protect against some deletion and ransomware scenarios.
Encryption protects backup confidentiality, but recovery also needs access to the key. Keep that access protected and available if the original machine or account is lost. CISA recommends offline, encrypted backups and regular recovery testing.
Two useful limits make the plan concrete. Open either term for an example.
RPO · How much data can you lose?
Recovery point objective is your tolerable data-loss window. If you can lose at most one hour of orders, a nightly backup alone does not meet that target. Actual recoverability depends on the most recent usable recovery point.
RTO · How long can recovery take?
Recovery time objective is your target time to restore service after disruption. Include finding the backup, downloading it, rebuilding dependencies, restoring data and checking the application. Measure a rehearsal against that target.
Restore somewhere you can inspect safely
For an ordinary file backup, start with a new, empty test directory. For a database or complete application, use an isolated test environment. Keep it away from production writes, scheduled jobs, email delivery and payment integrations.
Choose a recent recovery point and run the documented restore procedure. For this first lesson, the useful result is a written test plan. The next lessons will use a small directory of training files.
Use these boxes as reading notes. They are not saved, and checking them does not verify a backup.
Compare restored files with a trusted reference from the backup’s point in time. A current production file may have changed legitimately since then. A matching checksum can confirm matching file contents; it does not validate ownership, permissions or application behavior.
Repeat the rehearsal after meaningful changes to storage, credentials, encryption or software versions, and on a schedule that fits the importance of the data. Keep a short record: what you restored, where, how long it took and what failed.
Create a copy you can inspect.
In Lesson 02, create and check your first Linux backup using a small training directory. Then follow Lesson 03 to restore the archive and compare the recovered files. Live databases and full-server recovery need their own procedures.
Already scheduling jobs? The systemd timer tutorial explains how to check that a scheduled task ran. A restore rehearsal checks whether its backup output is useful.
