Automated Backups and Disaster Recovery Strategies for Drupal Websites

Statistics show that Drupal is more popular with prominent, high-traffic websites than with smaller projects. The figures are backed by countless examples proving that Drupal is an excellent building platform for a successful online business.

However, the bigger your business is, the more responsibilities you have toward your users and customers, especially in the field of security. You need a comprehensive data protection policy that covers as many feasible scenarios as possible and ensures that you have a plan of action in case the worst happens.

Automated backups and disaster recovery strategies are central to this policy. Today, we’ll see what they do, why they’re important, and how to set them up correctly.

The Importance of Backups and Disaster Recovery Strategies

In an ideal world, you’d never need to use your backups, and your disaster recovery strategy would be a Word document you’ve written and forgotten about. Unfortunately, we don’t live in an ideal world, so you must take the matter seriously.

Your Drupal site is very likely a source of income for you, so you want to make it as reliable as possible. You can take many precautions to ensure uptime stats are perfect, and so can your hosting provider.

Nevertheless, with something as complex as a Drupal website, you can never really be certain that everything will work fine. There are dozens of components, and the performance of each is affected by numerous factors. Many of them are outside your control.

You may be lucky enough to build and develop your business without any technical glitches, but you mustn’t ignore the possibility of something breaking at some point.

This is where a disaster recovery strategy comes in. In simple terms, it’s the plan of action you follow when your site is down, and you need to bring it back up again. Most of the action revolves around your backups.

A backup is a copy of your Drupal site’s files and database stored separately from the original. It’s a point-in-time snapshot you use to restore your site after an incident has caused corruption or data loss. This incident could involve software malfunction through a cyberattack or hardware failure. Before we delve further, let’s determine what backups we will discuss today.

You should always back up your site before performing core updates or installing new modules. Doing so can help you undo any changes you make if they don’t work. 

You want to lose as little data as possible while recovering from an incident, so your backup must be recent.

That’s why hosting providers and software vendors offer automatic backup solutions. These solutions create and store secure copies of your website regularly. The intervals between backups and the technologies differ from one backup system to the next, but the goal is always the same—ensuring that if you need to restore your site, it’s as close to its last known working state as possible.

The main objective is to bring the site back up with minimum losses, but doing it quickly is also extremely important. Downtime is expensive, so your disaster recovery strategy must include a set of protocols and procedures that allow you to restore the data as efficiently and reliably as possible. A few precautions taken in advance can also help.

Now that you appreciate the importance of a good disaster recovery plan, it’s time to build one. We’ll start with the different approaches to setting up automated backups for your Drupal website.

Backup Drupal Modules vs. Cron vs. Server-Level Tools

As always, there are multiple ways to approach the task, each with its advantages and disadvantages. Let’s take a look at the details.

• The Backup and Migrate Module for Drupal

We’re talking about an open-source CMS, so some of you are probably guessing that there is an add-on that can take care of the Drupal backups for you. And you’re right.

The Backup and Migrate module is designed to ease the process of creating a backup by automatically dumping the database and archiving your site’s files. Crucially, it can be configured to do this according to a predetermined schedule.

While it makes backups relatively easy, its installation is a bit trickier than usual. Still, if you take the time to read through the documentation and follow the instructions carefully, you’ll have no problems setting it up.

After activating the module, you should create a private directory where your backups will be saved. The folder must have writable permissions by the server and be outside your site’s document root.

Then, you need to edit Drupal’s primary configuration file (/sites/default/settings.php) and specify the private directory’s path under the file_private_path variable. This ensures your backups aren’t publicly accessible.

Finally, you can log in to Drupal’s back end and go to Configuration > Backup and Migrate. Since we’re interested in automatic backups, we’ll go to the Schedules tab, where you can specify when your backups will be created and what they will include.

Once you go past the initial installation, using the module is pretty straightforward, and you can enjoy enhanced flexibility when configuring your backups.

There are a couple of drawbacks, though. First, putting a module in the center of your disaster recovery plan is hardly the best solution. To restore data from the add-on, you need the Drupal installation to be relatively intact, which is rarely the case after an incident involving data loss. Furthermore, the backups will be stored on the production server, which presents a few potential problems.

• Cron

Every Linux server is equipped with Cron – a utility that acts as a job scheduler and can automate some tasks. The utility uses the crontab (or cron table) file, which is traditionally edited via the command line, but to make your life easier, many web hosting control panels also have tools for creating and managing cron jobs.

