I’ve been using Cloudflare R2
Keeping backups on the same server as the website isn’t particularly useful if that server suffers a serious failure. You might be able to recover from a bad plugin update, but you won’t have much luck if the entire server disappears.
I wanted the backups stored somewhere separate from the hosting environment, without having to build and maintain a separate backup server.
Cloudflare R2 is an object storage service with an S3-compatible API, which makes it useful for applications that already support Amazon S3.
Creating an R2 bucket
The first step is to create a bucket in Cloudflare R2.
A bucket is simply where the backup files will be stored.
I then create credentials with permission to access that bucket.
It’s worth restricting the credentials to the specific bucket where possible, rather than giving a backup plugin access to every bucket in the account.
R2 provides an S3-compatible endpoint that looks like this:
1https://<ACCOUNT_ID>.r2.cloudflarestorage.com
The account ID and access credentials are provided by Cloudflare.
Although the endpoint looks different from Amazon S3, a lot of software designed for S3 can use it without modification.
Configuring WordPress backups
For WordPress, I use BackWPup
The exact settings depend on the plugin version, but the important parts of the S3-compatible storage configuration are:
| Setting | Value |
|---|---|
| Endpoint | Your Cloudflare R2 S3 endpoint |
| Region | auto or the region value required by the plugin |
| Bucket | Your backup bucket |
| Access key | R2 access key ID |
| Secret key | R2 secret access key |
Older S3 integrations sometimes expect a conventional AWS region, such as us-east-1, and may also require path-style addressing.
R2 can work with those conventions, but I’d check the current plugin version rather than assuming all S3-compatible settings behave identically.
Once connected, the plugin can upload backup archives directly to the bucket.
What needs backing up?
A WordPress website is mainly made up of two things: its files and its database.
The database contains posts, pages, settings, users and other information managed through WordPress.
The files include themes, plugins and uploads, along with WordPress itself.
Both are important, but they don’t necessarily need the same backup strategy.
For example, a website with several years of uploaded images might have a relatively small database but many gigabytes of media.
Repeatedly backing up every image can use unnecessary storage and bandwidth.
For larger sites, it can make sense to separate database backups from media backups, or use incremental backups where the tooling supports them.
Scheduling and retention
I schedule backups to run automatically, usually during a quieter period for the website.
I also configure retention so the storage bucket doesn’t keep every backup indefinitely.
For example, keeping thirty daily restore points gives some flexibility when discovering that an issue started several days ago. The right retention policy depends on the website.
Testing the backups
A backup job reporting success doesn’t necessarily mean the website can be restored.
It’s worth periodically downloading an archive and checking that it contains the expected files and database.
Ideally, I’d restore the backup into a separate environment to verify that the website actually works.
There isn’t much value in discovering that your backups are incomplete at the exact moment you need them.
Why R2?
The main advantage is that R2 can be used through the familiar S3 API.
I don’t need anything particularly complicated on the WordPress server. The backup plugin creates an archive and uploads it to external object storage.
Cloudflare R2 also doesn’t charge egress bandwidth fees in the same way as some object storage services, although storage and operation charges still apply.
For me, the important thing is having an automated, off-site backup process that doesn’t depend on the WordPress server remaining available.