3-2-1 Backup for VPS: A Practical Guide

To ensure your VPS backup is truly recoverable, follow the 3-2-1 backup strategy, use tools like Restic or Borg, set up automated backups, and regularly verify their functionality by restoring data to a test VPS with 2 GB RAM and a 20 GB NVMe disk at least once per quarter.

VPS and dedicated server owners often face a paradox: they have backups, but they can't restore data from them. This is especially critical for commercial projects, where every minute of downtime means lost revenue and damaged reputation. Statistics show that backup issues are one of the most common causes of data loss, often not due to a lack of backups, but because they are non-functional. Unfortunately, many administrators and developers only realize this when a server has already crashed and data urgently needs to be restored. It's at this critical moment that they discover the backup is either corrupted, incomplete, or the restoration process is so complex and undocumented that it takes hours or even days. In this article, we'll thoroughly explain how to build a reliable VPS backup system that truly works and won't fail when you need it most.

Why Your VPS Backups Might Not Work

The Illusion of Security: When Backups Fail

Many companies and individual developers live with a false sense of security, relying on the mere existence of some backup. They set up automated VPS backups long ago, the script runs faithfully every night, and logs indicate success. However, reality can be much harsher. Imagine a scenario where your primary VPS fails due to hardware malfunction, a cyberattack, or a fatal configuration error. You attempt to restore data from your "working" backup and discover that:

• The archive is corrupted or incomplete.
• The encryption key was lost or changed, making data inaccessible.
• The backup was only stored on the same server, which is now unavailable.
• The backup script is outdated and doesn't account for new directories or databases.
• Database consistency is compromised, preventing it from starting after restoration.
• The restoration process takes significantly longer than expected due to complexity or lack of documentation.

Any of these scenarios transforms your "backup" from a life raft into an anchor, dragging your project down. This isn't just an inconvenience; it's a direct hit to your business, reputation, and ultimately, financial losses. This is why the main thesis of this article is: a backup that has never been restored is not a backup.

The Cost of Data Loss: From Reputation Damage to Bankruptcy

The consequences of data loss can be catastrophic. For small businesses, this can mean losing customers, fines for non-compliance (e.g., GDPR), and in the worst case, complete cessation of operations. Large companies can face multi-million dollar losses, falling stock prices, and severe brand damage. Even for personal projects, data loss can mean years of lost work, photos, or important information. In 2023, the average cost of downtime due to data loss for small and medium-sized businesses was around $5000 per hour, with this figure significantly higher for large enterprises. This is why investing in a proper backup strategy is not an expense, but an insurance policy.

What is the 3-2-1 Backup Strategy and Why is it Critical for VPS?

The 3-2-1 backup strategy is the gold standard in the backup industry, providing a high degree of data protection against a wide range of threats. It's simple to understand but requires discipline in implementation. This strategy is particularly relevant for VPS environments, where a single failure can lead to the loss of all information on the virtual machine.

Three Copies of Your Data: The Core Principle

The first rule of the 3-2-1 strategy states: you must have at least three copies of your data. This includes your original data (the working copy on your VPS) and at least two backup copies. Why so many? Because any single copy can become corrupted. If you only have one backup and it turns out to be unreadable, you lose everything. Three copies significantly reduce this risk by providing additional "points of failure."

Two Different Media Types: Diversification

The second rule: store two copies of your data on two different types of media. For instance, if your primary VPS uses NVMe disks, one backup copy could be stored on another VPS with HDD disks, and the second in cloud storage (e.g., S3-compatible). Different media types protect against specific failures. For example, a problem with one storage technology (say, a specific SSD model failure) won't affect another (such as traditional HDDs or tape drives, if dealing with large volumes).

One Copy Off-site: Disaster Protection

The third and arguably most crucial rule for server backup: one of your backup copies must be stored off-site. This means it should be located in a geographically distant location from your primary VPS. If your main data center suffers a natural disaster (fire, flood, earthquake) or a major power outage, your local backup copy stored in the same data center will also be lost. Keeping a copy in a different region or even country ensures that even with the complete destruction of your primary site, you can still recover your data.

