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 — the database, with no site files.
  • 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 Site files with classic mysqldump DB — the complete snapshot — so accepting the default always gives you something you can roll the whole site back to. The two partial modes are there for when you deliberately want just one half:

• Classic single file mysqldump only captures the database, plus the site's small settings files — without any of your uploaded files. Ideal before a content import or a module update that only touches the database.
• Site files without any DB captures your files alone — and it really is without any DB: no database dump is written into the archive, so it holds what its name promises.

Each mode restores exactly what it contains (see What each backup restores below), and the pickers on the Restore and backup-management forms label the partial ones — database only, no site files and site files only, no database — so you always know what a snapshot holds before you pick it.

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.

One thing you never have to think about: on the server your uploaded files live in a per-account storage area behind links, but every backup you take here in a files-carrying mode follows those links and archives the real content — the archive is self-contained and its listed size honestly reflects what's inside. If a "full" backup suddenly looks implausibly small next to its older siblings, treat that as a red flag and mention it to support rather than assuming all is well.

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 live in your own account files, reachable with your oN.ftp login over SFTP: the backups/ folder of your FTP home holds the archives themselves, and clients/<your-client>/backups/ lists the same archives grouped by client. They're working copies with housekeeping, though — archives older than about a week on a hosted account (two weeks by default on self-hosted servers) are tidied away by the nightly maintenance — so when a snapshot matters beyond the moment, Export-and-download is the way to keep 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, description — and, for partial snapshots, a label saying what they hold. 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.

What each backup restores

Restore brings back exactly what the snapshot contains — no more, no less:

• A full backup (Site files with classic mysqldump DB) rolls the whole site back: the database is imported from the archive's own dump, and your files are brought back to their archived state.
• A database-only backup (database only, no site files in the list) rolls back just the database. Your files are recognised as absent from the archive and are deliberately left exactly as they are — a clean way to undo a content mishap without touching uploads.
• A files-only backup (site files only, no database in the list) rolls back just your files and leaves the database alone. The task log states plainly that the archive carried no database dump and the database was left unchanged. (One exception: if your account is deliberately opted out of the stock Fast DB Backups behaviour, a snapshot without a dump cannot be restored from the panel at all — the task fails safely with "No database dump was found" and the site is left untouched.)

Unlabelled snapshots vary: whether one carries a database dump depends on how it was taken. On-demand backups in a database-carrying mode always do. Automatic scheduled ones on accounts with the stock Fast DB Backups behaviour don't — their database copies are kept separately on the server — and older snapshots from before your host's platform update usually don't either. Restoring a snapshot without a dump behaves like a files-only restore: files come back, the database stays, and the task log tells you so. When you need a guaranteed full rollback point, take a fresh Backup with the default mode — that is precisely what it is for.

A safety copy is taken first

Before it rolls anything back, the control panel takes an automatic snapshot of the site's current state — it shows up in your backup list with the note "Generated before being restored to a previous version."

That pre-restore copy is a full, restorable backup: it carries the site's database and files inside the archive, exactly like a Backup taken in the default mode, so it is itself a one-click rollback point from the panel. Your replaced files content is additionally kept aside on the server (never deleted), so even outside the archive nothing is lost and your host can wind things back for you on request.

The same reflex kicks in before a site is deleted — its final state is archived first — but that copy is taken in your account's everyday shape rather than in the forced restorable mode. On an account with the stock Fast DB Backups behaviour it carries no single-file database dump inside the archive, so treat it as a last record of the site rather than a one-click rollback point. If you want a rollback-ready copy before deleting a site, run Backup with the default mode first.

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.

Partial backups restore partially — by design

Every snapshot in the list can be fed to Restore; the labels tell you what each one will bring back. Just remember the rule of thumb: what you backed up is what you get back. A database-only snapshot cannot bring back files it never contained, and a files-only snapshot cannot bring back a database — the task log always says which halves were restored. (On accounts opted out of the stock Fast DB Backups behaviour, snapshots without a dump cannot be restored from the panel at all — the task fails safely and the site is left untouched.)

Since accounts use the faster Fast DB Backups behaviour as stock, it's worth knowing that the on-demand Backup task above still writes a classic, restorable dump into the archive whenever the mode includes the database — so the snapshots you make here stay fully 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.
• Control-file settings and command names are collected in the shared Reference.