Presslabs backup policy
Doing backups is a must these days. This is why here at Presslabs we have a multi-layered backup policy, trying to minimise data loss down to zero in case of any event.
We're using z3 to manage the backups on our platform, a tool written in Python which we open-sourced.
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
upgrades folders. This means all the
plugin files, together will all the files that are stored in the root folder of your site, e.g.
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.
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
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 Datacenter from the cluster it backs up, to be safe in case a Datacenter 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.
How can I have a backup of my site?
In case you want a backup of your site's code (
plugins, etc.), you have to clone your site's
or access the
Gitea web app
In case you need a backup of your database, or your static files (WordPress uploads) — you can request one from the
, from the tab
Sites -> Snapshots.
This section is dedicated to CDN related topics. We have built our own Content Delivery Network, [...]
Collecting data when an ad blocker is enabled
There's always a smarter way to get to the destination. Here's the automated way of collecting [...]
Here you can find details about DNS management and how the DNS failover works. We also use Amazon [...]
Here's our specs wardrobe—how WordPress site files organized at Presslabs, e.g. themes, plugins, [...]