On this page
The Backups tab lists the snapshots taken of your server on the schedule that comes with your plan. It is a listing and nothing else: there is no control to take a backup, restore one, or delete one. Restores are done by the support team on request.
What the tab shows
Each entry in the list carries four things:
- The backup's name, or
Backup #followed by its ID when it has no name. - How long ago it was taken.
- Its size.
- A status badge reading Completed, Failed, In progress, or Unknown.
On a server that has not finished provisioning, the tab reads "Backups become available once your server is provisioned" instead of a list.
An empty list is not an answer
If the tab shows No backups yet, that can mean either of two things: no backup exists, because your plan does not include scheduled backups or the first one has not run, or the listing could not be retrieved at that moment. Both look identical on screen, so an empty list on its own does not tell you which you are looking at.
If it matters, ask rather than assume. The empty state carries a link labelled Ask us about adding backups, which opens a ticket with this server already attached, and the team can confirm whether the server has a backup schedule and what the most recent snapshot is.
Asking for a restore
Restores go through support. Open a ticket and put enough in it that the request can be actioned without a round trip:
- Which server. Its name in the panel and its primary IPv4 address, since two servers on the same plan can carry the same name.
- Which backup. The name shown in the list, or its
Backup #ID, plus the date and time shown against it. - What you are trying to recover. This lets the team confirm the snapshot you picked is the one that actually holds it.
- When the server can be interrupted, if there is a window you need kept clear.
Taking your own backups
The panel gives you a list, not a lever. Anything you want to be able to recover yourself, on your own timing, has to be a copy you hold.
- Decide what has to survive. Usually that is your databases, your configuration files, and anything users uploaded. The operating system and packages can be installed again from scratch.
- Dump databases with the database's own tool. Copying data files while the service is running gives you a file that may not load back.
- Keep the copy somewhere else. A copy on the same disk is lost with the disk.
- Run it on a schedule, with cron or your own tooling, rather than when you remember to.
- Restore one occasionally to confirm the copies are usable. An untested backup is a guess.
- Take a fresh copy before anything destructive, including a rebuild or a plan change.
A dump and a pull, from the machine you want the copy to live on:
mysqldump -u root -p --single-transaction --all-databases > /root/dump.sqlrsync -avz -e ssh root@203.0.113.10:/root/dump.sql ./backups/