Cloudways backups: how to set them up and restore a site

Every Cloudways server takes an off-site backup of all its applications once a day, between 1 and 5 am UTC, and keeps it for one week, with no set-up needed. You can change the frequency from hourly to weekly, keep backups for up to four weeks, take extra backups on demand, and restore any single application to an earlier point from the dashboard. Storage costs $0.033 per GB per month.

The defaults are reasonable, but not right for every site. This guide explains how the system works, which settings to change, how to restore, and the gaps you should cover yourself.

What Cloudways backs up, and how

Backups are taken at server level: one scheduled run covers every application on the server. For each application, the backup includes the public_html folder (the website files), the private_html folder, and the application's database. Other files in the application's home directory are not included, so if a plugin or script writes important files elsewhere, move them into private_html.

The first backup is a full copy. After that, file backups are incremental, saving only what changed, while the database is backed up in full every time because it is a single file. With the default daily schedule and one-week retention, that works out as two full copies and six incrementals at any time. Backups are created on the server and then exported off-site, which uses some disk space temporarily while they transfer.

What is not in any backup: your email (Cloudways does not host it), your DNS records, and settings for add-ons such as Cloudflare Enterprise. Keep a note of those separately.

Change the schedule to suit the site

Open the server, then Backups under Server Management. Three settings matter:

• Frequency, from every hour to every seven days. A brochure site that changes monthly is fine with daily. A busy shop or a site with constant user content should use something shorter, such as every 6 or 12 hours.
• Retention, from one to four weeks. One week is too short for most businesses: problems like a hacked file or a broken plugin are often noticed later than that. Two weeks is a sensible minimum.
• Schedule time, in UTC, available when the frequency is a day or longer. Pick a time when your visitors are asleep.

Cloudways warns that on servers with more than 100 GB of data, frequencies below 12 hours can cause one backup to start before the last one finished, and some will be skipped or fail. Large servers should use 12 hours or longer. There is also a Local Backups option, which keeps the latest copy on the server's own disk for faster access, at the cost of that disk space.

Suggested settings by type of site

Frequency and retention are set per server, so a store sharing a server with brochure sites drags everyone onto its schedule. That is one more reason to give a busy shop its own server.

What backups cost

Off-site backup storage is $0.033 per GB per month for each server. A small site with 10 GB of stored backups costs about 33 cents. An agency server keeping four weeks of hourly backups for twenty sites can reach several dollars a month. The bill grows with retention and with how much your files change, since every change adds to the incremental copies. Our pricing guide shows backups alongside the other line items.

Take a backup before you change anything

Before a plugin update, a theme change, a WooCommerce upgrade or a staging push, take an on-demand backup from the server's Backups page. It costs nothing beyond storage and gives you a restore point from minutes ago rather than last night. The staging push dialog has a box to do this for you; tick it every time. Our staging guide shows where.

How to restore a site

1. Open the application that needs restoring, then Backup and Restore.
2. Pick a restore point from the list of available backups.
3. Restore. The application's files and database go back to that point. Other applications on the server are not touched.
4. Clear caches in Breeze and any CDN, then check the site, logged out and logged in.

Restoring at server level is different: it rolls every application on the server back to the chosen time, including sites that were fine. Use it only when the whole server needs to go back, and warn anyone whose site shares the server. If you only need a file or a table back, restore to a staging copy or download a backup and copy across just what you need.

Deleted servers and applications

If you delete an application or a whole server by mistake, Cloudways can recover it from backups, but only within 14 days. After that, the data is permanently gone. Deleted staging applications cannot be recovered at all. A recovered application comes back as a new application with a new temporary address, so you need to re-add its domain and update DNS. Recovery is in My Applications, under Recover Application, and you can restore to the same server, another server or a new one.

The same 14-day limit applies to servers removed for unpaid invoices. If a card expires and an invoice goes unpaid, access is restricted and the server can be removed after 14 days, so keep billing details current. Our guide to cancelling Cloudways covers downloading backups before deliberately closing an account.

Keep a copy outside Cloudways

Cloudways' backups protect you against your own mistakes and a failed server. They do not protect you against losing access to the Cloudways account itself, through a billing dispute, a compromised login or a mistaken account closure. For any site that matters, keep one more copy elsewhere:

• A WordPress backup plugin such as UpdraftPlus, sending weekly copies to your own Amazon S3, Backblaze B2 or Google Drive storage.
• A periodic download of an application backup to your own storage, for sites that rarely change.
• Two-factor authentication on the Cloudways account, so the account itself is hard to lose.

On Cloudways Autonomous, off-site backups are unlimited and included in the plan price. For the security side of protecting a site, see our Cloudways security guide.