How we manage database backups

We regularly get asked for information about how BulkMail takes backups so we thought it was about time we put together a handy digestible summary to explain exactly how we’ve got things setup!

Overview

Each instance of our solution has it’s own dedicated database which resides on a primary server within our database cluster.

For every primary server there are two secondary servers, both of which are essentially inactive, running only a few seconds behind making a copy of all databases just in case anything goes wrong.

We take full database backups multiple times every day, just in case something unexpected happens to all of the primary and slave servers.

Most system problems aren’t even noticed by anyone outside of our technical team because of the resilience of our database technology setup.

Multiple layers of backup mean that in the event of catastrophic hardware failure we should always be able to restore as much data as possible.

We’re continually monitoring and evaluating the way we manage our backups to ensure there are multiple layers of protection for our clients’ data.

We do not use the Cloud for data storage, only for storing image assets.

Real-time replication

The secondary database servers take copies in as near to real-time as possible, typically the process is running a few seconds behind. The short delay is simply because of the sheer volume of data that needs to be read and written.

Secondary database servers contain multiple storage drives and are configured in such a way that if any drive fails the server continues to function without fault and no data is lost.

Regular backups

Daily database backups are taken and stored within a separate data centre.

Our regular database snapshots process means that we always have backups for the last 7 days available plus weekly backups for each of the 3 weeks prior to those 7 days.