To implement this, you can use another Valebyte VPS in a different data center, cloud storage, or even a physical server at home, if the data volume allows.

What Exactly Should You Back Up on Your VPS?

Before configuring automated VPS backups, it's crucial to clearly define which data is critically important and requires backup. Errors at this stage can lead to incomplete or entirely useless restorations.

System Files and Configurations

While the operating system can be reinstalled, manually configuring all services and configuration files is time-consuming and prone to errors. Therefore, it's important to back up:

• Service configuration files: /etc/nginx/, /etc/apache2/, /etc/php/, /etc/ssh/, /etc/fail2ban/, /etc/systemd/, as well as VPN configurations if you use them. For example, there are specific considerations for automating VPN config backups.
• User configurations: /home/$USER/ (especially .bashrc, .profile, .ssh/, and other hidden files).
• Scripts and executables: /usr/local/bin/, /opt/, if your unique scripts or applications are stored there.
• List of installed packages: While not files themselves, a list of packages (e.g., dpkg --get-selections for Debian/Ubuntu) can help quickly restore your environment.

User Data and Applications

This is typically the largest and most frequently changing part of your data:

• Websites: /var/www/html/ or other directories where your website files are located (CMS, static files, user-uploaded media).
• Application files: If you have custom applications, their code and data.
• User uploads: Everything users upload to your server.
• Logs: /var/log/. While not always necessary to back up constantly, having them for the past few days can be useful for debugging after restoration.

Databases: The Heart of Any Project

Databases are arguably the most sensitive component of any system. Backing them up requires a special approach to ensure consistency, especially under load. We'll cover this in more detail in a separate section, but it's important to remember that simply copying database files (e.g., /var/lib/mysql/) without stopping the DBMS or using specialized utilities almost always results in an inconsistent backup.

How to Implement Automated VPS Backups: Restic and Borg Backup

For incremental backups with deduplication and encryption, which are standard for modern server backups, excellent Open Source tools are available. Among them, Restic and Borg Backup particularly stand out.

Restic: Incremental Backups with Deduplication and Encryption

Restic is a modern, fast, and secure backup tool. It supports incremental backups (copying only changed parts of files), data deduplication (not storing identical blocks multiple times), encryption of all data and metadata, and a variety of storage backends (local disk, SFTP, S3, Backblaze B2, and others). Its ease of use and high performance make it an excellent choice for VPS backups.

Key Restic Commands:

Initialize repository (one-time):

restic init --repo sftp:[email protected]:/path/to/repo

or for S3-compatible storage:

export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
restic init --repo s3:s3.amazonaws.com/your-bucket-name

Create backup:

restic backup /var/www/html /etc /home --repo sftp:[email protected]:/path/to/repo

Check repository for errors:

restic check --repo sftp:[email protected]:/path/to/repo

Clean up old backups according to policy (e.g., 7 latest daily, 4 latest weekly, 12 latest monthly, 1 yearly):

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 1 --prune --repo sftp:[email protected]:/path/to/repo

You can read more about installing and configuring Restic in our article Restic on VPS: Installation, Configuration, and Maintenance.

Borg Backup: Power and Flexibility for Server Backups

Borg Backup (or simply Borg) is another powerful tool, similar to Restic but with a slightly different architecture and feature set. It also offers incremental backups, deduplication, compression, and encryption. Borg performs particularly well with large data volumes and provides flexible repository management capabilities. It is often used for server backups where maximum disk space efficiency is required.

Key Borg Commands:

Initialize repository:

borg init --encryption=repokey-blake2 [email protected]:./repo

Create backup:

borg create --stats --compression lz4 [email protected]:./repo::"{hostname}-{now}" /var/www/html /etc /home

List archives:

borg list [email protected]:./repo

Clean up old backups:

borg prune -v --list --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 1 [email protected]:./repo

Scheduling Backups with Cron

To ensure automated VPS backups run regularly, you need to configure a task scheduler. In Linux, Cron is most commonly used for this. Open crontab for editing:

crontab -e

Add lines for daily backups (e.g., at 3:00 AM) and weekly cleanup of old archives (e.g., every Sunday at 4:00 AM):

