VPS backups and snapshots: turning on automatic backups and requesting restores

Turn on automatic backups

• In your account, click New server and choose a region, size and image.
• Turn on automatic backups under add-on options.
• The summary on the right shows the combined monthly price of the server and backups right away.
• Click Create server and pay for the chosen billing period, then pay the renewal invoice before the period ends to keep the server running.

Automatic backups are an option you choose when creating a server. To protect data on a server you already use, order a snapshot or use the in-server backups below as well. When creating a server with the API, include "backups": true in the request to turn on the same option.

Request a restore from automatic backups

Restores are handled by our support staff, who roll back to exactly the point you want. After your first payment, request it on the support page like this.

• Choose Server as the topic.
• Enter the name of the server to restore in the server name field.
• In the message, write the date and time (UTC) you want to go back to and whether to restore to the same server.

A restore replaces the server disk with its contents at backup time, so files created after that are removed. If there are recent files you want to keep, download them to your computer before you send the request. Replies appear on the support page.

Order a snapshot

• Click Order on the snapshots page.
• Choose the storage size. A size equal to or slightly larger than your server disk holds the whole disk comfortably.
• Enter the target server name in the name field so you can tell at a glance which server the snapshot belongs to. Latin letters, digits, dots and hyphens are allowed.
• When you order, pay for the chosen billing period, and once ready it appears in the product list in your account.

For servers with constant writes, such as databases, pausing the service briefly or stopping the server while the snapshot is made gives the cleanest image. To roll back to a snapshot or create a new server from it, request it on the support page with the server name and snapshot name after your first payment, and we will handle it.

Back up yourself on the server

While automatic backups and snapshots protect the whole server, in-server backups keep an extra copy of files and databases somewhere else. Following the 3-2-1 rule, three copies on two kinds of storage with one kept elsewhere, gives you the most protection.

Step 1. Bundle files and databases

mkdir -p /root/backup
tar czf /root/backup/www-$(date +%F).tar.gz /var/www
mysqldump --single-transaction --all-databases | gzip > /root/backup/db-$(date +%F).sql.gz

For PostgreSQL, bundle with sudo -u postgres pg_dumpall | gzip > /root/backup/pg-$(date +%F).sql.gz; for a Docker volume, use docker run --rm -v VOLUME_NAME:/data -v /root/backup:/out alpine tar czf /out/VOLUME_NAME.tar.gz -C /data ..

Step 2. Run it automatically every day

Open scheduled jobs with crontab -e and add the three lines below to create backup files every day at 3 a.m. (server time) and clean up files older than 7 days. Inside crontab, put a backslash before %.

0 3 * * * tar czf /root/backup/www-$(date +\%F).tar.gz /var/www
5 3 * * * mysqldump --single-transaction --all-databases | gzip > /root/backup/db-$(date +\%F).sql.gz
30 3 * * * find /root/backup -name '*.gz' -mtime +7 -delete

Step 3. Send another copy elsewhere

If backup files exist only on the same server, they can be lost along with it. Send them with rsync to a server in another region, or upload them to object storage with rclone, and you have a copy somewhere else.

rsync -az /root/backup/ backup@BACKUP_SERVER_IP:/backups/web-1/

Which method should I choose for each situation?

The three methods are strongest used together rather than as substitutes. Combine them to fit how you use your server.

• Personal blogs and small websites: turn on automatic backups when creating the server, and before big theme or plugin changes, download a WordPress export file. That is enough.
• Online stores and membership services: on top of automatic backups, create a database dump every day and send a copy to another region. You can recover order records and member data down to the hour.
• Development and test servers: keep a snapshot before big experiments, and delete it when the experiment is over to save on storage fees.
• Running several servers with the same setup: keep a snapshot of your reference server long term to bring new servers to the same state quickly.

Whatever the combination, the key is whether there is a copy outside the server and whether you have actually restored from it. Take care of these two things and you can calmly bring your service back after a sudden mistake or outage.

Think about cost as well. Automatic backups are set at 5.6% of the server price, the same amount every month, and snapshots cost only for the storage you use. In-server backups have no extra charge and use only disk space, but copies sent elsewhere need storage on the receiving side. Choose based on the size of the data you must protect and how often you need to restore, and you balance cost and safety.

Practice restores and good habits

Backups are only worth something if you can restore them. About once a month, create a small server, unpack your backup files and check that the site opens, and you will not fumble the steps when it really matters. Delete the test server as soon as you have checked.

• Right before big work, keep a snapshot or backup file.
• Put the date and server name in backup file names so you can tell at a glance which point in time they are from.
• Keep backups containing secrets, such as database passwords and API keys, only in secure places.
• Before reinstalling a server, do the data migration step in the reinstall guide first.

If disk space is too tight to keep backups for long, you can add an NVMe block disk to the server and use it as dedicated backup space. If you use Docker, also see volume management in the Docker install guide.