Automatic Snapshot via Zapier Vs DigitalOcean Weekly Backups

@bluenotes

When it comes to backups, as a general rule of thumb, don’t keep all your eggs in one basket. That doesn’t mean that you shouldn’t use DigitalOcean, it does mean, however, that you should spread your backups out across multiple providers where and when possible.

The biggest issue, for me, is shutting down a Droplet, or any active instance. If you’re running anything that uses a database (i.e. WordPress), simply shutting down the Droplet could result in data corruption (in such cases where MySQL, MariaDB or Percona are not shutdown cleanly). In such a case, when the Droplet comes back online, you may need to repair tables. It’s not a huge issue on small databases, but on larger (starting from 100MB to 500MB in size), it can be a pain and it can take a little while (it’s also not something you want to do using a web interface, such as phpMyAdmin – this should always be done from the command line).

For database driven websites or applications, I’d recommend using a CRON job that fires off a request to a bash script that will, in turn, perform the database backup by first shutting down the service, copying the database information to a secure location on the Droplet, restarting the database service and then compressing the data to a file which is then sent offsite.

You could, of course, go for a slightly more complex setup and use replication with MySQL by setting up a small 2-Droplet cluster (Master/Slave). The master would accept both reads & writes while the slave would only allow reads to be performed (the master would push changes to the slave at the same time).

Using the same CRON job and script, you would still backup the Master, though temporarily switch over to using the IP/Hostname of the Slave so that access to your database(s) is never unavailable. The bash script could handle this rather easily.

i.e. The bash script would (after you’ve properly configured a MySQL Master/Slave setup):

1). Change the Database Host in each wp-config.php files to the Slave IP/Hostname, then;

2). Shutdown the Master Database Server, then;

3). Backup the MySQL Database directory, then;

4). Restart the Master Database Server, then;

5). Change the Database Host in each wp-config.php back to the Master IP/Hostname.

The end result is that once the database directory is backed up, the script switches back to the Master thus, there’s only a brief period of time in which writes would be restricted and best of all, there’s no actual downtime and visitors to these sites may continue to browse as normal.

You could even go a step further and write a conditional statement that checks the IP/Hostname that WordPress is using. If it’s localhost or the IP of your Master, no message is displayed. If it’s the IP/Hostname of the Slave, then a small message is displayed at the top of each site with details on why certain functionality is currently restricted.