0 3 * * * /usr/local/bin/backup_script.sh > /var/log/backup.log 2>&1
0 4 * * 0 /usr/local/bin/cleanup_backup_script.sh > /var/log/cleanup_backup.log 2>&1

Don't forget to create executable scripts backup_script.sh and cleanup_backup_script.sh, which will contain the Restic or Borg commands, as well as environment variable exports (e.g., repository passwords, to avoid storing them directly in crontab). Be sure to protect these scripts and password files from unauthorized access.

Consistent Database Backups on Your Server: MySQL/PostgreSQL Under Load

Backing up a database on a server, especially one under constant load, requires special attention. Simply copying database files can result in an inconsistent dump that cannot be restored or will contain corrupted data.

MySQL Dumps with mysqldump

For MySQL, the most common and reliable method for creating a consistent dump is the mysqldump utility. The key parameter for ensuring consistency under load is --single-transaction. This parameter creates a dump that "sees" the database at a specific point in time, even if changes are occurring simultaneously. This is achieved by using transactions and InnoDB-level locks.

mysqldump -u root -pYOUR_PASSWORD --single-transaction --databases db_name1 db_name2 > /path/to/backup/db_backup_$(date +%F).sql

If you want to back up all databases:

mysqldump -u root -pYOUR_PASSWORD --single-transaction --all-databases > /path/to/backup/all_db_backup_$(date +%F).sql

After creating the dump, this .sql file can be compressed (e.g., with gzip) and added to your Restic or Borg repository.

mysqldump -u root -pYOUR_PASSWORD --single-transaction --all-databases | gzip > /path/to/backup/all_db_backup_$(date +%F).sql.gz

PostgreSQL Backup with pg_dump

For PostgreSQL, the pg_dump utility is used. It also creates consistent dumps by leveraging PostgreSQL's transaction capabilities. By default, pg_dump operates in a mode that guarantees consistency, so additional flags like --single-transaction in MySQL are not required.

pg_dump -U postgres db_name > /path/to/backup/pg_db_backup_$(date +%F).sql

For backing up all databases:

pg_dumpall -U postgres > /path/to/backup/pg_all_db_backup_$(date +%F).sql

As with MySQL, the resulting .sql file is recommended to be compressed and then included in your general Restic/Borg backup.

pg_dump -U postgres db_name | gzip > /path/to/backup/pg_db_backup_$(date +%F).sql.gz

The Importance of Consistency

Consistency means that the data in the backup represents a logically connected and complete set of information that can be restored and used without errors. For databases, this is critically important: an inconsistent dump can contain partial records, unfinished transactions, or corrupted indexes, rendering it useless. Always use specialized DBMS utilities to create dumps, rather than simply copying data files.

Backup Storage and Rotation: Where and For How Long?

Choosing storage locations and defining a rotation policy are key aspects of implementing the 3-2-1 strategy. Proper storage ensures data availability, while smart rotation helps save space and provides recovery points for different time periods.

Choosing Storage Locations: From S3 to Another VPS

Various options can be used for storing backups, adhering to the rule of "two different media types and one copy off-site":

1. Another Valebyte VPS: An excellent option for implementing an off-site copy. You can rent an inexpensive VPS with a large HDD disk in a different data center and set up an SFTP server or a Borg/Restic server on it. This gives you full control over your data and infrastructure. We previously wrote about how to choose a server for data storage.
2. Cloud Storage (S3-compatible): Many providers offer storage compatible with the Amazon S3 API (e.g., Backblaze B2, DigitalOcean Spaces, MinIO). This is a convenient, scalable, and relatively inexpensive option for off-site storage. Restic and Borg work excellently with S3 backends. You might also consider cloud backup services.
3. Dedicated Server for Backups (self-hosted backup target): For large data volumes or increased security requirements, you can rent a dedicated server as a self-hosted backup target. This will provide maximum performance and control.
4. Local Disk (for the first copy): You can store one backup copy on the same VPS, but on a separate logical volume or disk. This provides a quick recovery option for small files but does not protect against a complete server failure. Important: this does not replace an off-site copy!

