cPanel backup guide - How to define backup policy in a cPanel/WHM server

What all data should I backup? How often should I backup? How long should I keep the backup data? Where should I store the backup data?

These are some of the common questions cPanel web hosts ask our cPanel server administrators. Here we'll go through the most common decision points for defining a cPanel backup policy.

Before we go into finer details, lets address the bigger question first:

Why take backups?

Backups take up valuable disk space. It induces server load when it runs. It just sits there gathering cobwebs with no apparent use. At least a few web hosts have thought aloud if it is just a luxury that can be done away with a well drafted "User's Responsibility" in the End User Policy.

The short answer is, it is a necessary evil. Backups do eat up your resources, but it is your safety net. Customer data is a strategic asset. It allows you bounce back to full service status after a disastrous server crash. Your periodicity of backup, the storage location, and the technology used determine how robustly you can recover from a downtime.

This leads us to the next question:
 

What all data should I backup?

The short answer is, anything that won't be available in a freshly installed server. This can include a lot, depending on how customized your servers are. A quick check list is below:

1. Customer website and email data.
2. Configuration files and statistics data of users.
3. Database dumps and database files.
4. Configuration files of all services, including monitoring system, backup system, etc.
5. Files of custom installed applications.
6. If you use a legacy OS, its installation image.
7. License keys, SSL certificates, or any other data of 3rd party origin.
8. Optionally, some key logs like login data, command history, etc.

The most critical among these is customer data, especially email and database content. Those keep changing all the time, and a successful restore depends on how "fresh" the backup is - which brings us to the next question:

How often should I backup?

It depends a lot on how much you can use availability of backups as a marketing edge. Once a week backup should be sufficient to restore your services with not too much damage to service reputation, but if you use backups as a selling point, it needs to be run daily. Some hosts even use continuous data protection, which is then marketed as a premium service.

We usually recommend daily "incremental" backups often run during night time, as it doesn't induce much load on the server, and gives decent coverage for those clients who need their websites restored. By linking the daily incremental backup directory to a low-space-overhead open source backup system like rsnapshot, the recovery points can be extended to many days back, which leads us to the next question:

How long should I keep the backup data?

Short answer: It depends on how often the data changes, and how critical it is in restoring a server. For example, if your server has a customized legacy operating system, the OS image has no life limit unless of course you migrate to a new server. In contrast, customer email data changes almost on an hourly basis, and would be obsolete after a month.

We recommend the following for customer data, and other frequently changing server data like usage statistics:

Daily incremental backup using cPanel's native tool to an attached backup drive, which is linked to a daily differential backup (in a central backup server using a tool like rsnapshot) for up to 14 days. Take weekly snapshots of the daily differential backup, and store them for 8 weeks (hard links and changed data used to minimize space usage). Take monthly snapshots from daily differential, and store them for 3 months.

For system specific data like service configuration files, the retention period is 6 months, with backups taken daily.

Now, we'll address the last question:

Where should I store the backup data?

The purpose of taking a backup is to be able to quickly restore it when it is needed. So, ideally it should be available in a high speed media connected to your server. However, what happens if the whole data center goes down? Yes, its far fetched, but what if?

So, the answer is a balance of all considerations. We'll address it by looking at the possible recovery situations.

1. Customer requests for a data restore due to accidental deletion, security issue, etc. - This would be needed quite often if you advertise availability of backups.
2. A canceled customer (or one who forgot to renew) comes back to have the service restored. - This could happen probably once a month.
3. Accidental change in configuration files, which needs a backup restore. - Might happen once or twice a year.
4. A disastrous hard disk crash leading to partial or total loss of data. - Could happen (god forbid) to one of your servers once every 2-4 years.
5. A total downtime of the data center lasting more than a day. - Very low likelihood, but still known to happen, even to major data centers.

There are 3 locations where backups can be stored. A local disk attached to the server, a central backup server (or network attached storage device) that collects backup from all servers, and an offsite backup server to store the most critical data.

For fast, low-load backups, daily incremental backups should be stored in a locally attached disk. It would also be the most used backup in restores. A central backup server can be used to store the weekly and monthly backups, which will come in useful to restore canceled accounts and corrupted service files. In the event of a server crash, system files stored in the backup server, and daily customer data stored in the local disk can be used to restore the server.

Now, to be truly resilient against a data center crash, the whole data should be available in another data center, but it is a very expensive proposition. Considering the very low probability of the event, the recommended course of action is to keep just a mirror of your own company website in another data center. Some web hosts also keep a backup of their key customers who helped them build the market.

Hopefully, this helped you firm up your cPanel backup policy. We'll further discuss how to implement this recommended backup policy in a cPanel/WHM server. Keep watching this blog for updates.

In the mean time, if you'd like to have one of our cPanel administrators evaluate and help you build your server infrastructure absolutely free of cost, check out our 7-day no-risk free trial offer.