Presslabs backup policy
Doing backups is a must these days. This is why we have a multi-layered backup policy, trying to minimize the data lost down to zero in case of any event.
Our backup policy is done on 3 different types of data:
1. Site code
By site code we mean all the files that stay in WordPress' wp-content folder except uploads and upgrades folders. This means all the theme and plugin files, together will all the files that are stored in the root folder of your site, e.g. example.com/abc.html.
All these files are stored on our Git servers stack and they're versioned after each time a file is modified, as Git commits. This makes it very easy to restore any change to any file using Git commands. A secondary way to roll-back to a previous version of the code is through our SFTP server which is powered by [gitfs] (https://www.presslabs.com/gitfs/) and has a very easy way to restore a previous version of your site's code. ve Currently the history of changes stored in the Git repo isn't limited in time or number of commits.
2. Static files
WordPress keeps its static files in the folder
/wp-content/uploads/. We're using ZFS to store these files, on a pair of storage servers, having paired hard disks using RAID, configured for automatic failover in case any of them fails. ZFS is taking automatic snapshots with the following rules:
- every 15 minutes for the last hour
- every hour for the past day
- every day for the past month
- every week for the past 2 months
- every month for the past 3 months
We also have a dedicated backup server for each cluster that syncs these snapshots on a daily basis. This server is physically located in a different data center from the cluster it backs up, to be safe in case a data center fail. On a nightly basis the backup server sends all the daily snapshots in an Amazon S3 bucket where they are stored for 21 days. We therefore have 4 levels of backups for this data:
- a pair of RAID disks on each storage server - in case a disk fails, the other takes over until the first is replaced.
- a pair of servers with automatic failover, synchronised every 5 seconds
- off-site dedicated backup server for each cluster
- Amazon S3 bucket for disaster recovery purposes
We're using a MySQL stack to store the database used by WordPress with a primary server and 1 or 2 replica servers, with RAID-paired hard drives and automatic failover between the servers. The external backup server mentioned above on the static files section is also configured as a MySQL replica server, in sync with the entire stack of its dedicated cluster. This server also takes nightly snapshots of all the MySQL databases and keeps them for 30 days. In the same time it sends them over to an Amazon S3 where they're kept for 21 days. The same 4 layers backup is present here as well.