For storing backups up to 500 GB, a VPS with 1 vCPU, 2 GB RAM, and a 500 GB HDD disk is sufficient.

Backup Data Volume	vCPU	RAM	Disk	Port	Price (approx., Valebyte)
Up to 100 GB	1	1 GB	100 GB HDD	1 Gbps	from $5/mo
Up to 500 GB	1	2 GB	500 GB HDD	1 Gbps	from $15/mo
Up to 2 TB	2	4 GB	2 TB HDD	1 Gbps	from $30/mo
Over 2 TB (with deduplication)	2-4	8 GB	4 TB HDD	1 Gbps	from $50/mo

Rotation Policy: Grandfather-Father-Son (GFS)

A rotation policy defines how many backup versions are kept and for how long. One of the most popular and effective schemes is Grandfather-Father-Son (GFS):

• Son (Daily): Keep the last 7-14 daily backups. This allows recovery to any day within the last one to two weeks.
• Father (Weekly): Keep the last 4-8 weekly backups (typically the backup made on Sunday). This provides the ability to revert to data states from the last one to two months.
• Grandfather (Monthly/Yearly): Keep the last 12 monthly backups and several yearly ones. This is useful for long-term data retention, auditing, or recovery from very old errors.

Tools like Restic and Borg have built-in functions to implement GFS-like policies using the forget and prune commands.

Verifying Backups by Restoration: Regular Drills

This is the most important section of the article. As previously stated, a backup that has never been restored is not a backup. Regularly verifying the functionality of your backups is not an option, but a mandatory requirement for any reliable backup strategy.

Why "Dry Runs" Are Not Enough

A "dry run" check (e.g., restic check or borg check) confirms the integrity of the backup repository: that all data blocks are present, undamaged, and can be decrypted. This is an important step, but it doesn't guarantee that a working system can be assembled from this data. A check does not account for:

• Correct file paths after restoration.
• Database consistency, if it was dumped incorrectly.
• The presence of all necessary configuration files and dependencies.
• Application functionality after restoration.
• The time required for a full recovery.

Only a full deployment of the backup onto a clean system can provide confidence in its functionality.

Step-by-Step Plan for Test Restoration to a Clean VPS

It's recommended to conduct such drills at least once per quarter. For this, you'll need a clean VPS, preferably with a configuration similar to your main server, or with a similar OS.

1. Prepare a test VPS: Rent a new, minimal VPS (e.g., 1 vCPU, 2 GB RAM, 20 GB NVMe disk) for a few hours or days. Install the same operating system on it as on your primary server.
2. Install necessary tools: Install Restic or Borg, as well as the DBMS (MySQL/PostgreSQL) and web server (Nginx/Apache) if they are used.
3. Restore data:
   • Connect to the backup repository.
   • Execute the restoration command for the latest data. For example, with Restic:

     restic restore latest --target /tmp/restore --repo sftp:[email protected]:/path/to/repo

   • Uncompress and import the database:

     gunzip < /tmp/restore/path/to/db_backup.sql.gz | mysql -u root -pYOUR_PASSWORD restored_db_name

   • Copy the restored files to their respective directories (e.g., /var/www/html/, /etc/).
4. Verify functionality:
   • Start all services (web server, DBMS, applications).
   • Check website or API availability.
   • Attempt to log into applications and test functionality.
   • Ensure all configurations have been applied correctly.
   • Check logs for any errors.
5. Document: Document the entire restoration process, including commands, execution time, and any issues encountered. This will be your "survival guide" in case of a real disaster.
6. Destroy the test VPS: After successful verification, delete the test VPS to avoid unnecessary costs and potential vulnerabilities.

Such drills can also help you estimate the time required for recovery, which is critically important for planning your RTO (Recovery Time Objective).

Automating Verification: Is It Possible?

Fully automating backup verification by restoration is complex due to numerous nuances (OS deployment, network configuration, application startup). However, parts of the process can be automated:

• Deployment scripts: Use Ansible, Docker, or other tools to quickly deploy a clean environment and install dependencies on the test VPS.
• Post-restoration tests: Write scripts that automatically check web server availability, database functionality (simple queries), and the presence of key files.

