Restore a backup
Bring a site's files back from a NovaPanel snapshot, and restore a database from a dump. ~1 minute for a small site.
What a restore does, and what it doesn't
A NovaPanel restore brings back files. Databases are not included — they are dumped into the archive, but restoring does not import them, because dropping and replacing a live database is a separate decision from rolling back a set of files.
So if you are recovering from a bad deployment or a hacked site, a restore is what you want. If you are recovering from a bad database migration, skip to restoring a database below.
Restoring a site's files
Find the snapshot
Customer panel → Backups. Each snapshot shows its timestamp, size and where it lives — on the server, offsite, or both. If the local copy was already pruned by your retention setting, that's fine: NovaPanel fetches it back from your offsite destination automatically.
Operators can restore on a customer's behalf from the admin panel under Backups, which lists every account's snapshots.
Choose what to restore
Click the restore icon on the snapshot. If the backup holds more than one site, you can restore just one of them rather than the whole account — pick Just one site and choose it from the list. Every other site is left exactly where it is, still running whatever was deployed to it this morning.
This is usually what you want. One site broke; the others have moved on since the snapshot was taken, and rolling all of them back to fix one costs more than the original mistake did.
The list of sites is read from the archive itself, so it shows what that backup actually contains rather than what exists today. A site created after the snapshot was taken will not appear, because its files are not in there.
Your main site is a slight special case: its folder is the
account's home directory, which also contains your other sites. Restoring it
brings back its public_html and leaves the rest of the account
alone.
Start the restore
Click the restore icon on the snapshot and confirm. The confirmation is blunt on purpose: the site's current files are replaced, and anything changed since the snapshot was taken is lost.
The restore then runs in the background — you can close the page — and you get a notification when it finishes. A small site takes seconds; a multi-GB one takes a few minutes.
If it fails
Nothing is changed. The archive is unpacked to a temporary directory first and only swapped into place once it has extracted cleanly, so a failed or interrupted restore leaves the live site exactly as it was rather than half old files and half new.
Restoring a database
Customer panel → Databases → pick the database
→ Import, and drag in a .sql file. The
dumps from a NovaPanel snapshot are inside the archive under
databases/ — download the snapshot, unpack it locally, and
import the dump you need.
Or over SSH, if you would rather:
mysql -u <db-user> -p <db-name> < dump.sql
If the dump references a different database name, correct the USE
line at the top of the file before importing.
Restoring from another host's backup
This is the path when you have a site.tar.gz and a
db.sql from somewhere else — a cPanel or Plesk export, say.
Files
Upload the tarball through the File Manager, or copy it over SSH:
scp site.tar.gz user@your-host:/tmp/
ssh user@your-host
sudo -u <customer-user> tar xzf /tmp/site.tar.gz \
-C /srv/sites/<customer-user>/<site>/public_html/ Archives from other panels often carry the wrong user IDs, so fix ownership afterwards:
chown -R <customer-user>:<customer-user> \
/srv/sites/<customer-user>/<site> Database
Create the database in the panel first, then import the dump as above.
Common issues
The site looks broken after a restore
Almost always ownership. Run
chown -R <customer>:<customer> /srv/sites/<customer>/<site>
over SSH and check again — PHP-FPM running as the wrong user is the usual
cause.
The site is back but the data is old
Expected: a restore brings back files only. The database is still whatever it was. See restoring a database.
An offsite destination lists nothing
Either the credentials under Backups → Offsite destination are wrong, or the bucket policy does not grant permission to list objects. Use the Test connection button there first — it reports the exact failure. To check independently:
aws s3 ls s3://your-bucket/ --endpoint <endpoint> Setting up automatic backups
Customer panel → Backups → Schedule. Choose the hour it runs and how many days of snapshots to keep; anything older is pruned automatically.
Under Offsite destination you can send each snapshot to S3, Backblaze B2, Wasabi, MinIO or SFTP. You can also choose not to keep a local copy — in which case the local file is only ever removed after the upload has been confirmed, so you are never left with no backup at all.