How to Restore a VPS from a Snapshot in the Hostini Panel: Complete Guide
Learn how to restore your VPS from a snapshot in the Hostini panel in minutes, when to use a snapshot vs a traditional backup, and how to avoid data loss during the operation.
A VPS snapshot is the right tool for three specific situations: a system update that might break, deploying a new version of an application, and a critical configuration change (firewall, network, kernel). In any of these scenarios, taking a snapshot beforehand takes 10 seconds and gives you an instant “undo” button. Restoring takes the same time.
The most common confusion among beginners is treating a snapshot as a backup. It is not. A snapshot lives on the same storage as the VPS — if the physical disk fails, the snapshot goes with it. A snapshot is operational safety for short-term changes; a traditional backup is protection against disaster. This guide focuses on restoring from a snapshot through the Hostini panel, but along the way it makes clear when you should be using something else.
The tutorial assumes you already have an active Hostini VPS with at least one captured snapshot, access to the client panel at app.hostini.com.br, and a maintenance window of 5 to 15 minutes to perform the operation calmly. The VPS will be unavailable during the restore — do not attempt this during peak hours if it is production.
Prerequisites
Before restoring, confirm you have everything you need to perform the operation without surprises.
An active Hostini VPS with at least one previously captured snapshot, access to the client panel (app.hostini.com.br) with the account that owns the VPS or a sub-user with management permissions, and a planned maintenance window because the VPS will go offline during the process (typically 1 to 5 minutes, depending on disk size).
app.hostini.com.br Services → VPS → Snapshots 1-5 min No after confirming If you do not yet have a snapshot, this guide will not help you — you need to create one first. A snapshot is a “take now to use later” operation, and the goal here is the “use later” part.
When to use a snapshot vs a traditional backup
The decision matters more than the execution. Getting this wrong costs data you thought was protected.
A snapshot is the right choice when: you are about to make a change that might break in the next few hours (kernel update, database upgrade, runtime version swap), the current state of the VPS is the state you want to preserve as a reference (pre-deploy snapshot), or you are testing a configuration and want to roll back quickly if it goes wrong.
A traditional backup is the right choice when: you need protection against hardware failure or serious human error (wiping the whole disk), you need long retention (weeks, months), or you need the copy to survive even if the VPS is accidentally terminated. Backups live in separate storage and have configurable retention.
The rule of thumb: a snapshot is a seatbelt for the operation you are about to do right now; a backup is fire insurance. The two coexist — it is not a mutually exclusive choice.
Accessing the snapshots area in the panel
The Hostini interface consolidates snapshots inside the management page of the specific VPS. There is no global “all snapshots” area — each VPS has its own.
Go to the panel at app.hostini.com.br and log in with your account. If you have multiple VPS, go to “Services” in the side menu to see the full list.
Click the specific VPS you want to restore. The detail page shows the current status (running, powered off, suspended), real-time CPU/RAM/disk metrics, and tabs for each category of operation.
On the side or top tab, find “Snapshots”. You will see the list of existing snapshots with three pieces of information per line: name (set by you on creation), date/time of capture, and space used on storage.
The list is sorted from newest to oldest. Each snapshot has action buttons: “Restore”, “Rename”, and “Delete”. The “Create new snapshot” button is at the top of the section.
Preparing the VPS before restoring
The restore is destructive relative to the current state. Everything written to disk after the snapshot will disappear. This step is where you decide what deserves to survive.
Restoring a snapshot erases all data, configuration, and logs generated after the moment of capture. There is no “undo” after confirming. If there is critical data in the current state (a new database, uploaded files, tuned configurations), copy it out of the VPS before proceeding.
Identify what changed since the snapshot. If you are not sure, consider: application logs (/var/log/), database data (a recent SQL dump), user upload files, renewed SSL certificates (Let’s Encrypt typically renews every 60 days).
Export anything critical out of the VPS. For a MySQL database, the standard command is:
mysqldump -u root -p --all-databases > /tmp/backup-pre-restore.sql
scp /tmp/backup-pre-restore.sql user@local-machine:~/For entire directories, rsync is more robust than scp:
rsync -avz /var/www/html/ user@local-machine:~/backup-html/This step is optional from an operational standpoint — the restore works without it — but mandatory from a common-sense standpoint when there is data you do not want to lose.
Take a new snapshot of the current state before restoring the old one. It may seem counterintuitive, but it is the simplest way to create a return point in case the snapshot you are about to restore is too old or has a hidden problem.
In the panel, click “Create new snapshot” at the top of the list, give it a descriptive name (e.g., “before-restoring-X-2026-05-29”), and confirm.
Executing the restore
With critical data exported and a safety snapshot created, the restore itself takes only a few clicks.
Locate the snapshot you want to restore in the list. Check the name, date, and (if available) description to make sure it is the correct state. Restoring the wrong snapshot is the costliest mistake in this operation.
Click “Restore” on the chosen snapshot. The panel opens a confirmation detailing: that the VPS will be automatically powered off, that subsequent changes will be lost, and the estimated operation time (proportional to disk size).
Reread the warning. Confirm only if you are sure.
After confirming, follow the progress on the same page. The VPS status changes to “Restoring…” and then to “Starting…” as the disk returns to the captured state and the VPS is automatically rebooted.
Do not close the tab during the process — losing the connection does not cancel the operation, but you lose visibility into errors if they occur.
Do not try to power off, power on, or send any command to the VPS while the restore is in progress. Interrupting in the middle can leave the disk in an inconsistent state, requiring manual recovery.
Post-restore verification
The operation ends when the status returns to “Running” (or to the state it was in at the moment of the snapshot, if it was “Powered off”). But finishing does not mean everything works — you need to verify before considering the problem solved.
Connect to the VPS via SSH (Linux) or RDP (Windows) with the credentials that were valid at the moment of the snapshot. If you changed the root password after the snapshot, the old (captured) password is the one that applies now.
ssh root@YOUR-IP-HERECheck the system date and time, kernel version, and the status of the critical services for your application:
date
uname -r
systemctl status nginx mysql php-fpmThe date should be up to date (the system clock syncs after boot). The kernel should be the one that was active at the snapshot. Critical services should be active (running) — if any are inactive, investigate logs in /var/log/.
Test the functional path of the application. If it is a website, open it in the browser. If it is an API, make a request. If it is a database, connect and run a simple query. This smoke test reveals problems that systemctl status does not catch — a closed port, a broken external dependency, an expired SSL certificate.
Troubleshooting common problems
Most post-restore problems fall into three predictable categories.
VPS does not start after the restore
The symptom is the status stuck on “Starting…” for more than 5 minutes or a status of “Error”. Common cause: the snapshot was captured in an inconsistent state (during boot, during shutdown, during a heavy write).
The solution is to open the graphical console of the VPS through the panel itself (“Console” or “VNC” button) to see where the boot got stuck. If it is a filesystem issue, run fsck from recovery mode. If the VPS is unrecoverable, restore the safety snapshot you created in Step 06.
Application returns but with old data
This is the expected symptom — the snapshot captured the state at the moment, not the current state. If you ran mysqldump in Step 05, restore the dump:
mysql -u root -p < backup-pre-restore.sqlIf you did not back up first, the data is lost. Lesson learned — always Step 05 before Step 08.
SSL certificate expired after restore
Common on snapshots older than 60 days, because Let’s Encrypt renews every 60 days. The restore reverts to the certificate from the snapshot date, which may be expired.
The solution is to force a manual renewal:
sudo certbot renew --force-renewal
sudo systemctl reload nginxIf auto-renew was configured, it will resume working normally after this manual renewal.
Next steps
Snapshot restore is a tactical tool — it works when you use it well. For a complete protection strategy for your VPS, consider combining snapshots with external backups and active monitoring.
- Set up periodic backups — snapshots solve “go back 1 hour”, backups solve “go back 1 week after a storage disaster”
- Document your snapshot strategy — when to create (pre-deploy, pre-update), how many to keep, when to delete the old ones to free space
- Enable alerts in the panel to be notified when a snapshot is near the plan limit
- Practice restoring on a test VPS before you have to do it in production — a timed and rehearsed operation is faster and has fewer mistakes
If you are running a critical application and want more control over snapshots and maintenance windows, Hostini VPS come with snapshots integrated into the panel and optional traditional backups, with no per-operation charges.
Frequently asked questions
What is the difference between a snapshot and a traditional backup?
A snapshot is a copy of the disk state (and optionally the RAM) at a specific instant, stored on the same storage as the VPS. A traditional backup is a full disk copy exported to external storage with its own retention. Snapshots are instantaneous and ideal for reverting short-term changes; backups are safe for disaster scenarios because they survive a failure of the primary storage.
Does restoring a snapshot erase data created after it?
Yes. The restore reverts the disk to the exact state at the moment the snapshot was taken — any file created, modified, or deleted after that point is lost. Before restoring, export logs, databases, and critical files from the current state if you want to preserve them.
Can I restore a snapshot with the VPS running?
Technically the hypervisor allows it, but Hostini automatically powers off the VPS before the operation for safety — restoring with the VPS running corrupts the filesystem and open databases. After the restore, the VPS returns to the state it was in when the snapshot was captured (powered on or off).
How many snapshots can I keep per VPS?
The limit varies by plan — smaller VPS plans typically support 1 to 2 simultaneous snapshots, larger plans up to 5. Each snapshot consumes space on the VPS storage proportional to the changes since the capture. Old snapshots do not expire automatically; you need to remove them manually when they are no longer useful.
Does a snapshot include RAM or only the disk?
It depends on the type chosen at the moment of capture. A disk-only snapshot (the most common) freezes the filesystem and requires a full boot on restore. A snapshot with RAM (live snapshot) includes the memory state, so the VPS returns exactly as it was — running processes, active connections. The snapshot with RAM takes up more space and takes longer to capture.
Can I use snapshots as a single backup strategy?
No. Snapshots live on the same storage as the VPS — if the physical disk fails or the node has a serious problem, the snapshot and the VPS are lost together. Snapshots are for reverting recent changes (an update that broke something, a misconfiguration, a problematic deploy). For protection against permanent loss, combine snapshots with periodic external backups — also available in the Hostini panel.