← Back to Blog

How to Restore a VPS Backup: Weekly Copies, Daily Restore Points and Your Own Off-Site Copy

Published · by Leo Gashi, RS Computers

Backups VPS Disaster recovery

To restore a VPS backup at RS Computers, open the server in the client area, go to its backups, pick the copy you want and click Restore. The whole server goes back to the moment that copy was made, usually within minutes, and you do not open a ticket. Every server in Amsterdam, Dublin and Prishtina gets a free backup of the whole machine once a week, and the last two are kept. If a week is too long a gap for your data, the daily backups add-on keeps seven daily restore points instead.

That is the short version. The rest of this guide is about the part most people learn the hard way: what a server backup does and does not save you from, how to restore without losing the work you did since the last copy, and which small extra copy you should still keep yourself.

Key facts:

What a server backup covers, and what it does not

A server backup is a copy of the entire virtual disk: the operating system, installed packages, configuration, your websites, databases and logs, all in one piece. That makes it the right tool for the big accidents. An update that leaves the server unable to boot. A plugin that turns out to be malware. A rm -rf in the wrong folder. A firewall rule that locks you out and that you cannot undo from the console.

It is the wrong tool for small, recent losses. If a customer uploaded an invoice this morning and someone deleted it at lunch, the last weekly copy does not contain it, and restoring the whole server to fetch one file would throw away everything else from the past few days. For that kind of loss you want file-level or database-level copies, which you make yourself and which we cover further down.

It also lives with the same provider as the server. That is fine for accidents, and it is why the 3-2-1 rule asks for one more copy somewhere else.

Weekly or daily: which one does your server need?

Ask yourself one question: how much work could you afford to lose? With weekly copies the honest answer is "up to a week". With the daily add-on it is "up to a day".

What the server doesWeekly copies enough?Why
Static website, landing pagesUsually yesContent rarely changes, and the source files often live in Git anyway
Development, staging or CI runnerYesThe real copy of the code is in your repository
VPN endpoint, monitoring probeYesConfiguration changes once and then stays
Online shop, booking siteNo, add dailyOrders and customer accounts arrive every day
Database server, CRM, ERPNo, add dailyA week of records is too much to type in again
Mail server, n8n automationsNo, add dailyMailboxes and workflow state change by the hour

You switch the daily add-on on or off from the client area whenever you like, so a shop can turn it on before a sale season and keep it from then on.

How to restore a backup without losing recent work

  1. Find out when things went wrong. Look at your logs or think back: was the site still fine on Tuesday? The backup list in the client area shows when each copy was taken, so you need a copy from before the problem started.
  2. Save what changed since that copy, if the server still runs. Copy recent uploads, new database records or edited files to your own computer first. From a terminal on your computer, replace the address with your server's IPv4 address and the folder with your own:
    # on your own computer, not on the server
    rsync -avz root@203.0.113.10:/var/www/ ./before-restore-www/
    You should see a list of file names scrolling past and a summary line with the total size at the end. On Windows, the same works from WSL, or copy the folder with WinSCP.
  3. Start the restore. In the client area, open the server, go to its backups, choose the copy from step 1 and click Restore. Confirm when asked. The server stops, its disk is replaced with that copy, and it starts again by itself.
  4. Check that the server is healthy. Log in again over SSH and run:
    # as root, on the restored server
    uptime
    systemctl --failed
    df -h /
    journalctl -p err -b --no-pager | tail -n 20
    uptime should show that it booted a few minutes ago, systemctl --failed should list "0 loaded units", df -h / shows disk space, and the last command shows the newest errors since boot. On Windows Server, connect over RDP and look at the System log in Event Viewer.
  5. Put back the recent work from step 2, one folder at a time, and check the site or app after each one. If the problem came back with one of those files, you have found the cause.

If the server will not boot at all, skip step 2 and restore straight away; that is exactly the situation the weekly copy is for. If you are not sure which copy to pick, message us on Telegram before you click.

Databases: one small extra step

A whole-server backup copies the database files the way they are on disk at that moment. Most databases recover cleanly from that, the same way they recover after a power cut, but a busy one may need a few seconds of repair when it starts. A logical dump is the belt to go with those braces: a plain file that any version of the database can load.

# as root: MariaDB or MySQL, consistent while the site keeps running
mysqldump --single-transaction --all-databases > /root/db-nightly.sql

# as root: PostgreSQL, all databases in one file
sudo -u postgres pg_dumpall > /root/pg-nightly.sql

Run the one that matches your database once by hand; it prints nothing when it works, and ls -lh /root/*nightly.sql then shows a file of a sensible size. To make it nightly, open the root crontab with crontab -e and add a line such as 30 2 * * * mysqldump --single-transaction --all-databases > /root/db-nightly.sql. Because the dump sits on the server disk, the weekly and daily server backups pick it up too.

The copy you keep yourself

Our backups protect you from accidents on the server. They do not protect you from losing access to your account, a stolen password that lets someone delete both the server and its backups, or the day you simply want your data somewhere else. That is the "one copy off-site" in 3-2-1, and CISA adds "offline" and "encrypted" to it for a reason: ransomware goes looking for every backup it can reach.

The cheapest way to get there is a second small server in another city that only accepts new backups and cannot delete old ones. Our guide to off-site backups with restic or Borg sets that up step by step, for example from Amsterdam to Dublin, or from Prishtina to Amsterdam. Test it once: restore one folder from it to a temporary directory and open a few files. A backup you have never restored is a hope, not a backup.

Questions people ask

Are the weekly backups really free in every location?

Yes. Every VPS and VDS plan in Amsterdam, Dublin and Prishtina includes a free weekly backup of the whole server, and the last two copies are kept. Only the daily add-on costs extra; its price per plan is listed on the location pages.

Can I restore a single file from the panel?

No. The client area restores the whole server. For single files, keep your own file-level backups with restic or Borg, or the database dumps shown above, so you can pull one file back without touching the rest of the server.

How long does a restore take?

It depends on how much data is on the disk. A small server with a few gigabytes is usually back within minutes; a VDS with hundreds of gigabytes takes longer. The server starts again by itself when the restore is done.

Do I need to set anything up?

No. The weekly backups run on their own from the day your server is created. You only decide whether you want the daily add-on, and whether you keep your own off-site copy as well. Our VPS and VDS plans page shows the sizes and prices in all three cities.

← All articles

Chat on Telegram