Backing up and restoring in the UI

Your control panel keeps a running list of backups for every site, and it takes snapshots for you on demand. This is the safety net you reach for before a risky change: click Backup, and a moment later you have a snapshot you can roll back to if anything goes wrong. Everything on this page happens in the web UI you log into — there's nothing to install and no server to touch.

Two jobs live here, side by side:

  • Backup takes a snapshot of a site right now.
  • Restore rolls a site back to one of those snapshots.

Both run as tasks: you click a button, the control panel queues the work, it runs in the background, and you see a live log turn green when it finishes. You don't have to sit and watch it.

Making a backup

  1. Open the site in the control panel.
  2. In the row of tasks, click Backup.
  3. A short form appears. Fill it in and confirm.

The form has two fields:

  • Description — an optional note to your future self, like before Drupal update or pre-launch. It shows up next to the backup in the list, so a good description saves you guessing later. You can leave it blank.
  • Backup Mode — what to include in the snapshot. You have three choices:
    • Classic single file mysqldump only — just the database, on its own.
    • Site files without any DB — just your site's files, no database.
    • Site files with classic mysqldump DB — the files and the database together.

The form opens on Classic single file mysqldump only — a database-only snapshot that the Restore task cannot use. If you're taking a backup so you can roll back later, change it: pick Site files with classic mysqldump DB unless you have a specific reason not to. That is the complete snapshot, and — importantly — it is the only mode you can later feed to the Restore task. The other two modes are handy for grabbing just one half of a site (for example, exporting only the files), but you can't restore a site from them in the UI — so don't just accept the default if a restorable snapshot is what you're after.

Confirm the form and the backup task runs. When it finishes, your new snapshot appears in the site's backup list, stamped with the date, its size, and the description you gave it.

What's in a backup

A full backup (the Site files with classic mysqldump DB mode) is a single archive containing everything that makes your site your site:

  • The database — all your content, users, and settings.
  • The site's files — its settings.php, uploaded files, and the site's own sites/<domain>/ directory.

That one archive is enough to bring the site back exactly as it was at the moment you took it. It does not include the shared platform code your site runs on (that's managed separately), and it doesn't include the server itself — a backup is a snapshot of one site, not of the whole machine.

Where your backups are listed

Every snapshot a site has is listed in one place: open the site in the control panel and go to its Backups tab. There you'll see each backup with its date, size, and description, newest first.

From that list you can also export a backup and download the archive to your own computer, which is worth doing before a big change so you have an off-box copy in hand. That Export-and-download from the Backups tab is the simplest way to get a copy in your hands. The same snapshot archives also show up in your own account files, under a clients/<your-client>/backups/ folder you can reach with your oN.ftp login over SFTP — so a downloaded copy is always within your reach, whichever way you prefer to grab it. Each archive's filename carries the site's address and the date it was taken, so you can tell them apart at a glance.

Restoring a site

Restoring rolls a site back to an earlier snapshot. It's the undo button for a change that didn't work out.

  1. Open the site in the control panel.
  2. In the row of tasks, click Restore.
  3. The confirmation screen lists the site's backups, each with its date, size, and description. Pick the one you want to roll back to.
  4. Confirm.

The restore task queues and runs in the background, just like a backup. When it turns green, your site is back to the state captured in that snapshot.

You can't lose your current state

Here's the part that makes restoring safe: the control panel takes a fresh backup of the site's current state before it rolls anything back. That automatic snapshot shows up in your backup list with the note "Generated before being restored to a previous version." So even if you restore to the wrong point, or change your mind afterwards, your pre-restore state is sitting right there in the list, ready to restore to. You can't paint yourself into a corner.

The same reflex kicks in for the other risky moves: disabling a site takes a fresh snapshot first (labelled "Generated before being disabled"), and so does deleting one. Whichever way you take a site offline, there's a backup of exactly how it looked just before, waiting in the list.

The site is briefly unavailable during a restore

While the restore runs, the control panel puts the site into maintenance for a short while — it has to swap the old database and files out for the restored ones, and it can't do that with visitors mid-page. Once the restore finishes, it re-checks the site and brings it back online automatically. Expect a brief blip, not an outage you have to fix. If you want to avoid surprising visitors, do restores at a quiet time.

One thing to watch: the backup mode has to match

You can only restore from a backup that included both the files and the database — that is, one taken in Site files with classic mysqldump DB mode. If you try to restore and the backup you want isn't offered, or the restore doesn't take, it's almost always because that snapshot was a files-only or database-only backup, which the Restore task can't use on its own. The fix is simple: take a fresh full backup next time, and you'll always have a restorable snapshot on hand. If you'd set your account to use the faster Fast DB Backups option for other tasks, note that the on-demand Backup task above still writes a classic, restorable dump — so the snapshots you make here stay usable for Restore.

When something's genuinely stuck

If a backup or restore task goes red and the log doesn't make it clear why, run a Verify Site task first — it re-checks the site and regenerates its config, and it clears up a surprising number of hiccups on its own. If a restore fails in a way you can't unpick, that's a good moment to open a support request: your host can look at the task log from the server side, which you can't reach, and sort out anything that needs attention there.

Where to go next

  • On-demand snapshots aren't the whole backup story. Alongside the ones you take here, your account also gets automatic local database dumps on a schedule, and (if your host has it switched on) scheduled off-site backups to cloud storage — a separate safety net that runs without you lifting a finger.
  • Full task names and control-file names are collected in the shared Reference.