Server Backups: The 3-2-1 Rule and Methods

The 3-2-1 backup rule

The most widely accepted rule in backups is simple:

• 3 copies: The original data and two backups.
• 2 different media: For example the server's own disk and separate storage.
• 1 copy somewhere else: In a different data center or with a different provider.

For a server, in practice this means: your original data lives on the server, your provider's automatic backups make up the second copy, and the encrypted backups you send to another provider make up the third. Today one more requirement is often added to this rule: at least one of the copies should be immutable or impossible to delete from the server, so an attacker who takes over the server can't delete the backups too.

Types of backups

The most robust setup is to use them together: the provider's server backup gives you fast disaster recovery, while file and database backups give you the flexibility to bring back a single file or table and to move to another server.

What should you back up?

• Application and site files: /var/www, game server folders, bot code and content uploaded by users.
• Databases: Not as a file copy, but as a dump taken with the database's own tool.
• Configuration files: Nginx, service and firewall settings under /etc; .env files; the output of crontab -l.
• Docker data: Compose files and volumes or bind-mounted folders.

You don't need to add the operating system itself or files that can be downloaded again (for example a game server's files downloaded with SteamCMD) to your file backup; only the data and settings you created matter.

Backing up databases correctly

Copying the files of a running database can result in a backup that won't open. First take a dump with the database's own tool, then include that dump in your file backup:

mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz

If you use PostgreSQL, pg_dump does the same job. We covered installing and backing up MariaDB in detail in our How to install MariaDB guide.

Encrypted offsite backups with restic

restic is a free, open-source backup tool. It encrypts backups, stores repeated data only once (deduplication) and sends only the changed parts with each backup. It can send backups to another server over SFTP or to S3-compatible object storage.

1. Install restic:

   sudo apt install restic
   

2. Write the encryption password to a file and protect it so only root can read it:

   sudo sh -c 'openssl rand -base64 32 > /root/.restic-password'
   sudo chmod 600 /root/.restic-password
   

   
   Save this password somewhere safe as well. Without the password, the backups can't be opened.
3. Create the backup repository on another server. For example, over SFTP:

   sudo restic -r sftp:backup@198.51.100.20:/srv/restic init --password-file /root/.restic-password
   

4. Take the first backup:

   sudo restic -r sftp:backup@198.51.100.20:/srv/restic --password-file /root/.restic-password \
     backup /var/www /etc /var/backups
   

5. Clean up old backups according to a retention policy:

   sudo restic -r sftp:backup@198.51.100.20:/srv/restic --password-file /root/.restic-password \
     forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
   

This policy keeps one backup for each of the last 7 days, the last 4 weeks and the last 6 months. For the SFTP connection, your server needs to be able to connect to the backup server with a key, without a password; we explained how to create an SSH key in our What is SSH? post.

Automating backups

A backup taken by hand will be forgotten one day. Put the steps in a script, for example /root/backup.sh:

#!/bin/sh
set -e
REPO="sftp:backup@198.51.100.20:/srv/restic"
PASS="/root/.restic-password"

mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
restic -r "$REPO" --password-file "$PASS" backup /var/www /etc /var/backups
restic -r "$REPO" --password-file "$PASS" forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Make the script executable and run it every night with sudo crontab -e:

30 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Check the log file now and then, or use a monitoring service that notifies you when a backup fails. A backup that fails silently is the same as no backup at all.

Test your restores

An untested backup is a backup you don't know actually works. Run these checks once a month:

• List the backups: Use restic snapshots to see that backups are being taken regularly.
• Restore a file: Bring back a single file with restic restore latest --target /tmp/test --include /var/www/site/index.php and check its contents.
• Try the database dump: Load the dump into a separate test database and check that the tables come back.
• Check integrity: restic check verifies that the repository is intact.

Even better, a few times a year try restoring everything from scratch onto an empty server. That's the only way to find out how quickly you can recover in a real disaster.

Backups at Nodesty

Nodesty AMD Ryzen 9 9950X VPS and EPYC VPS plans include free automatic daily backups kept for 7 days, which you can turn on and off from the panel. On web hosting plans you reach your backups from the control panel with JetBackup, and on game servers daily backups are kept for 7 days as well. These backups provide the second copy in the 3-2-1 rule. For your important data, we recommend keeping an independent copy somewhere else, as in this guide.