Keep a real recovery path
Use a row export when you need to share a result. Use a database backup when you need to restore the database after a failure or unwanted change. The files serve different purposes.
Choose the artifact you need#
| Goal | Appropriate workflow |
|---|---|
| Share a report | Export a bounded query result |
| Move a small structured fixture | CSV or Excel export and validated import |
| Recover a complete database | Use database-native backup and restore tools |
| Apply the same schema change elsewhere | Keep a reviewed migration in version control |
A complete recovery may need schema, constraints, routines, privileges, and engine-specific metadata as well as records. A CSV does not preserve all of these.
Follow your engine's procedure#
Use the official instructions for the database and deployment you run:
- PostgreSQL backup and restore
- MySQL backup and recovery
- MongoDB database tools
- SQLite backup API and tools
For a managed database, include the provider's backup retention and restoration procedure in your recovery plan. Choose the procedure based on the recovery you need rather than assuming one export command covers every failure.
Test the restoration#
Restore into a separate target. Follow the backup tool's verification procedure, then use WhoDB to inspect expected objects, counts, keys, and known records. Test the application against the restored target when application behavior is part of the recovery requirement.
Record the commands, required credentials, storage location, and validation checks with the backup configuration. A file that has never been restored leaves an important part of the recovery process untested.
Continue with Export options for report files or Migration validation for checking a planned transfer.
Was this page helpful?