A failed disk is inconvenient. A failed disk combined with an untested backup is an outage that can stop a store, website, mail service, or internal application for days. This Linux backup guide is built for administrators and business owners who need a recovery process that works under pressure, not a folder full of files that may or may not restore.
The goal is not to copy every byte on a server every night. The goal is to restore the systems and data your business actually needs within an acceptable time. That requires a clear scope, more than one copy, automation, and regular restore tests.
Start With Recovery Requirements#
Before choosing a backup tool, decide what failure you are planning for. A deleted WordPress database table has a different recovery path than a compromised server, a ransomware event, or the loss of an entire VPS account.
Write down the services the server provides and what data each service needs. For a typical web server, that usually includes website files, application configuration, database contents, uploaded media, TLS certificates, scheduled task definitions, and mail data if the server handles email. Do not assume that backing up `/var/www` is enough. A WordPress site can have complete theme and upload files but still be unusable without its MySQL or MariaDB database.
Two measurements help keep backup decisions practical. Recovery point objective, or RPO, is the maximum amount of data you can afford to lose. If an ecommerce database changes throughout the day, a nightly backup may leave too large a gap. Recovery time objective, or RTO, is how quickly the service must be online again. A full disk image may be useful for a fast server rebuild, while application-level backups are usually better for restoring one database or site.
Linux Backup Guide: Use the 3-2-1 Rule#
The 3-2-1 rule remains useful because it protects against common single points of failure. Keep three copies of important data, on two different types of storage, with one copy stored offsite.
For a small business server, this might mean production data on the VPS, encrypted backups on attached or separate storage, and a second encrypted copy in a different provider account or physical location. A backup stored on the same server is not an offsite backup. It may help with an accidental deletion, but it cannot protect against a compromised host account, a provider failure, or a server-wide filesystem issue.
Snapshots have a role, but they are not a full backup strategy. Provider snapshots can speed up a rollback after a bad update, yet they often live in the same infrastructure as the original server. Treat them as a convenient recovery layer, not the only layer.
For particularly important systems, protect backup credentials as carefully as production credentials. A ransomware attacker who gains root access may try to delete accessible backups first. Immutable storage, versioned buckets, or a remote destination with restricted credentials can reduce that risk. The best option depends on your budget and hosting setup, but the principle is simple: production access should not automatically grant unrestricted backup deletion rights.
Choose Tools Based on the Data You Need to Restore#
Linux offers several dependable backup approaches. The right choice depends on file volume, database use, retention needs, and how comfortable you are managing the restore process.
`rsync` is a sensible option for copying directories efficiently to another server or mounted storage location. After the first transfer, it sends only changes, making it practical for website files, configuration directories, and user data. Use it with careful exclusions for transient data such as caches, session files, log archives already collected elsewhere, and virtual filesystems like `/proc` and `/sys`.
For backups that need deduplication, compression, encryption, and retention management, tools such as BorgBackup or Restic are usually a better fit. They store repeated data efficiently across backup runs and can encrypt data before it leaves the server. This is especially helpful for retaining many versions of large media libraries or multiple websites without paying for a complete copy each time.
Databases require separate attention. Use `mysqldump` or `mariadb-dump` for portable logical backups when databases are moderate in size and simple point-in-time recovery is not required. For larger or busier databases, consider physical backup methods and binary log retention. Logical dumps are easier to inspect and restore to another server, but they can take longer and may affect performance if poorly scheduled.
A full-system image can be valuable before major migrations or as a fast rebuild option. Still, do not make it your only backup. Restoring an entire image is often slower and less flexible than restoring the exact application files and database needed.
Build an Automated Backup Job#
Manual backups fail because people get busy. Use a scheduled job with logging, error handling, and notifications. Cron is sufficient for many servers, while systemd timers offer clearer control over missed schedules and service dependencies.
A reliable job should first create consistent database backups, then back up the resulting files along with application directories and selected configuration. Store temporary dump files in a protected directory, and remove them only after the backup tool reports success. If a database dump fails, the job should exit with an error rather than continuing as though the backup were complete.
Avoid placing passwords directly in shell scripts whenever possible. For database commands, use protected client configuration files with restrictive permissions. For remote repositories, use dedicated keys or repository credentials limited to backup operations. Keep scripts readable, but do not make them a source of exposed secrets.
Schedule frequency according to change rate. A brochure site may need one backup each night. A WooCommerce store with regular orders may need database backups every few hours, or more frequently if the cost of lost orders is high. Media files often change less often, so file backups and database backups do not always need identical schedules.
Retention also needs a deliberate policy. Keeping every daily backup forever raises storage costs and makes management harder. A practical pattern is frequent short-term backups, weekly recovery points for a few months, and monthly copies for longer business or compliance needs. Keep enough history to recover from problems discovered late, such as a corrupted file that was silently included in several recent backups.
Protect the Backup Data#
Backups contain customer data, site credentials, configuration secrets, and sometimes private documents. Encrypt them before sending them to remote storage, particularly when using third-party infrastructure. BorgBackup and Restic support encryption as part of their normal workflow. If you use `rsync`, encryption in transit through SSH is helpful, but you may also need encryption at rest on the destination.
Set permissions so only the backup account and authorized administrators can read backup archives. Do not run every backup task as root unless it must access protected system files. A separate backup user with narrowly scoped access reduces the impact of a compromised script or credential.
Monitor capacity on both the production server and backup destination. Backups often fail at the least convenient moment because a disk filled gradually with logs, old archives, or uploaded media. Alert on failed jobs, repository errors, and low free space. A successful cron entry is not proof of a usable backup.
Test Restores Before an Emergency#
A backup is only proven when it restores. Test at least one file restore, one database restore, and one full application recovery on a schedule. Use a staging server or isolated environment where possible. This protects production from accidental overwrite while confirming that the restored application can start correctly.
For a WordPress site, a useful restore test includes importing the database, restoring `wp-content`, checking `wp-config.php`, updating any environment-specific settings, and loading both public pages and the admin area. For ecommerce sites, verify products, recent orders, payment configuration, and transactional email behavior without sending test messages to real customers.
Record the actual time required. If the restore takes six hours but your business needs the site back in one hour, the backup plan needs adjustment. That may mean smaller, more frequent database backups, a prebuilt replacement server, faster storage, or a simpler deployment process.
Keep a Short Recovery Runbook#
When an incident happens, you should not have to remember repository paths, encryption keys, database commands, or DNS steps. Store a concise recovery runbook somewhere available outside the server being restored. Include the backup location, access method, key storage procedure, restore commands, service restart steps, and a contact list for hosting or domain support.
Review the runbook after every major infrastructure change. A new database name, storage provider, PHP version, or reverse proxy can turn accurate instructions into outdated ones quickly.
A disciplined backup process is one of the least visible parts of running reliable infrastructure. It earns its value when a bad update, deleted directory, or failed server becomes a controlled repair instead of an expensive scramble. Set aside time for the first restore test this month. That result will tell you more about your protection than any backup dashboard ever can.