Backups are one of those things everyone assumes they have until they actually need one. A corrupted disk, an rm in the wrong directory, ransomware or a deploy that wiped data: what separates a scare from a disaster is having a recent, complete and restorable copy.
The 3-2-1 rule explained
- 3 copies of your data (the original plus two more).
- 2 different media or systems (for example, the server disk and external storage).
- 1 offsite copy, with another provider or in another region.
A backup stored on the same disk as the server is not a backup: if the disk fails or the server is compromised, you lose both.
What a VPS backup must include
| Item | Examples | Watch out for |
|---|---|---|
| Databases | MySQL/MariaDB, PostgreSQL | Use a consistent dump; never just copy the files of a running database. |
| Application files | /var/www, uploads, storage/ | User uploads are not in Git. |
| Environment variables and secrets | .env, API keys | Store them encrypted. |
| System configuration | Nginx/Apache, PHP-FPM, cron, systemd | Without it, rebuilding the server takes hours. |
| Certificates | /etc/letsencrypt | Avoids mass reissuance and rate limits. |
How to create consistent dumps
# MySQL / MariaDB (InnoDB) without locking the database
mysqldump --single-transaction --routines --triggers --all-databases | gzip > mysql-$(date +%F).sql.gz
# PostgreSQL
pg_dump -Fc -d meu_banco -f meu_banco-$(date +%F).dumpHow often should you back up?
Define two numbers for each system:
- RPO (Recovery Point Objective): how much data you can afford to lose. An RPO of 1 hour requires hourly backups.
- RTO (Recovery Time Objective): how quickly the system must be back online.
| System type | Database | Files | Suggested retention |
|---|---|---|---|
| E-commerce / SaaS | Hourly | Daily | 7 daily + 4 weekly + 3 monthly |
| Company website / blog | Daily | Weekly | 7 daily + 4 weekly |
| Staging | Weekly | Weekly | 2 to 4 copies |
The step almost everyone skips: testing the restore
A backup that has never been restored is just an assumption. At least once a month:
- Restore the dump into a temporary database and check the row counts of the main tables.
- Make sure the compressed file is not corrupted (
gzip -t arquivo.sql.gz). - Time the process: that is your real RTO.
How EzServer automates this
- Automatic discovery of applications and databases on every server, so nothing gets left out by accident.
- Scheduled backups of files and databases, with dump verification.
- Retention policy and cleanup of old copies, so the backups themselves don't fill up the disk (a more common problem than you might think).
- All in one dashboard, across multiple servers at once.
Beware of a classic mistake: backups written to
/tmp or to the same disk, with no retention, fill up the server and take the application down. Always cap the number of local copies.