For example, if you use SPanel, you have an interface that looks like this:

You decide how frequently and at what time of day the job will be run. To simplify things, SPanel lets you choose from a few presets in the drop-down menu. In the Cron command field, you enter the command you want to execute at the specified time.

To create a backup of your Drupal website, you’ll need two cron jobs – one for dumping the database into an SQL file and the other for adding the contents of your site’s document root folder to an archive.

For the database, you can use the mysqldump utility with a command that looks like this:

mysqldump -u [your MySQL user] -p'[the MySQL user’s password]’ [the name of the database] > [filename].sql

To archive the files, your command should look like this:

tar -czvf [filepath]/[filename].tgz /home/[your hosting account’s username]/public_html

Cron will ensure the two commands are executed at their specified times.

What you see above is automation at a very basic level. You can build up on the commands and write a script that does things like timestamping the backup files, retaining them for a set period of time, and even sending them to a remote server, but you have to be fairly handy with the command line.

Furthermore, if you want Cron to be at the center of your disaster recovery strategy, you also need to try to optimize the restoration process as much as possible.

• Server-Level Backup Tools

You can find tools that do all of the above without requiring you to write commands, put together scripts, or fiddle with settings. These solutions are installed straight on the server and can be integrated into your control panel, so you often have an easily accessible graphical user interface for managing your backups.

Features like incremental backups speed up the process and keep the load on the server in check. You can also often store the data in an offsite location.

Some hosting providers develop their backup systems themselves, and others use solutions built by third-party vendors. When choosing a hosting account, it’s a good idea to check whether such a tool is even included in your plan. If you opt for a self-managed server, you’ll likely need to configure it yourself and set aside a budget for it.

Whatever solution you choose for backing up your site, you have to make sure it’s optimized to minimize data loss and accelerate recovery. While setting everything up, you should consider several things.

Backup Frequency

Website owners often wonder how frequently they should back up their websites. The truth is there are too many factors at play to give a definitive answer.

Different websites have different requirements, and if you don’t take them into account when you’re building your backup and disaster recovery strategies, you’ll have a hard time minimizing data loss. We’ll illustrate the point with a couple of examples.

First, you have a Drupal website promoting a local business. Its only purpose is to showcase the products and services offered by a small company. The stuff on display rarely ever changes, and the owner is too busy running the business to deal with things like a blog or any additional content. There is no online store section, and the only point of interaction between users and the site is a simple contact form.

There’s little point in creating a backup of this website every few hours. In fact, the only thing that would do is put an unwanted load on the server and potentially slow the site down.

At the other end of the scale, you have a Drupal-powered news website. A team of reporters and content writers publishes multiple articles every hour. There’s a comment section where users can say what they think and a newsletter users can subscribe to.

What happens if your server goes down and your most recent backup is a couple of days old?

Well, dozens of articles will go down, and you’ll have to republish them one by one because if you don’t, the links indexed by Google will return an error, which is not very good for your site. Visitors’ comments from the last 48 hours will also be lost, which is unlikely to make them particularly happy.

Such a website has to be backed up at least once a day. If it isn’t, the data loss in the event of an unforeseen outage is inconvenient, to say the least.

In other words, the more often you add content and update your site, the more frequent your backups should be. This isn’t the only consideration, though.

Let’s assume you have an online store that is still in the early stages of development. Since you register only a few orders a week, you may think your backups don’t need to be that frequent.

However, remember that every order you register contains sensitive personal, billing, and transaction data. Losing it won’t speak good for your business, especially while it’s still relatively small. In this case, you can save yourself a lot of headaches by making your backups more regular.

In other words, it’s not just the volume of data your site handles but also its nature. The more valuable the information, the higher the stakes are, and the more frequently you must back it up.

Backup Retention

You have automatic daily backups set for your server. Your site is archived at midnight every single day, and each new backup overwrites the previous one, meaning you have a retention period of 24 hours.

This is not an ideal solution.

Let’s imagine, for example, that your site is targeted by hackers who want to send spam. On Monday, they use a phishing email to steal your password and break into your server. Once in, the attackers immediately install a backdoor – malicious software that gives them future access to your premises. This allows them to access the backend, even if you reset your password.

The hackers then wait a few days and start sending spam from your server.

You realize what has happened and decide the best course of action would be to restore everything from a backup. If your retention period is 24 hours, your only option is to restore the site from Tuesday’s archive. However, because the attackers installed the backdoor on Monday, Tuesday’s backup is already compromised. So, after you bring the site back, they can still use your server for spam campaigns.

