Cloud Servers
Cloud Server Backups
Every KapsuleHost Server is backed up to encrypted offsite storage once a day and kept for 30 days, and you can take an extra backup or restore one at any time from the server's own page in KPanel.
Backups are armed automatically when a server is provisioned. There is nothing to configure, no agent for you to install, and no schedule for you to set. This guide explains exactly what is captured, how to read the backup list, how to take one on demand, and what a restore does to a running server.
Where Backups Live
Backups belong to a server, so you reach them from that server rather than from the main menu:
- Sign in to KPanel.
- Click Cloud Servers in the left sidebar, then click the server you want.
- Scroll to the Backups card.
The direct address is /cloud-servers/<server-id>.
The card header shows the time of your last successful backup. Before the first one completes it shows the standing description instead: "Daily off-site backups to encrypted storage, kept for 30 days."
Cloud Servers only appears in the KPanel sidebar once your account actually has a cloud server. If you cannot see it, the account has none yet.
What Is Captured
Expand What's in your backup at the bottom of the Backups card to see the live manifest for your server. It is grouped into five categories:
| Category | Included paths |
|---|---|
| Website files | /var/www (docroot, uploads, themes, plugins) and the /root and /home directories |
| Databases | /var/lib/mysql and /var/lib/postgresql data files |
| Server configuration | /etc, plus /etc/letsencrypt certificates, /etc/ssh, /etc/ufw firewall rules and /etc/fail2ban |
| Cron jobs and system state | /etc/cron.d and the daily, hourly and weekly cron directories, /var/spool/cron user crontabs, /etc/systemd units, and a captured snapshot of your crontab, installed packages, enabled services and firewall status |
| Mail data, when mail is configured on the server |
Volatile and rebuildable paths are deliberately excluded: /proc, /sys, /dev, /run, /tmp, /var/tmp, /var/cache, container overlay storage under /var/lib/docker/overlay2, and swap files. Excluding them keeps backups small and fast without losing anything you cannot regenerate.
Backups are encrypted with a key unique to your server and written to offsite object storage. Only your panel can decrypt and restore them.
A cloud server backup captures the server. It does not capture anything that lives outside it. A managed database on another host, an external payment gateway, or a third-party service your application talks to holds its own data and must be exported separately.
Reading the Backup List
Each row in the list shows when the backup started, its size once complete, and a status pill:
| Status | Meaning |
|---|---|
| Backed up | The backup completed and is a usable restore point |
| Running | The backup is in progress |
| Failed | The backup did not complete |
Manual backups are tagged manual next to the date so you can tell them apart from the daily run. A completed backup also shows its snapshot reference, which is the identifier support will ask for if you ever need help with a specific restore.
If the most recent backup failed you get a banner on the card: "The most recent backup failed. We'll keep retrying on the daily schedule. Check disk space, or contact support if this persists." A single failure is usually a full disk. Free some space and the next scheduled run will succeed.
Taking a Backup on Demand
Take a manual backup immediately before anything risky: a major package upgrade, a database migration, a configuration change to a service you depend on, or your first attempt at something unfamiliar.
- Open the server's page and find the Backups card.
- Click Back up now in the card header.
- You get the confirmation "Backup started. It will appear in the list shortly."
- The run happens on the server in the background. Refresh the card after a few moments to see it appear as Running, then Backed up.
Large servers take longer. The size column on the finished row tells you how much was captured.
A manual backup is identified by its timestamp, not by a name you choose. Take the backup immediately before you make the change, so the times line up and you can tell at a glance which restore point is the "before" one.
Restoring From a Backup
- Find the completed backup you want in the Backups card.
- Click Restore on that row.
- Read the confirmation: "This overwrites the server's current files with the contents of the selected snapshot. Any changes made since the snapshot will be lost. The server stays online during restore."
- Click Restore to go ahead.
A restore cannot be undone. Everything written since that backup was taken is replaced by the backup's contents. If there is any chance you will want the current state back, take a fresh backup or a snapshot first, then restore.
The server stays online while the restore runs, which is what makes this useful for recovering a broken application without a full outage. Large filesystems can take a while. If the restore is still going after five minutes, KPanel tells you it "is taking longer than expected and is still running on the server" and the restore continues in the background.
Backups Compared With Snapshots
Your server has two independent safety nets, and they are good at different things.
| Backups | Snapshots | |
|---|---|---|
| Where it is kept | Encrypted offsite storage | Alongside the platform your server runs on |
| Schedule | Daily, automatic | On demand, plus automatically before every patch run |
| Retention | 30 days | Kept until you no longer need them |
| What it restores | Files, databases and configuration, in place | The entire disk, exactly as it was |
| Server during recovery | Stays online | Reboots |
| Best for | Data protection and disaster recovery | A safety net immediately before a risky change |
Use both. A snapshot before a change is the fastest way back if the change goes wrong. Backups are what protect you from problems you do not notice until days later. Cloud Server Snapshots covers the snapshot side in full.
Backups and Rebuilds
Rebuilding a server's operating system wipes the disk, including the restore tooling that lives on it. Your backup data is safe in offsite storage, but the in-panel Restore button cannot use it on a rebuilt server. Read Rebuilding Your Cloud Server in full, and download anything you need before you rebuild.
Troubleshooting
"Backups are not yet configured for this server." They arm automatically at provisioning. If a brand new server shows this, give it a few minutes; if it persists, contact us.
"No backups yet." The first backup runs automatically shortly after provisioning. You can also click Back up now rather than wait.
"Manual backup is temporarily unavailable." The panel could not reach the server to start the run. Check the server is running and reachable, then try again.
The Restore button is missing on a completed backup. Restore needs a reachable, provisioned server with the backup tooling present. A server that has been rebuilt, or that is powered off, will not offer it.
If a backup fails repeatedly and disk space is not the cause, email support@kapsulehost.com with the server name and the timestamps of the failed runs.