"We exported something once" is not a recovery strategy. A backup is only useful if you know what's in it, where it lives, and how you'd actually restore it. Here's how to think about it before you start changing things.
Two kinds of backup
- •Code backup is your repository. Git handles this; make sure it's pushed.
- •Content and data backup is the stuff that lives in your app's database or file storage. This is the one people forget.
Reusable content vs. user activity
Separate reusable configuration and content (the things you'd rebuild from) from user-generated activity (the things you can't rebuild). Both matter, but they're backed up for different reasons.
Know your entities
Identify parent and child entities in your data model. If you export a parent without its children, you've backed up half a record. Understand the relationships before you export.
Exporting
- •Export reusable content in a format you can actually re-import.
- •Consider a recovery-only export of user activity if it's appropriate—and only if you can store it securely.
- •Protect private or regulated data. Don't copy production participant or customer data into development environments.
Naming and storage
- •Use clear file names: project, export type, date.
- •Add version notes for non-obvious exports.
- •Store backups somewhere secure and separate from the thing you're backing up. A backup on the same server as the app is not really a backup.
Validate, then test
- •Open the export and confirm it contains what you expected. An empty export is a common, silent failure.
- •Test whether the backup can actually be restored—not just that it exists. A restore you've never tried is a hypothesis.
Establish a recovery point
Before major work, create a known-good recovery point. If the change goes sideways, you know exactly where to return.
Takeaway
Backups are a verb. Know what, where, and how you'd restore—before you need to.