Replication and Data Backup Policy
This is a copy of our internal policy. We share it to help customers get a better understanding how how we work. The policy will get updated or improved from time to time. You’re welcome to give us feedback by sending a mail to email@example.com.
It’s crucial we keep backups of our core production data, so in the event of major failure (like a coding error that erases customer data from the database) we can roll back to a previous safe state.
- We take daily snapshots of all production data and store it on an independent system.
- We get notified in case a backup didn’t succeed
- We replay backups frequently in order to ensure they are still working
- We delete backups after 6 months
- Our Application runs in Google Cloud App Engine, the live database being in Google Data Store. Our backups are stored in the Google Cloud Storage service, which is entirely independent. Even if a coding error or App Engine related proble, led to our entire databse being wiped, we’d be able to recreate the database within hours.
- A daily notification mail sent to key employees when a backup has been taken, and in case anything in the process has failed the email states this very clearly in the subject line, and we’ll take immediate action to ensure the backup will work
- At least every 2 months we take a backup and replay it onto an empty server and ensure the process still works
- Backups are deleted after 6 months
- It’s important that we don’t have a single point of failure. All our production systems need to survive individual servers or even entire datacenters going down
- We run all of our crucial production systems in the Google Cloud. Most services have cross-datacenter replication built in by default (our database and production servers for instance). In the few cases where we have to build our own infrastructure like our Google-hosted Loadbalancers, or our Google-hosted PDF-generation-servers, we ensure that there is always enough replication in place for single servers or even datacenters to fail without jeopardizing the service itself.