This is just one example of how a longer retention period can save the day. It lets you pick between several backups going further back in time, helping you restore your server to a point when it was backdoor-free.

Your hosting environment will be secure post-restoration, so the extended retention period makes your disaster recovery plan more robust. In addition to giving you extra flexibility, it also ensures that you have a secure hosting environment.

Backup Encryption

Cybersecurity is not a matter you should take lightly. A backup is essentially a package containing all the data from your website. In that respect, it’s a more appealing target for hackers than the site itself.

If someone breaks into your hosting server or Drupal backend, you’ll find out sooner or later, and you can cut off their access before they find the data they’re looking for. By contrast, if an attacker gets their hands on your backup, they have all the time in the world to look for the needed information.

Fortunately, all the time in the world won’t be enough if someone attempts to look inside a securely encrypted backup file.

Encryption is the process of scrambling human- or machine-readable information in order to protect it. It’s the pillar of data security and can be implemented in a variety of ways. When it comes to encrypting backups, you’ll likely use off-the-shelf solutions that provide two main types of encryption.

• Encryption at rest

From your perspective, encrypting a backup at rest usually involves protecting the archive file with a password, which unlocks its contents. Behind the scenes, complex technology is employed to ensure unauthorized access is impossible. With the correct algorithm and implementation, nobody can get in without your password. Just make sure you use a strong passphrase.

• Encryption in transit

If you want to store your backups in an offsite location, you want to ensure they’re secure while moving from your production server to the storage machine. In other words, you must establish a secure communication channel to prevent anyone from intercepting, stealing, or tampering with your backups.

This also involves encryption, but the idea here is to scramble the data only while it’s transferred from one server to another. This is known as encryption in transit and is usually provided by secure communication protocols like SSH and SFTP.

Ideally, you should be looking for a solution that encrypts your backup both at rest and in transit.

Backup Storage

When you create the backup, you have to find a place to store it. There are three main options, but only one is truly suitable.

• Storing backups on the production server

Many would probably think that it’s logical to create a folder named “backup” on your account and put your site archives there. It is the most straightforward and, at first glance, the most affordable option.

But what happens if hackers gain unauthorized access to your server? The first thing they’ll do when they see the “backup” folder is to delete it, so you have no way of restoring the data.

Storing archives on a different server but in the same data center is also problematic. Modern data centers are pretty advanced facilities but are not completely immune to fires and other natural disasters. It’s not unheard of to see an entire data center go down, so putting both the production server and the backups in the same building carries a certain degree of risk.

• On-premises backup storage

Given that you only need storage to keep your backups, you might think the old computer gathering dust in the corner of your office may do the trick. However, this is rarely the case.

For one, as your website grows, so will its storage requirements, and it’s naive to think you can satisfy them in the long run with a computer designed for home or office use.

Furthermore, we’ve already learned that restoring data from a backup is a matter of urgency. You need instant access, and if you rely on regular hardware and the upload speed provided by your local ISP, this simply isn’t going to happen.

• Offsite backup storage

This leaves us with the only really secure way to store automatic backups – on a different server in an offsite location.

If you employ a second server in a different data center from your production machine, you minimize the risk of losing control over your site. Some experts even advise keeping multiple backups in multiple locations.

While this may be overkill for owners of regular websites, finding a solution that stores copies of your site on a remote server is crucial for projects of all shapes and sizes.

If you have to set up archiving yourself, it’s best to look at cloud services offered by companies like Amazon. They’re infinitely scalable and can be highly cost-effective.

Backup Testing

Thanks to the myriad of tools available, backing up a Drupal website may look deceptively simple. Even if you set up a cron job and write the commands yourself, your input is minimal.

However, behind the scenes, we’re talking about archiving hundreds and possibly thousands of files. Add to that the innumerable rows and columns that need to be extracted from the database, and you’ll see that it’s quite the undertaking.

At the same time, the connections between records in the database and the files in Drupal’s core and modules are so critical that even the tiniest glitch could corrupt the entire backup. And if the archive is corrupted – you can’t use it to get your website going again.

In the worst-case scenario, you won’t know that something has gone wrong with your backup until the time comes to restore the data. By then, your site had already suffered a malfunction, and your quickest and easiest way to fix it wouldn’t really work.

That’s why it’s a good idea to test your backups regularly.

It’s usually impossible to do that with every single archive your server generates. Still, you can review your logs every so often to ensure there are no glaring issues. You should look for errors generated by the automatic backup system, the web server, and the database engine.

