Canvas Database Backup Policy

[nara-falconeer]

What is the backup policy for prod deployments? From what I can tell from the outside, it looks like each customer's env is deployed in separate containers or servers. I'm not sure if the DB is a single large instance or in each customer's env. Either way, is the DB being backed up on a regular basis? If so, how frequent? Is this only to prevent disasters at the Canvas level, or if we as customers run a big job that, for some reason, screws up our env, is it possible to restore from one of these DB snapshots? I realize that restoring the DB might have issues from a compliance perspective, as we will lose patient logs since the snapshot, but for genuine disasters, is there a way out? The reason we ask is this. We have a sister system that pairs with Canvas that implements a lot of specific functionality, and we would like its backups to synchronize with Canvas's, as they rely on each other a lot.

[beaugunderson]

Hi Nara,

Each customer gets a dedicated Postgres database in an isolated environment, so backups are scoped to your data only.

Snapshots happen automatically every 24 hours. For your environment we retain 14 daily, 12 monthly, and 6 yearly, plus a final snapshot if you were to deprovision.

Continuous WAL archiving is enabled, so we can restore to a specific timestamp (point-in-time recovery, PITR) rather than only snapshot boundaries. Current window for PITR is the last 24 hours.

Restores are non-destructive, they spin up a new database alongside the live one, so a "we ran a bad job" scenario is fully recoverable (with the audit-log-gap tradeoff you flagged, which we'd walk through at restore time).

For your sister system: can you tell us your target RPO and whether it can restore to a specific timestamp? If yes, we could align a paired restore via PITR; if it's dump-based, we'd align to the nearest snapshot.

[nara-falconeer]

Thanks. I'll reach out to support separately on this.