Knowledge base
Backup and recovery responsibility
What Propulsive handles for backups, what the customer owns, and how to think about restore readiness.
- Audience
- Administrators, Implementation partners
- Permissions needed
- Platform administration
- Environment
- Production and staging
- Product version
- Current
- Last reviewed
- Owner
- Propulsive Product Team
Before you start
- A backup you cannot restore is not a backup - verify restore drills on a schedule.
Backups and recovery responsibility split along the same line as support generally: the platform operator runs and monitors the infrastructure, and the customer owns the decisions made from the data it contains.
What the platform provides
- Database backups are part of the operating process on managed deployments.
- Schema migrations are reversible - every migration declares its own rollback, so a failed release can be reverted step by step rather than restored wholesale.
- Release evidence records what version ran where, so a restore or rollback can be verified against a manifest rather than guessed.
What the customer owns
- Your data, and the decisions made from it, remain your responsibility - including keeping your own exports and records of anything the platform’s backup cycle does not cover.
- Exporting the data you need is always available through the data export and privacy flows - see Data export & privacy.
- Recovery expectations are agreed per contract - we do not promise a specific restore SLA we have not independently rehearsed on a schedule.
The restore-rehearsal question
We are honest about the boundary here: regular backups are in place, but an independently rehearsed, repeatable restore drill on a fixed schedule is where our operational maturity is still catching up - see the Deployment page for the current status. Until that is mature, treat a restore as something to test, not something to assume.
Recommended hygiene
- Export critical data periodically, independently of the platform’s own backups.
- Before any major migration or release, confirm you could rebuild the environment from migrations plus seed data plus your exports - that is the three-part restore story: schema, seed, and your data.
- If you operate your own deployment, run the backup and restore tooling yourself and rehearse it; do not discover a broken restore at the moment you need it.