@@PRODUCT@@

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

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 you actually take it.

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

The nine steps

StepWhat you decide here
Snapshotwhich copy you are putting back — the list comes from the server itself
Scopea whole account, or files out of a server snapshot
Targetwhere it lands: beside the running system, or over it
What it replaceswhat stays as it is, and whether you back up the current state first
Preflightwhether it can happen at all: repository, lock, snapshot, and room
Dry runwhat it would do exactly, per resource, without writing anything
Confirmtyping the name of what you are about to overwrite
Progressfollowing the task
Verificationreading 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.

A folder that points out of your home

When the server creates a folder for you in your home directory (the folders above a single item you restore), it does not follow a link that leads out of your home. If you replaced such a folder with a link to somewhere else on the server, the action is refused and says why. Remove the link, or let it point inside your own home, and try again. A link that stays inside your home, like the document root an import leaves behind, works as before.

See also

  • Your servers' backups — where the backups go and when they run.
  • Your own backups — the backup a customer makes and restores themselves.