It is vital to have some level of data protection for your WordPress site, but there are several different approaches to data protection and not every site needs the same type of service. In this blog we will go over the four main levels of WordPress data protection, including a few things that might surprise you.
- Local site snapshots: Local snapshots are a “backup” of a WordPress taken (manually or automated) by the hosting service. They are a point in time snapshots of the final and database data and can be used to restore a site in the event of a problem. While local snapshots serve a purpose, and are better than nothing, they are practically useless for data protection beyond that hosting provider. As we explained in our 10 reasons why you need a disaster recovery (DR) service for your WordPress site blog there are many reasons why you could get caught out by not protecting your WordPress data “off-cloud”, or away from the primary hosting environment. A hosting provider’s backups should always be also offsite and WPQuasar’s are located in offsite object storage.
- Data backups with sovereignty (off-cloud Backup-as-a-Service): An off-cloud data backup is a big step forward from local snapshots and gives you immediate sovereignty over your data and usually consists of a full site and database backup to another cloud. This can be achieved with a download of your backups to a local client, or a cloud-to-cloud Backup-as-a-Service (BaaS). For most business cases, you will need cloud-to-cloud BaaS because it can be automated and paves the way for faster recovery. At WPQuasar we enable off-cloud BaaS to most cloud storage services, including Google Drive.
- A running snapshot: This is where a replica of the WordPress site data and database is transferred to another data centre or cloud and its sits idle until a decision is made to cut over to it in the event of a problem with the main site. A running snapshot is a browse-able snapshot of the site but not including the database. Think of it as read only – you keep your web presence, but can’t take orders or signups. Any server-side plugin functionality won’t work. This functions as DR-as-a-Service (DRaaS) albeit with an expected longer recovery time. Generally speaking, any business can recover from a period of downtime (even extended downtime), but is very unlikely to recover in the event of a total loss of data.
- Dynamic site failover: This is where the primary and DR instance of WordPress are in more of an active-active state and each component is in sync in a close to real-time as possible. This is also DRaaS but with higher expectations of recovery times. This is a lot easier to do with a ‘warm’ spare rather than a hot spare. In this scenario, both instances would point to the same HA database, but the second instance would be disabled until the primary disappears.
Active-active is not possible with WordPress; however, you can have a secondary instance with its own point-in-time snapshot of the database up and running but this has the following caveats:
- You rollback to the state of the last snapshot (lost orders etc) as syncing the database regularly creates load/traffic
- When you switch back to the primary you again lose data so you probably want to reverse the sync to grab the changes that happened on the secondary.
There are not a lot of benefits of truly hot spare given the caveats – it only takes seconds (at worst) to bring the ‘warm’ instance up to being a hot instance.
As you can see there are degrees of WordPress data protection, and the best approach really depends on the business case for the site. If it is a personal blog you might be happy with a download of a snapshot once a month, but if you’re running a high-value e-commerce site then you will want to see it running as close to 24x7x365 as possible.
Data protection by WordPress component
WordPress was originally developed on the tried and battle tested LAMP (Linux Apache MYSQL PHP) stack which consists of a number of components with different ways to protect the data. In addition to WordPress itself, network services come into play for off-cloud backups and DR. In short, WordPress can be “architectured” for maximum resilience.
- Linux system: This is where the applications and files live. The Web server, PHP, media files, and database are run on Linux, but they can be separated out to run on different servers reducing the exposure to a single system. Servers can be clustered, files can be synchronized, and databases can be replicated to achieve full data protection.
- Database: The MySQL or MariaDB can be clustered and replicated separately from the files. This is useful with DR as it one less component to cut over or restore in the event of a problem.
- DNS and network services: In order to cut over to a secondary site you need to tell the Internet’s telephone book (DNS) where the new site is hosted so regular visitors won’t notice any change. In the event of a disaster someone needs to decide on whether a cut over to a DRaaS is warranted. This is because a simple “outage” needs to be assessed to determine if it is only temporary or actually a real problem. A once-off network outage or system update might not be enough to trigger a DR plan for your site.
Remember, there is no such thing as 100% uptime and even the biggest cloud sites have all experienced some form of outage. The most important thing is to ensure your WordPress data is protected at multiple levels.
Effective DRaaS that doesn’t cost the Earth
Is there a solid middle ground to all this data protection that doesn’t require teams of people on standby all around this planet? The good news is yes, there is.
At WPQuasar we can help you get a good level of data protection with the option to easily cut over to a DRaaS setup. This involves:
- A clustered HA database.
- File sync to a server in a different data center, with monitoring.
- Lock out the primary site to avoid any consistency issues in WordPress. This would need to be addressed during discovery and it would be done with whatever access control is available at the database host.
- Provide an SSH key for access and a script to bring up the DR site so that you can cut over in the event of a disaster
- Provide instructions to update your DNS, or do this with a script via an API (depending on the DNS provider)
- For HTTPS, we synchronize the TLS certificate to the backup instance which would depend on how the primary instance is configured. It is not a problem if WPQuasar is also providing the primary hosting, because we can do a system-level sync of either a Let’s Encrypt or commercial certificate. Otherwise, we plan the best approach during discovery. An alternative to this is to use a hosted proxy in front of the sites to do the TLS.
With everything setup, DRaaS is ready swing into action when a decision is made to cut over.
Cutting back to the primary would be a hands-on process, and the sync direction and the lockout need to be reversed. Note, this setup describes disaster recovery, not simple load balancing.
Other options
There are also other site resiliency options, such as static page generators, which might be a viable solution for a read-only static DR site. This can avoid consistency issues and enable the ability to potentially automate the cut over, but it would still need automation discovery for the environment, and an approach to sync TLS (or offload it).
And, of course, DR means not having any single point of failure or exposure. So, using a commercial service to serve static pages does not mitigate an account problem or dispute with that service provider.
Backups, DR and data protection all go hand-in-hand so the question is really about what is right for your site, not trying to cover everything.
