The first question to ask yourself
If your server disappeared right now, how long would it take you to rebuild it, and how much data would you lose? The answer defines your strategy: daily backups for an online store, weekly for a brochure site.
The 3-2-1 rule
Three copies of your data, on two different media, one of them off site. On a VPS, this means in practice: the production server, a local backup on a separate volume, and an off-site copy to object storage or another server.
What must be backed up
- The application files (code, media, configurations).
- The database, with a consistent dump — copying the raw files of an active database produces a corrupted backup.
- The server configuration files: nginx, certificates, scheduled tasks, accounts.
A backup without the server configurations forces you to rebuild everything by hand: that is where whole days are lost during a restore.
Basic backup example
mysqldump --single-transaction --routines base > /sauvegardes/base-$(date +%F).sql
The --single-transaction option avoids locking tables during the export.
Automate, then verify
Put the backup into a scheduled task, but above all: test the restore. A backup that has never been restored is an assumption, not a guarantee. Schedule a test once a quarter on a disposable server.
The most common mistake
Storing the backup on the server being backed up. It is convenient, and it is exactly what disappears together with the server. Keep at least one copy off site.
What about high availability?
Backing up is not the same as staying online. If your business cannot tolerate an interruption of a few hours, the question is not backup but architecture: multiple servers, load balancing, replicated database. Let's talk about it if that is your case.
