1. Roll back a release
- Websites: go back to an earlier published version (see Publish your website).
- Containers: every deploy is a revision. Click Roll back to this on the Revisions tab.
- Static Web: the 5 newest releases are kept. Click Use this release.
2. Scheduled backups on every database
Back up every 6 or 12 hours for data that changes all day, such as orders, and daily or weekly for data that rarely changes. Keep enough to go back as far as you would need, for example 14 daily backups for two weeks. Storage is billed by the size kept, so don’t keep more than you need.
3. Back up by hand before any big change
Before a migration, a large import or an upgrade, click Back up now on the Backups tab. Backups you make are kept for 90 days, then deleted. You’re warned by email and in the bell 7 days before, and Extend 90 days is free as often as you like (storage is still billed by size).
A database’s backups are deleted together with the database, and a project whose wallet stays empty has its services stopped after 72 hours (24 hours for new accounts) and deleted after 30 days, backups included. Never delete a database you may still need to restore, and keep production’s wallet topped up.
Keep a copy of your own, and practise restoring
Every few months, take a dump of production with pg_dump or mysqldump, import it into a database in your testing project on the Import tab, and check that your app runs on it. You find out the backup works, and you have a copy outside the platform.
Production databases: a standby and point-in-time recovery
- Turn on High availability: a standby in another zone takes over on its own if the primary stops responding, with the same name, IP and password. Turn on Synchronous replication for data you can’t afford to lose a second of, such as payments.
- Turn on Point-in-time recovery so you can restore to the second before a mistake, such as a
DELETEwithoutWHERE, into a new database. - Turn on Grow storage automatically so a full disk never stops the database, and set a Maintenance window outside your busy hours.
See High availability, point-in-time recovery and upgrades.
Read replicas and logs
- For a database many people read, add a replica on the Read replicas tab and point reports at it, so they don’t slow down the main database. If the main database has a serious problem, you can promote the replica.
- The Logs tab keeps only about the last 16 MB per service, and a new deploy starts a fresh log. If you need logs for longer, have your app send them to a system of your own.