When a university website goes down for hours, it isn't just a technical incident — it directly affects application processes, student portals, payment workflows, and the institution's reputation. Drupal is a powerful and secure content management system, but no infrastructure is fully immune to human error, hardware failure, or cyberattacks. That's why backup and disaster recovery are essential components of any Drupal-based institutional website.
In this guide, we walk through what Drupal backup actually covers, which tools you can use, key concepts like RTO and RPO, critical DR scenarios for higher education institutions, and how the drupal4edu approach builds an end-to-end protection plan.
What Is Drupal Backup and Why Does It Matter?
Drupal backup is the process of regularly creating safe copies of every component your site needs to keep running. Copying files alone or pulling just a database dump produces an incomplete backup. A complete Drupal backup covers three core layers:
- Database: All content, user information, configuration, and session data lives here. Without a database dump, you can't restore your content.
- User files: Images, PDFs, course materials, faculty photos — all uploaded media. These typically live under
sites/default/files. - Code and configuration: Drupal core, modules, custom code, theme files, and exported configuration (config sync) files.
Backup isn't just a safety net during disasters — it plays a critical role in planned operations too. Before a Drupal core update, when installing a new module, when making bulk changes to permission structures or display configurations, or before a major content migration, taking a backup is strongly recommended. Even well-tested updates can behave unpredictably in a production environment with custom code.
Why does it matter so much?
Data loss typically doesn't start with a cyberattack — it starts with human error, a failed update, storage corruption, or an outage on the hosting provider's side. That's why "we have a backup" isn't enough. Where the backup lives, how often it runs, and how often it gets tested are what actually matter.
Backup and Disaster Recovery Are Not the Same Thing
These two terms get used interchangeably, but they're different concepts. Backup is the act of creating a copy of your data. A Disaster Recovery Plan is the complete set of procedures followed to bring a site back online at a defined service level within a defined time frame after an outage.
In other words: a backup is a file; a disaster recovery plan is a written document. The plan clearly defines who does what and when, where backups are stored, how long restoration takes, and what level of data loss is acceptable.
RTO and RPO: The Two Core Metrics of Disaster Recovery
A professional DR plan has two critical parameters:
- RTO (Recovery Time Objective): The maximum acceptable time for the system to be operational again. For example, if your RTO is 2 hours, the site must be back online within 2 hours of an outage.
- RPO (Recovery Point Objective): The maximum acceptable window of data loss. If your RPO is 1 hour, the most data you can afford to lose after restoration is one hour's worth — which means backups need to run at least hourly.
For university sites, these metrics need to be defined more strictly as registration periods, exam result announcements, or accreditation processes approach. A site that crashes on application day damages both the prospective student experience and the institution's reputation in one stroke.
The 3-2-1 Backup Rule: The Industry Standard
In the backup world, the 3-2-1 rule is the gold standard:
- You should have at least 3 copies of your data (1 primary, 2 backups).
- These copies should live on at least 2 different media or devices.
- At least 1 copy should be kept offsite.
For Drupal, this rule works in practice like this: the first copy lives on the production server running the site, the second copy on an independent backup server or cloud storage service (like Amazon S3 or Azure Blob), and the third copy in an entirely separate location. A backup stored on the same server stops being a backup the moment the server crashes.
Backup Methods for Drupal Sites
The Drupal ecosystem offers several backup methods. Which one to choose depends on site size, traffic, your team's technical capacity, and your hosting infrastructure.
Backup and Migrate Module
Drupal's most widely known backup module. It supports database, file, and code backups, scheduled backup definitions, gzip/bzip/zip compression, and optional encryption. The interface works well for small and mid-sized sites — but because it stores backups entirely on the production server, it isn't sufficient as a disaster recovery solution on its own. If the server goes down, you lose access to the backups too.
Command-Line Backup with Drush
Drush is Drupal's command-line tool. Commands like drush sql-dump for database dumps and drush archive-dump for archiving code and database together let you script a full backup workflow. Combined with cron on the server, you can build an automated and schedulable backup pipeline. It's developer-friendly and more reliable than module-based solutions for large sites.
Server-Level (Snapshot) Backups
This is the disk-snapshot-based backup method offered by hosting providers or cloud platforms. Managed Drupal platforms like Pantheon, Acquia, and Platform.sh provide automated snapshot-based backups. The advantage: it captures a point-in-time image of the entire server. The disadvantage: some providers use these backups only for their own internal disaster recovery processes — meaning they don't give the site owner ad-hoc restore access. This is something to verify before signing any contract.
Restic Backup Module
The Restic Backup module offers a more modern approach and is especially effective for backing up uploaded files. Incremental backups and deduplication keep storage costs down. It can back up to SFTP or S3 targets. For university sites with large media libraries, a combination of Git for code, Retention Database Backup for the database, and Restic for files delivers comprehensive protection.
Backup Frequency and Retention Policy
Backup frequency depends on how quickly your site changes. For a university portal with regular content updates and many concurrent users, a practical retention policy might look like this:
| Backup Type | Frequency | Retention Period |
|---|---|---|
| Daily | Every day | Last 7 days |
| Weekly | Every week | Last 4 weeks |
| Monthly | Monthly | Last 6–12 months |
| Event-based | Before updates/migrations | Until the related task completes |
This policy can be tightened based on how rapidly the site changes and how sensitive the data is. On exam result announcement days or during registration periods, for example, shrinking the backup interval down to hours makes sense.
Drupal Backup for Higher Education: What's Different?
A corporate site and a university site might seem to have similar backup needs on the surface, but the implementation details differ significantly.
- Multisite architecture: Universities typically host dozens of subsites for the main site, faculties, institutes, library, and research centers. Each needs its own backup policy, but they all need to be managed under a unified DR framework.
- LMS integration: For Drupal sites integrated with Moodle, Canvas, or institutional LMS platforms, the backup needs to capture integration parameters and caches consistently.
- Personal data and regulations: Student data falls under data protection regulations. For campuses in the EU, GDPR applies; in the US, FERPA; in California, CCPA; and other regions have their own frameworks. Backups must be encrypted and access-controlled.
- Peak traffic windows: During registration periods, application days, or exam result announcements, RTO/RPO thresholds need to be tightened. The cost of an outage during these windows is multiple times higher than on normal days.
- Accreditation and audits: Audits like ABET, AACSB, or regional accreditation bodies may require site content history to be preserved and retrievable. Long-term archival backups become essential here.
Step-by-Step Drupal Disaster Recovery Plan
A backup alone isn't a disaster recovery plan. The steps below offer a DR framework applicable at the university scale.
- Inventory critical assets. List which systems (main site, application portal, library, alumni) sit at which priority level.
- Define RTO and RPO values for each system. This directly drives backup frequency and technology choices.
- Build your backup architecture around the 3-2-1 principle: production, separate server or cloud, offsite.
- Encrypt your backups. This is a compliance requirement for GDPR, FERPA, and similar regulations — and a leaked backup is a major security risk regardless.
- Document the restoration procedure. Who does what, in what order? If the responsible person is on vacation, who takes over?
- Test the DR plan on a regular schedule. A plan that lives only on paper usually fails when a crisis actually hits.
- Integrate with version control. Manage your code in Git so backups only need to cover the database and files.
- Prepare a communication plan. Design upfront how students, faculty, and the press will be informed during an outage.
Don't Trust Backups You Haven't Tested
If we had to sum up the most expensive lesson in this industry in one sentence: an untested backup isn't a backup. Many teams have run backups for years, only to discover during their first restoration attempt that the backup was corrupted, incomplete, or the wrong version.
The fix is simple. On a regular schedule (quarterly, for example), restore a real backup file into a staging environment. On the restored site, verify content integrity, user sessions, configuration settings, and integrations one by one. Document the results, address any issues, and keep a test history log.
Common Backup Mistakes
- Keeping backups on the same server: When the server crashes, you lose access to the backups too.
- Backing up only the database: Without code and user files, the site can't be restored.
- Not encrypting backups: A leaked backup causes damage equivalent to a production breach.
- Failing to document the restoration procedure: Improvising in a crisis increases the risk of error.
- Not testing backups: A broken backup can be more dangerous than no backup at all.
- Neglecting the right tool selection: Module-based backups fall short in some critical scenarios — they should be combined with server-level backups.