Restoring a backup

Restoring is the thing backups exist for, and it is also the thing you get the least practice at. So in CoreCP it is one journey of nine steps rather than three separate screens: you can see the whole decision in front of you, in the order

Written for: Administrator

You will find it under Servers → a server → Backups → Restore.

The nine steps

Step	What you decide here
Snapshot	which copy you are putting back — the list comes from the server itself
Scope	a whole account, or files out of a server snapshot
Target	where it lands: beside the running system, or over it
What it replaces	what stays as it is, and whether you back up the current state first
Preflight	whether it can happen at all: repository, lock, snapshot, and room
Dry run	what it would do exactly, per resource, without writing anything
Confirm	typing the name of what you are about to overwrite
Progress	following the task
Verification	reading back whether everything the backup names is really there

The first six write nothing. Only after the confirmation does anything reach the server.

The preflight is not a formality

It used to be halfway through a restore that you found out there was no room. The preflight measures it beforehand, on the disk the files actually land on, and says one of four things about it:

Fits — there is room to spare;
Tight — it fits, but leaves less than a gigabyte behind. That is a decision for you, not for us;
Does not fit — the screen will not let you continue, and it says how much you are short;
Not measured — we could not measure it and say so, rather than giving it the benefit of the doubt. An account's dry run then gives you the real number, because that is recorded inside the backup itself.

A restore cannot be undone

What is there now will be gone afterwards. That is why it says so in as many words, and why the What it replaces step carries a button that backs up the account exactly as it is now. One press, before anything is replaced. That is your way back.

If one resource fails on the way — a database with a collation this server does not carry, for instance — the rest still goes through and that one carries the server's own sentence. Starting the restore again retries exactly that; what already landed stays.

One file, one database, one mailbox

The journey is too big for that. You will find those under Accounts → an account → Backups → Restore: a browser through the contents of the backup, with what a restore would do to each item beside it.

From the command line

corectl backup restore preflight --scope account --account demo
corectl backup restore account demo --dry-run
corectl backup restore account demo
corectl backup restore verify demo

Does anybody ever test that it works?

Yes, every week — and that part is new. Every server with the backup role takes a sample out of its newest snapshot on its own, reads it back and throws it away again. The server's backup screen says when that last went well. When it went wrong, you see it in the list of problems, with the server's own sentence beside it.

You can also run it yourself: Backups → Run the restore test now.