NovaPanel
Docs

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.