Post‑Restore Integrity Verification in Spatie Laravel Backup

Question

Post‑Restore Integrity Verification in Spatie Laravel Backup

The package’s php artisan backup:restore command restores the latest or a specified archive, writing data to the configured disk and database. It does not automatically verify that the restored files or database rows match the original backup.

When restoring a production snapshot, the absence of an integrity check means that corruption, partial writes, or accidental mis‑configuration could go unnoticed until a later failure. The design team is debating whether to embed a verification step, such as checksum comparison or a test suite run, and how to surface failures to the operator.

Unresolved questions include:

Should the restore command perform automatic checksums against the backup archive after writing files and data?
What should be the fallback behavior if a verification mismatch occurs—abort, retry, or log and continue?
Can a custom hook be added to trigger application‑level tests post‑restore, and how would that affect deployment pipelines?

Siddharth · Answer

Answer to the Core Question
When you run php artisan backup:restore, the command simply unpacks the chosen archive to the configured disk and imports the database dump. It does not perform any checksum comparison or application‑level test after the restore completes. The package therefore offers no built‑in fallback policy for mismatches, nor a documented hook that runs automatically after the restore finishes.
Confirmed Facts (Spatie Laravel Backup 5.x)

The RestoreCommand extracts the archive and runs the database import; no post‑restore verification logic is present.
Exceptions are thrown only for extraction or import errors; otherwise the command exits with a success status.
There is no event or interface exposed by the package that signals “restore finished” for external listeners.

Likely Considerations for Adding Verification

Checksum comparison can be implemented by calculating hashes of the restored files and comparing them to the hashes stored in the backup manifest (if you keep one).
Database integrity checks usually require application‑specific queries—row counts, checksums of key columns, or a lightweight functional test—because a raw file checksum of a dump does not guarantee data consistency.
Choosing a fallback—abort, retry, or log-and‑continue—depends on your operational tolerance. A hard abort can block a production recovery if the mismatch is a benign difference (e.g., auto‑increment IDs or timestamps).

Practical Steps for Your Current Set‑Up

Wrap the restore command. Create a small Artisan command that calls backup:restore via $this->call('backup:restore', …), then runs your own verification logic.
Implement a verification routine. For files, read the manifest.json (if you keep one) or compute hashes of key directories. For the database, run a set of sanity checks such as SELECT COUNT(*) FROM users and compare to a known baseline.
Decide on failure handling. If a mismatch is detected, you can throw an exception to abort the whole process, or simply log the issue and proceed—document the chosen policy in your recovery playbook.
Integrate with CI/CD. If you run restores as part of a deployment pipeline, add the verification routine as a post‑deploy job that can gate the promotion of the new environment.

Missing Diagnostic Detail
To tailor the recommendation precisely, could you let me know which major version of spatie/laravel-backup and which Laravel version you are using?

Post‑Restore Integrity Verification in Spatie Laravel Backup