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.

Restoring over a website that is still there

Restoring an account whose websites still exist on the server updates them in place: the settings from the backup are applied, and what the server set up itself since — such as the mail security policy — stays as it is. A website that now belongs to another account is never taken over: the restore stops before it changes anything and names that account. Move or remove the website there first.

What an archive may not do

An archive is a file somebody else may have made — a backup from another panel, for instance. Two things a restore therefore never puts in place, even when the archive asks for them:

A link that points outside your own directory. A symbolic link in the archive that would point at /etc or at another customer is not created, and no file is ever written through such a link. The report says so; the rest of the archive comes back as usual.
A password field that is not a password hash. The account password in an archive is an encrypted hash. If the field holds anything else it is not applied, and the report tells you to set the password again with corectl account passwd.

Both are a message, not a stop: the website, mail and databases from the same archive are restored.