You should also test the restore yourself. A staging environment is perfect for this job, as it allows you to see the restore process in action without disrupting the operation of the production site.

Downtime Notifications

At the end of the day, you set up an automatic backup system and build a disaster recovery strategy to minimize downtime, so you have to react as quickly as possible to any emergencies.  To respond quickly, however, you need to be notified about the problem as soon as it occurs.

There are several ways you can ensure this is the case.

• Through a Drupal module

Drupal modules can monitor your website’s health and collect information about a wide range of critical performance metrics. The data is usually organized and stored in logs, but some add-ons, like the Watchdog Statistics module, can be integrated with additional services that send alerts whenever something’s wrong.

• Third-party uptime monitoring tools

Uptime monitoring is essential for all website owners, not just Drupal users. That’s why there are dozens of services you can sign up for and get real-time notifications whenever your website becomes unresponsive.

These platforms usually include a range of features like the ability to set up a status page, detailed reports on performance and load, etc. When it comes to uptime monitoring, however, they all work the same way—they ping your website at predetermined intervals and send alerts if they get anything other than an HTTP 200 response (the success status code indicating that everything is okay).

The differences between the various service providers lie in the frequency of the checks and the mediums through which they alert you. There are both free and paid options, so it’s a good idea to do some research and see which one gives you the best features at the right price.

• Open-source tools

For the more DIY-inclined, there are also self-hosted open-source tools that monitor your site and alert you whenever there’s a problem. A good example is Upptime, a utility that can be configured to track any website you want and send out notifications when something goes down.

It’s hosted on GitHub, so you don’t even need to upload anything to your server. Instead, you can use the official repository as a template in your GitHub account, create an access token, and edit the configuration file to ensure the tool pings the right website.

The project developers have included detailed documentation, so if you’re willing to invest the time and effort into setting up and configuring the tool, you’ll have the resources to do it.

ScalaHosting and Disaster Recovery Plans

A website could suffer downtime due to various reasons. Sometimes, the hosting provider is to blame, and in others, the website owner has messed up. It’s not uncommon to see outages caused by faulty software, either.

Whoever the culprit, it’s your host’s responsibility to ensure that, one, the risk of website downtime is minimized, and two, should the worst happen, you have enough options to restore your website as quickly as possible.

At ScalaHosting, we’ve been in the industry long enough to know how to deal with backups.

Our hosting services are built with state-of-the-art technology that keeps our servers running and allows us to promise our clients upward of 99.9% uptime. And we’re ready to put our money where our mouth is and issue refunds if we’re unable to meet our goals.

We haven’t forgotten about backups, either. Every single one of our hosting plans—from the cheapest shared package to the most advanced VPS—comes with daily backups, which are stored offsite to ensure you can access them even if the entire data center hosting your production server goes offline. As standard, the retention period for our daily backups is 24 hours, but as an extra feature, you can keep them for three or seven days.

If you want yet more peace of mind, you can take advantage of our 24/7 proactive monitoring. With it, every single service on your server is checked every minute, so within sixty seconds of a problem occurring, our experienced sysadmins already know about it and can act to resolve it. This further reduces the chances of ever needing to restore your site from a backup. If you want to learn more, don’t hesitate to contact the ScalaHosting Team.

Conclusion

Nobody wants to be in a position where they need to put their disaster recovery plan into motion. If you’ve reached this point, your site is either severely compromised or offline, and you need to get it working again as quickly as possible.

This is when it becomes apparent why having a good disaster recovery strategy and reliable backups is so important. The better prepared you are now, the quicker and more hassle-free the restore will be.

FAQ

Q: How do I back up my Drupal site?

A: You have multiple options for backing up a Drupal website. It’s possible to use a module, and you can also set up a couple of cron jobs to automate the task. However, in terms of both functionality and usability, the best option is to use a server-level backup system installed on top of the operating system and integrated into your control panel.

Q: What is the difference between disaster recovery and backup?

A: A backup is a copy of your site’s database and files. A disaster recovery plan is the strategy for configuring automatic backups and the procedures you follow to restore them and bring your website back up as quickly as possible.

Q: How do you create a disaster recovery plan?

A: You start with your automatic backups. You need to set them up correctly so they’re easily accessible whenever needed. You must have solid procedures that allow you to restore the data as quickly and efficiently as possible, and you should probably consider employing other tools that will help you minimize the time to react to an emergency.