A VPS gives you full control of the server, which means backups are your job too. Here is what to back up, the 3-2-1 rule on a VPS, how to automate the schedule, and why a restore drill is the only real proof.
A VPS backup is a copy of your server's data stored somewhere the server itself cannot reach, so that when the server fails, is deleted by mistake, or is encrypted by ransomware, you can bring the same data back on a fresh machine. On shared hosting the provider takes those copies for you; on a VPS you control the whole stack, so the responsibility for backups, and for recovering from them, moves to you. The practical standard is the 3-2-1 rule - three copies of the data, on two different storage types, with one copy off-site - and the only proof any of it works is a restore you have actually run.
On shared hosting the provider snapshots the whole machine, and you open a support ticket when something breaks. A VPS removes that ceiling: you choose the operating system, the database, the firewall and the update schedule, which is exactly the point of having one - but it also means nobody is taking a copy on your behalf. The provider still protects the hardware, and a good one survives a failed drive without you noticing, yet that only covers the physical layer. It does not cover the operator who installs an update that breaks the database, the script that overwrites the wrong directory, the attacker who encrypts everything and demands a ransom, or the compromised provider account through which a whole project vanishes. Those four scenarios share one trait: they are invisible to the datacenter, and they all end the same way unless a copy exists somewhere else.
The rule is three copies of the data, on two different media, with one off-site, and it survives because it is simple and it covers every single-point failure. On a VPS it maps directly onto infrastructure you already have. Copy one is the live server itself. Copy two is a second copy on different storage in the same project - a detached volume snapshot, a database dump written to an object-storage bucket, or a backup service inside the same provider but on separate disks. Copy three is the off-site copy, and "off-site" should mean a different failure domain entirely: another provider, another datacenter, or an object-storage account in a separate region. Two media matters because a whole storage array can fail; one location matters because a whole account or provider can fail. Two numbers decide the shape of the whole setup: your recovery point objective, the amount of data you can afford to lose measured in time, and your recovery time objective, how long the business can survive without the service. Answer those two questions first and every backup decision afterwards makes itself.
Not everything on a server needs a copy, and treating it all equally is how backup budgets explode. Databases come first, because they hold the work: take a logical dump every night with pg_dump or mysqldump - a single compressed file that restores anywhere - and for larger databases add continuous point-in-time recovery so a bad import can be rolled back to the hour rather than to last midnight. Application code does not need backing up, because the repository is the backup; deploying from git means rebuilding the application is a single command. What does need copying is everything the repository cannot recreate: uploaded files and user media, environment files holding secrets and third-party keys, nginx and service configuration, cron schedules and the backup script itself. Certificates and DNS records belong on the list too, since a domain whose records are lost can take days to rebuild. Keep the secrets encrypted at rest wherever they are stored - a backup of an .env file sitting in a public bucket is a data breach waiting to be found.
A backup that depends on a human remembering will be forgotten on the exact day it matters. Automate it and make the automation honest: run the job from cron or systemd on a fixed schedule, have every step write to a log, and crucially have the script exit non-zero when any step fails, then send that exit code somewhere a human reads - an email, a chat channel, a monitoring system. A backup job that silently produced an empty file for six months is a classic incident postmortem, and the exit code is the cheap guard against it. Add integrity checks: verify the dump is not empty, check the archive checksum, and confirm the off-site copy actually landed by reading the bucket listing rather than trusting the upload command. Then set retention deliberately instead of keeping everything forever - a grandfather cycle of daily copies for a week, weekly copies for a month, and monthly copies for a year covers every realistic need at a fraction of the storage cost, and it forces old data to age out rather than accumulate until the budget quietly doubles.
A backup is a theory until it has been restored. Once a quarter, pick a recent copy, provision a throwaway server of the same size, and restore the whole stack from nothing: the application, the configuration, the database, the uploads. Time the exercise, because a backup that takes nine hours to restore is a different proposition from one that takes twenty minutes, and the gap is only visible when you measure it. Then compare real records against the restored data - a total, a row count, a recent transaction - because a restore that completes with last week missing is not a success. When the drill is done, write down what happened in a runbook that lives off the server: the commands in order, the credentials source, the DNS records to flip, and who does each step. A runbook stored on the machine it rescues is useless precisely when it is needed, and a calm engineer with a tested runbook recovers in an hour what a panicked one rediscovers in a day.
Automated daily backups are the minimum for a business site, with database dumps taken more often if the data changes constantly - every few hours, or continuous point-in-time recovery if losing a whole morning of transactions would hurt. The right interval is set by your recovery point objective: the answer to "how much new work can we afford to lose?" measured in hours, not by a rule of thumb.
Provider backups are a useful first layer, and on a good platform they are reliable, but they are not a disaster-recovery plan. They usually live in the same account and the same failure domain as the server itself, they are often an extra cost that gets dropped when budgets tighten, and if the provider account is compromised, the server and its backups are gone together. Keep the provider backup, and add one copy you control outside that account - that is the off-site copy the 3-2-1 rule exists to enforce.
You restore them. A backup job reporting success only proves the script ran and a file was written; it says nothing about whether the file is complete, uncorrupted, or restorable. The only reliable test is a restore drill into a throwaway environment - provision a fresh server, rebuild the stack from the backup, and compare real data against the original. Run it at least once a quarter, and time it, because a restore that works but takes a whole day changes your recovery plans.
VPS servers deployed with a working recovery story - daily database backups, off-site copies and tested restores as part of the managed service.
The prevention half of this guide - SSH keys, a firewall, automatic updates and TLS, so fewer incidents ever reach the backup.
Where your server sits decides its latency and its failure domain - the same question to ask before placing an off-site backup copy.
EGYmass handles hosting, security, and ongoing management - so you can focus on your product.
Get a Free Consultation