Your own backups

Your hosting company almost certainly backs up the whole server. Those backups exist for disasters — a broken disk, a lost machine. They are not there to get you out of Tuesday afternoon, when a plugin update wrecked your site. That is what your own backups are for: you decide when they are made, where they live and when you put one back.

Screenshot — Panel → Hosting → Accounts → your account → Files, FTP and backups → Backups. Screenshots are captured with openwolf designqc into .wolf/designqc-captures/.

What is in a backup

One backup of your account contains:

• your files — everything under your home, so your websites too;
• your databases, as dumps;
• your mailboxes, with the messages in them;
• your DNS zones, if they live on this server.

You can skip parts you do not need — mailboxes are often the biggest piece and the least interesting to change.

What your plan allows

At the top of the page is What the plan allows: how many backups per day you may take, how many may be kept, how many destinations you may store and which destination types are permitted. Those limits are enforced on the server, not in the screen: ask for more than is allowed and you get the allowed value back, not an error.

If it says Own backups are off for this account, your reseller or administrator has not enabled them in the plan. That is where you ask.

corectl userbackup status --account web1

Destinations: where the backups go

There is always one destination that already works: local, in ~/backups. Handy and fast — but it sits on the same server as your site. For "I emptied my database by accident" that is fine. For "the server is gone" it is not.

So put at least one off-site destination next to it. Supported:

Click Add destination, choose a type and fill in the fields that belong to it. The credentials go to the server once and are kept encrypted there; the panel keeps no copy.

# S3-compatible storage
corectl userbackup dest add offsite --account web1 --type s3 \
  --endpoint s3.eu-central-1.wasabisys.com --region eu-central-1 \
  --bucket my-backups --access-key AKIA… --secret-key-stdin < ~/secret.txt

# a NAS of your own over SSH
corectl userbackup dest add nas --account web1 --type sftp \
  --host nas.example.net --port 22 --user backup --path /volume1/hosting --key-file ~/.ssh/id_ed25519

corectl userbackup dest list --account web1
corectl userbackup dest remove nas --account web1

Removing a destination erases its credentials; the backups already sitting there stay where they are.

Taking a backup now

Click Back up now and choose the destination. You see the progress, and when it is done the backup appears in the list with its date, size and an id.

corectl userbackup create --account web1 --dest offsite --keep 5
corectl userbackup create --account web1 --dest local --no-mail   # without the mailboxes
corectl userbackup list   --account web1 --dest offsite

--keep tidies up afterwards: it keeps the newest N backups at that destination and throws the rest away, within what your plan allows.

Automatically, every night

Under Schedule you set per destination when it happens on its own. The field is an ordinary five-field cron line.

# every night at 03:30, keeping five
corectl userbackup schedule --account web1 --dest offsite --cron "30 3 * * *" --keep 5

# every Sunday at 04:00
corectl userbackup schedule --account web1 --dest nas --cron "0 4 * * 0" --keep 8

corectl userbackup schedule --account web1 --dest offsite --off   # remove the schedule

Five fields: minute · hour · day of month · month · day of week. Put it at night; backing up a large site costs disk I/O your visitors notice.

Under Recent runs you see for each scheduled run whether it succeeded. Look at that now and then — a schedule that has been failing for three weeks is worse than no schedule, because you thought you were covered.

Restoring

Look at what it would do first. Click Dry run: the panel shows which files, databases and mailboxes would be overwritten, and changes nothing.

corectl userbackup restore --account web1 --id <backup-id> --dest offsite --dry-run

If you agree, choose Restore. Restoring overwrites the current files, databases and mailboxes of this account. There is no "merge": what is in the backup wins.

corectl userbackup restore --account web1 --id <backup-id> --dest offsite
corectl userbackup restore --account web1 --id <backup-id> --no-mail --no-dns

If you only want your database back and not your files, take the dump out of the backup instead — see Databases and phpMyAdmin for importing it.

Throwing a backup away:

corectl userbackup remove --account web1 --id <backup-id> --dest offsite

The three rules that make backups actually work

1. One copy is not a backup. Local and somewhere else.
2. A backup you have never restored is an assumption. Do a trial restore once a year — on a test environment if you like.
3. Watch the runs. A silent failure is noticed the moment you need it.

When something is not right

See also

• Files, FTP and SSH — where ~/backups lives.
• Databases and phpMyAdmin — putting one database back instead of everything.
• Making a test environment — practising without touching your live site.