Even partial automation will significantly reduce the time and effort required for regular checks. This is also useful for backing up and migrating applications to another VPS.

Common VPS Backup Failures and How to Avoid Them

Even with a good strategy and tools in place, common mistakes can negate all backup efforts.

Full Disk and Forgotten .env Files

• Full Disk: One of the most common problems. If the disk storing temporary dumps or the backup repository itself fills up, backup scripts start failing or operating incorrectly.
  • Solution: Regularly monitor free disk space (e.g., with Zabbix or Prometheus) and configure backup rotation using restic forget --prune or borg prune.
• Forgotten .env or other environment variables: Many applications use .env files to store sensitive data (API keys, DB passwords). If you only back up application code but forget the .env file, the application won't start after restoration.
  • Solution: Include all critically important configuration files, including .env, in your list of directories to back up. Ensure they are encrypted within the backup repository.

Backing Up to the Same Server: False Security

Storing the only copy of your backup on the same VPS you are backing up is equivalent to having no backup at all. If the server fails (hardware malfunction, hack, deletion), you lose both your primary data and its backup copy.

• Solution: Always have at least one backup copy off-site from the primary server, as required by the 3-2-1 strategy. Use another VPS, cloud storage, or a dedicated backup server.

Expired Encryption Key or Forgotten Password

Encryption is excellent for security, but only if you can decrypt the data. A lost or forgotten password/encryption key renders your backups useless.

• Solution: Store your password or encryption key in a secure location, separate from the server (e.g., in a password manager, on an encrypted USB drive, or printed and stored in a safe). Never keep it on the same server as your backups. Regularly test the ability to decrypt data by restoring small files.

Outdated Configurations and Dependencies

Over time, server configurations change, new software versions appear, and new packages are installed. If your backup script isn't updated, it might miss new important files or back up outdated configurations.

• Solution: Regularly review and update your backup scripts. Ideally, use configuration management systems (Ansible, Puppet, Chef) to automatically include new directories in your backup. After every significant change on the server (e.g., installing a new web server or DBMS), perform a test restoration to ensure the new component is correctly backed up and recoverable.

Frequently Asked Questions

What disk space is needed for VPS backup?

The disk space needed for VPS backup depends on your data size and rotation policy. For a single VPS with 100 GB of data and storing 7 daily, 4 weekly, and 12 monthly copies, accounting for deduplication, you might need 150 GB to 300 GB of disk space on a remote server. Restic and Borg significantly save space through deduplication, so the actual volume will be less than the sum of all copies.

How often should I back up my database on the server?

The frequency of database backups on your server is determined by your RPO (Recovery Point Objective) – the maximum acceptable amount of data loss. For most web applications, daily backups are recommended, while for high-load systems with critical data, hourly or even continuous backups using replication and WAL archiving may be necessary. For example, for an online store processing 1000 orders per hour, losing one hour of data could be critical.

Can I use Google Drive or Dropbox for backup storage?

Theoretically, yes, but it's not the best choice for commercial VPS backups. The main reasons are: low performance, lack of direct support for tools like Restic/Borg (requiring additional workarounds), and potential data privacy issues, as these services are not designed for such scenarios. For professional use, it's better to choose S3-compatible storage or another VPS. For personal needs and small volumes (up to 5 GB), it might be acceptable.

How much does a test VPS for backup verification cost?

The cost of a test VPS for backup verification can vary, but it typically involves minimal plans that can be rented for a short period. At Valebyte, for example, a basic VPS with 1 vCPU, 2 GB RAM, and a 20 GB NVMe disk might cost from $5-10 per month. If you rent it for only a few hours for verification, the overall expenses will be minimal, but the benefits of such a check are incomparably higher.

Conclusion

A reliable VPS backup is not just about having data copies; it's a comprehensive strategy that includes the 3-2-1 scheme, using proven tools like Restic or Borg, consistent database backups, and most importantly, regular restoration verification. Never rely on a backup you haven't tested by restoring it to a test server. Invest time and resources into building a resilient backup system, and your project will be protected from most unexpected failures.