Skip to main content

Backups & recovery

AppHaven is built durability-first: the platform assumes that something (a bad migration, an overeager script, a hardware fault) will eventually go wrong, and treats getting your data back as a core feature. Your production deployment is backed up automatically, with no schedule to wire up. The one choice you make is how long restore points are kept.

What is protected​

Two layers run side by side:

Nightly snapshots: everything, consistently. Every night, all of a deployment's persistent data, both its volumes and its managed database storage, is captured in a single atomic snapshot. Atomic means the volumes and the database are captured at the same instant, so a restored snapshot is internally consistent: no database that's newer than the files it refers to.

Continuous database capture: every change, as it happens. For the managed database, AppHaven additionally records its change stream continuously. This is what makes point-in-time recovery possible: the database can be restored not just to last night, but to a chosen moment, such as one minute before a bad migration ran.

The change stream is deliberately stored outside your app's environment, separate from the database itself. A bug that mangles the database, a compromised app, or a deploy gone wrong cannot reach back and damage the record needed to undo it.

Choosing how long backups are kept​

Open your app's Backups section in the console to set the retention window: how far back your restore points reach. You can keep 7, 14, or 30 days. A longer window gives you more room to recover from a problem you only notice later, and uses more of your storage budget for history. New apps start at 7 days.

The same Backups section lists your current restore points and shows the point-in-time window you can recover to, so you can see at a glance what is protected.

What you can recover, and to when​

WhatRecoverable to
Managed databaseA point in time of your choosing, or a nightly snapshot
Persistent volume filesThe most recent nightly snapshot
Application codeAny commit; your Git history is the backup, and every deployment records the commit it shipped
ConfigurationCurrent manifest in your repository; current Variables & Secrets in the console

Restoring​

To restore, contact AppHaven support with the app, the deployment, and the moment you need. "The database as it was yesterday at 14:05" is exactly the right shape of request. For a database, AppHaven restores to the nearest snapshot and replays the change stream forward to your target time; for volumes, it restores the nightly snapshot.

Because every deployment records its commit, pairing a data restore with a code rollback is straightforward: restore the database to just before the bad deploy, revert the branch to the prior commit, and deploy.

How backups relate to your storage size​

Snapshots and the database change history live inside your deployment's storage size: the single number you pick covers your live data and the history kept to protect it. A longer retention window keeps more history, so it uses more of that budget. The deployment page shows how much of the budget is in use.

Scope: your production deployment​

Backups protect your production deployment, the one running your production branch. Preview deployments are disposable: each is rebuilt from its branch every time you deploy, so they carry no separate backups, and nothing you try on a branch can consume or contaminate your production history.

Two lifecycle rules follow from data belonging to the deployment:

  • Stopping a deployment keeps its data and backups. Deploy again and everything is still there.
  • Deleting a deployment removes its data and backups. Delete is the one operation that lets go of your data. If you might want it later, stop instead, or take an export first (Application portability covers how).

Where to go next​