A website backup strategy: the 3-2-1 rule

Imagine that one night after updating a WordPress plugin, your site encounters a fatal white screen error. Or worse: a hacker encrypts all your files and demands a ransom. In these moments, the only thing that can save you is a healthy and recoverable website backup. But is having an old zip file from three months ago enough? Definitely not. In this article, we will examine the industry-standard 3-2-1 strategy practically and with real commands so you can set up a professional backup system for your site.

The 3-2-1 Rule: Why Is This Website Backup Strategy Essential?

The 3-2-1 rule is a simple yet powerful framework recommended by IT professionals worldwide. This rule states:

• Keep 3 copies of your data (one primary and two backups).
• Store them on 2 different media types (e.g., local hard drive and cloud storage).
• Maintain 1 copy off-site.

Why is this rule important? If you only have one backup copy on the same main server, a disk failure or ransomware attack could cause you to lose everything. By following this rule, the risk of complete data loss is drastically reduced. Next, we will implement each component with practical examples.

Key Components of a Complete Website Backup

A website backup typically consists of two main parts: files and database. For dynamic sites like WordPress, both parts are critical.

File Backup

Website files include PHP code, images, CSS and JavaScript files, and user-uploaded content. To back up files on Linux, we use the tar command:

tar -czf backup-files-$(date +%Y%m%d).tar.gz /var/www/html/

This command creates a compressed file with a name including the date. For example, the output will be backup-files-20250315.tar.gz. Be sure to replace /var/www/html/ with the correct path to your site's directory.

Database Backup

The MySQL or MariaDB database contains the main site content such as posts, settings, and user information. Use the mysqldump command:

mysqldump -u username -p database_name > backup-db-$(date +%Y%m%d).sql

After execution, enter the database password. For simultaneous compression, you can pipe the output directly to gzip:

mysqldump -u username -p database_name | gzip > backup-db-$(date +%Y%m%d).sql.gz

Important note: If your database is large (over 1 GB), use the --single-transaction option to avoid locking tables.

Implementing the 3-2-1 Rule in Practice

Now that we are familiar with the basic tools, let's implement a complete strategy.

First Copy: Local Backup on the Server

Store the first backup copy on the same main server. This is the fastest way to recover from minor failures. Create a dedicated directory:

mkdir -p /backup/local
chmod 700 /backup/local

Then create a simple script for daily backups. Create the file /usr/local/bin/backup-local.sh with the following content:

#!/bin/bash
BACKUP_DIR="/backup/local"
DATE=$(date +%Y%m%d)
tar -czf $BACKUP_DIR/files-$DATE.tar.gz /var/www/html/
mysqldump -u root -pPASSWORD database_name | gzip > $BACKUP_DIR/db-$DATE.sql.gz
find $BACKUP_DIR -type f -mtime +7 -delete

The last line deletes files older than 7 days to prevent disk space from filling up. Make the script executable:

chmod +x /usr/local/bin/backup-local.sh

And run it with cron:

0 2 * * * /usr/local/bin/backup-local.sh

Second Copy: Backup on a Different Medium (Cloud Storage)

The second copy should be stored on a different medium. The best option is to use cloud storage services like AWS S3, Google Cloud Storage, or local services. Using rclone, you can easily transfer backups to the cloud. First, install and configure rclone:

rclone config

Then create a new script for automatic upload:

#!/bin/bash
rclone copy /backup/local remote:backup-site/ --progress
find /backup/local -type f -mtime +30 -delete

This script copies local files to the cloud and deletes files older than 30 days. Run it with cron:

0 3 * * * /usr/local/bin/backup-cloud.sh

Third Copy: Off-Site Backup

The third copy should be stored in a location completely separate from the main server. This could be another server in a different datacenter or even an external hard drive that is periodically moved to another location. For simplicity, you can use an FTP or SFTP service on another server:

#!/bin/bash
HOST="backup.example.com"
USER="ftpuser"
PASS="password"
lftp -u $USER,$PASS $HOST <

This script uses lftp to transfer files to another server. Be sure to use a strong password and the SFTP protocol instead of FTP.

Testing Recovery: The Most Important Part of Website Backup

Many people take backups but never test them. Until you have fully restored a backup, you cannot trust it. A common mistake is that the backup file is corrupted or the database is incomplete. To test recovery:

1. Create a test server or a separate directory.
2. Extract the backup files: tar -xzf backup-files-20250315.tar.gz -C /tmp/test-restore/
3. Import the database: mysql -u testuser -p testdb < backup-db-20250315.sql
4. Open the site in a browser and ensure everything works.

Common mistake: Forgetting to adjust path settings in configuration files. After recovery, absolute paths in PHP files may have changed. Be sure to check the wp-config.php file (in WordPress) or similar files.

Backup Automation and Monitoring

To ensure regular backups, use monitoring tools. A simple way is to send logs via email:

0 2 * * * /usr/local/bin/backup-local.sh && echo "Backup successful" | mail -s "Backup Report" admin@example.com

You can also use tools like healthchecks.io or similar services to receive alerts if a backup fails to run.

Security Tips for Website Backup

• Protect backup files with a password: gpg -c backup-file.tar.gz
• Use encrypted protocols (SFTP, SCP) for transfer.
• Restrict access to the backup directory: chmod 700 /backup
• Automatically delete old backups to manage storage space.

Summary

A professional website backup strategy with the 3-2-1 rule ensures you are resilient against any disaster. Three copies, two different media types, and one off-site copy, along with regular recovery testing, will save you from major headaches. Using the scripts provided in this article, you can set up an automated backup system in less than an hour. Remember: a backup that hasn't been tested is not a backup. ServerNet, as a web hosting service provider, always emphasizes the importance of regular backups and provides the necessary tools for this task to its users.