A backup is not proven until the expected files exist at the remote destination. A “completed” message only confirms that the backup process reached its final step; it does not prove that every archive was uploaded.
The design decision
The safest backup report checks two separate results:
- Did the backup process finish successfully?
- Does remote storage contain the expected number of archives?
These checks answer different questions. The first measures the job. The second measures the outcome.
Why a success message can be misleading
A post-backup hook may run even when some uploads are missing. It can also inspect the wrong local directory after local copies have already been deleted.
Cause: The report trusts a process status or an empty local path.
Fix: Query the remote destination directly and compare what is there with what should be there.
A practical verification process
- Count expected backups. Start with the number of active accounts or items included in the job.
-
Handle intentional skips. Keep suspended or excluded accounts in a separate count instead of marking them as failures.
-
Inspect remote storage. Read the object count and total size from the destination used for that run.
-
Compare expected and actual results. Compare the expected archive identities as well as the count; an equal count alone does not prove completeness.
-
Record useful evidence. Include the run date, remote path, uploaded count, total size, and remaining local disk space.
Use clear backup states
A simple report is easier to trust when it uses distinct states:
- Completed: The job succeeded and all expected archives are present remotely.
-
Incomplete: The job ended, but fewer archives were uploaded than expected.
-
Failed: The backup process or remote-storage check returned an error.
-
Still running: The reporting window ended before the backup finished.
-
Skipped: An account was intentionally excluded, such as a suspended account.
Common mistakes
Using the wrong status variable: Read the documented success indicator supplied to the hook instead of assuming a generic error variable exists.
Checking only local files: If local archives are removed after upload, the remote destination must be the source of truth.
Treating skipped accounts as failures: Separate expected exclusions from actual missing backups.
Reporting raw sizes: Convert large values into readable units so unusual changes are easy to spot.
Sending success when verification fails: A remote query error should produce an unknown or failed state, never a green result.
File counts are only the first check
Compare a manifest of expected archive names, not only a total count: yesterday’s files or duplicate names can hide a missing backup. Check nonzero sizes and available checksums, then regularly restore a sample into an isolated environment. A complete-looking remote upload is evidence of delivery, not proof that the backup can be restored.
A reliable backup report verifies the destination, not just the process. The next action is simple: add an expected-versus-uploaded comparison to the post-backup check.