Backing up a VPS is different from backing up a hosting account: there is no control panel doing it for you, and the machine itself is part of what you might need to recover. The disaster-recovery thinking: how long a restore takes, what order to recover in, is covered in Backups and Disaster Recovery for Dedicated Servers.
This article is about the practical arrangement on a VPS.
Snapshots and backups are different products
Providers offer snapshots, and they are genuinely useful for the wrong problem.
A snapshot is an image of the whole volume at a moment. Taking one is instant, restoring is fast, and it lives on the same platform as your server, so it survives your mistake and not the platform's.
A backup is a copy that exists somewhere else entirely.
Use snapshots before you change something risky: an upgrade, a configuration change, anything you might want to undo in five minutes. Use backups for everything else.
What actually needs backing up
Less than the whole disk, and knowing which parts makes a restore faster.
Databases, dumped rather than copied as files. A database file copied while the service is running can be inconsistent, and the inconsistency is invisible until you restore it.
Application files and uploads. The part that cannot be reinstalled.
Configuration: the web server, PHP, the firewall, cron jobs, and anything under /etc you changed.
The operating system itself does not need backing up if you can rebuild it, and being able to rebuild it is worth confirming rather than assuming. How to Manage Multiple Servers Consistently deals with writing the build down.
Dump databases properly
mysqldump --single-transaction --routines --all-databases > /backup/db.sql
--single-transaction gives a consistent snapshot without locking the tables, which matters on a live site. --routines includes stored procedures, which a plain dump omits and nobody notices until something calls one.
Compress it afterwards. Database dumps compress extremely well, and the difference in transfer time off the server is substantial.
It has to leave the machine
A backup on the same VPS is not a backup. If the volume is lost or the account is suspended, both copies go together.
Push it to object storage, another server, or a backup service. Pull-based arrangements, where the destination fetches from your server, are worth preferring, because a compromised server cannot then delete its own backups.
That last point is not theoretical: ransomware looks for reachable backups first, and credentials stored on the server for pushing to a destination are credentials an attacker inherits.
Automate it, and make it complain
A manual backup is a backup that stops when you get busy.
Schedule it, and make the job report failure somewhere you read. A backup job that has silently failed for a month is the normal way people discover they have no backups; the schedule looked fine, nothing said otherwise.
Check the size as well as the exit code. A backup that completes and is a tenth of its usual size is a backup of almost nothing. How to Schedule Jobs with Cron and Systemd Timers explains why cron fails quietly.
Keep enough history
Not just the most recent copy.
A compromise is usually discovered a fortnight after it happened, and a backup taken after that point contains it. A single nightly copy overwritten each night is one bad day from useless.
Daily for a week, weekly for a month, monthly beyond that is a reasonable shape, and compressed dumps make the storage cost small.
Restore, do not assume
Restore to a second VPS; a small one, hourly-billed, destroyed afterwards.
That finds the problems that only exist at restore time: a dump too large to import in the browser, a database user that did not come across, a configuration file referencing a path that does not exist on a clean machine.
Do it once a quarter. It converts your backup from an assumption into a known quantity, and it is the only part of this article that proves the rest worked.
Time the restore, and write the number down
How long it actually takes to go from a new VPS to a working site.
That number is what you tell people during an outage, and it is what tells you whether the arrangement is good enough. A four-hour restore is fine for a brochure site and not for a shop, and knowing which you have is only possible if you have measured it.
Do not forget what is not on the server
DNS records, the domain registration, and any external service the site depends on.
A perfect restore onto a new machine still leaves you editing DNS, and a zone you never recorded is one you rebuild from memory. Keep a copy of it alongside the backups. What to Do Before You Cancel or Move Hosting deals with what else is not in any backup.
For backups that run repeatedly, copying only what changed turns an hourly job into a cheap one. How to Use rsync for Transfers and Backups goes over it, including the flag that has emptied people's backups.
Confirm the archive is readable, not merely present
A backup job that reports success has proved it finished, not that it produced something usable.
tar -tzf /backup/site-$(date +%F).tar.gz >/dev/null && echo "arsiv saglam" gzip -t /backup/db-$(date +%F).sql.gz && echo "dump saglam" tail -2 /backup/db.sql | grep -qi 'dump completed' && echo "dump tam"
Reading the whole archive without extracting it catches a truncated write or a transfer that stopped partway. Checking the last line of a database dump catches the more insidious case, where the export was interrupted and the file looks entirely normal until the missing half of it matters.
Put these three checks in the job itself rather than running them by hand. A backup that fails its own verification should produce the same noise as a backup that did not run.
Watch the size, not only the timestamp
The most common silent failure is a backup that keeps running and captures less than it used to.
ls -l --time-style=+%F /backup/*.tar.gz | awk '{printf "%s %.0f MB\n", $6, $5/1048576}' | tail -10
A file that suddenly halves is the signal. It usually means an exclusion was added, a database was skipped because the connection failed, or the run was cut short when the destination filled.
None of those produces an error, because from the job's point of view it did what it was told. Compare against last week rather than against zero, and alert on a drop as well as on an absence.
Know which restore you are actually planning for
Backups are designed for one scenario and then used for a different one, and the mismatch shows at the worst moment.
Deleting a file by accident needs yesterday's copy and takes minutes. A failed disk needs the whole machine rebuilt and takes hours. A compromise needs a copy from before the intrusion, which may be weeks old, and that determines how much history you must keep.
The third case is the one that defeats short retention. Seven days of backups is ample for the first two and useless for the third, since an intrusion discovered on day ten has been captured faithfully in every copy you hold. Backup strategy for reseller accounts goes into the retention decision.