Website backup and recovery: how to protect your data

If you host your website in the cloud, you’re in luck. According to stats accumulated by Web tribunal, hardware failure accounts for 40% of data loss cases. Given that the cloud largely eliminates any single point of failure (and assuming your host replaces failed hardware as soon as it occurs), chances are you won’t even notice when a hardware component fails.

But according to those same stats, human error accounts for nearly half of all data loss cases. If you’ve been putting your website’s backup and recovery strategies on the back burner, now might be a good time to figure out how you’ll protect your data. 

One of the best ways to protect your website and data is with website backups. It provides the peace of mind that if something were to go wrong – from natural disaster to a ransomware attack – a quick restore can have you back on track.

But, as websites grow in size and complexity, full site backups no longer become viable. Instead, a strategic approach to website backup and recovery is required, which is what we’ll explain below. Implementing these steps while your site is still growing will instil the necessary routine and iron out any wrinkles as you finetune the process to meet your needs.

Perform a business impact analysis

A business impact analysis (BIA) is an examination of how a disaster scenario will impact a business’s operations. The analysis, therefore, starts by identifying possible disaster scenarios that could negatively impact a website, and how that affects the business. Examples include:

• Hardware failure. As previously said, this is less likely to happen in a cloud environment because of redundant hardware. But it becomes a reality if a service provider’s entire infrastructure is impacted by, for example, man-made or natural disasters. Let’s not forget that data centre fires do happen.
• Security breaches. It’s rare that attackers will outright just delete data. Ransomware is a more common occurrence; attackers know that every minute of downtime negatively impacts a business’s bottom line.
• Human error. It should be kept in mind that human error isn’t just limited to mistakes made by people in your organisation. It includes mistakes made by people in data centres and other services on which your website’s operation depends.

The business impact analysis should also determine how data loss affects the business in various key areas:

Finances. Calculating the average cost of website downtime (measured in £/hour) is often a good starting point with a business impact analysis.

Reputation. Downtime at critical moments can be a dealbreaker, especially when other businesses rely on you for mission-critical services. The resulting reputational damage can produce a ripple effect through supply chains.

Regulation. Are you bound by regulation (e.g. GDPR) to inform stakeholders about a downed website? Could you face severe financial penalties?

Productivity. Businesses that rely heavily on their websites may also face a loss in productivity. Aside from the financial loss mentioned above, what is the cost of staff being unable to perform their duties?

In short, your business impact analysis should approach the effects of website downtime from every angle. The more thorough, the better your position to implement contingencies.

Set backup and recovery RTOs and RPOs

Recovery time objective (RTO) and recovery point objective (RPO) are two fundamental terms associated with website backup and recovery. Here’s what they mean:

Recovery time objective (RTO): This refers to the maximum amount of time it should take to restore a downed website back to operational status. Or, put differently: “How long can our site(s) be down before we suffer irreparable damage?

Recovery point objective (RPO): For many websites, this is essentially the time between backups. In other words, if you lose your entire site now and you only backup once a week, then you have an RPO of 7 days or 168 hours. This is, of course, an extreme example since few businesses can afford to lose a week’s worth of information, however many businesses do not run backups nearly as often as they need to meet their RPO.

How you determine RTO and RPO depends entirely on your business and the role your website plays in your business. But for mission-critical sites and apps both RTO and RPO should be as close to zero as possible.

Implement a backup strategy

By now you should be able to see that the business impact analysis influences RTO and RPO, which should in turn influence your backup strategy. A single backup strategy may include various types of backup, depending on the complexity of your website or hosted applications.

Types of backup methods include:

1. Full backup. This involves copying all website data (files, database, etc.) to a backup storage device or location. It is the most comprehensive type of backup.
2. Incremental backup. This involves backing up only data that has changed since the last backup. It is faster and requires less storage space than a full backup.
3. Differential backup. This is similar to incremental backup, but it only backs up data that has changed since the last full backup. It requires more storage space than an incremental backup but is faster than a full backup.
4. Mirror backup. This involves creating an exact copy of the website data on a separate storage device or location. It provides redundancy and can be used for disaster recovery.
5. Cloud backup. This involves backing up website data to a cloud-based storage service. It provides easy accessibility and scalability.
6. Hybrid backup. This combines multiple backup methods, such as full and incremental backup, to create a comprehensive backup strategy.

Backup types should be accompanied by policies for backup storage, like the 3-2-1 backup rule which recommends a master backup and two copies of the master (3 backups), two of which are stored on different media (2), and one which is stored offsite (1). 

Of course, this backup rule was created before the days of cloud computing while magnetic tape backups were still used. As such, and given the proliferation of cloud storage services, it’s entirely possible to store multiple copies of your website with different service providers and keep one copy in your desk drawer.

Regardless of where you choose to store your backups, routine testing of your backups is strongly recommended – realising your backups are corrupt or incomplete at a critical moment can add insult to injury.

Create response policies

In its simplest form, a response policy is how disasters are managed. In addition to outlining the various scenarios for potential downtime, it should define:

• Roles and responsibilities. Who are the key personnel in the disaster recovery response plan? This should include IT staff as well as marketing / PR teams. Remember to include the contact information of everyone who’ll play an active role in the mitigation and recovery process.
• Emergency procedures. Outline the procedures that should be followed in case of a disaster, including communication and response procedures.
• Document the recovery process. It is essential to document the recovery process to ensure that it can be followed easily and correctly in case of data loss. This documentation should include the recovery plan, backup procedures, restore procedures, and contact information for support personnel.
• Monitor the recovery process. Monitor the recovery process to ensure that website data is restored correctly and that the website works the way it should.

Keep in mind that a response policy shouldn’t necessarily be confined to members of in-house staff; including your service provider’s support team in the process can help fill skills gaps and streamline the process.

In fact, if your service provider offers managed backups & disaster recovery it can greatly simplify the entire process: The onus is still on you to perform a BIA and set appropriate RTOs and RPOs. Once done, however, your requirements can be tied to a service-level agreement (SLA) which guarantees restoration of your site in a predetermined timeframe.