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.

Two directories are deliberately left out:

• backups/ — your earlier backups. Otherwise every backup would carry all the previous ones and grow every night.
• .trash/ — your wastebasket. What you threw away does not belong in a backup: it would grow with every deletion, and a restore would bring your deleted files back. To keep something that is in the wastebasket, put it back first — then it is in your files at the next backup like anything else.

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

Where those limits come from

The limits are resolved over four layers. The bottom one applies when nobody says anything, and the top one wins:

The default is 3 backups kept, 4 destinations, 1 per day for an ordinary hosting account. If you are a reseller yourself it is 7 / 6 / 2 — you also restore backups on behalf of your own customers.

corectl userbackup status and the Origin column in the panel say, per line, which layer decided it. "Set here" means your hosting company agreed something specifically for you — which can also be more than the plan gives:

corectl userbackup policy show --account web1

Why there is no limit in GB

There is deliberately no maximum in gigabytes on your backups.

• A remote destination — your own S3 bucket, your NAS, your Dropbox — is your storage. What fits there is your call, not ours.
• A local backup sits in ~/backups, inside your account, so it is already counted by the disk quota you have anyway. If your quota fills up with backups then your quota is full — your account page says so, and you fix it by removing backups or buying more room.

What your plan does bound is the number of copies, the number of destinations, and how often you take one.

Which server makes the platform's backup of your account

One line can appear above the list: "The platform backup of this account is made by …". It shows only when your account's backup role sits on a machine other than the one your files are on.

That is a different answer from the destination below: the destination is the storage, this is the server that writes to it. Nothing changes for your own backups — those are made on the machine your files are on.

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

Getting one thing back instead of everything

Usually nothing is broken except one thing: one file you overwrote, one table you emptied by accident, one mailbox that is gone. Restoring the whole account then costs you everything that happened since — this afternoon's orders, this morning's mail. It does not have to.

Look at what a backup holds first. This reads the backup itself, changes nothing, and says per item what restoring it would do:

corectl backup items web1
corectl backup items web1 --kind database
corectl backup items web1 --path domains/example.com/public_html

There are six kinds of item: a file, a directory, a database, a mailbox, a DNS zone and your crontab. Put one back with the kind and the name you saw in the listing:

# a dry run first: this writes nothing
corectl backup restore item web1 --kind file \
  --name domains/example.com/public_html/index.php --dry-run

# and then for real
corectl backup restore item web1 --kind file \
  --name domains/example.com/public_html/index.php
corectl backup restore item web1 --kind database --name web1_shop
corectl backup restore item web1 --kind mailbox --name info@example.com

Three things you may assume, and that are tested:

• Only that one thing changes. Restore one file and the file next to it stays exactly as it was. A directory is merged: whatever you added after the backup stays.
• A dry run really is a dry run. --dry-run names the item, says whether it would be created or overwritten, and leaves the server alone.
• Restoring twice is the same as restoring once. You can safely run the same command again; you never end up half-way.

If such a command does not work, your hosting company keeps no backups of this account or does not make them available to you. Ask them — they can restore the same things from the panel, on the screen below.

Restore from a backup (the screen)

This screen is for your hosting company and your reseller. If you cannot see it, nothing is broken: it also reads the backups the platform takes of your account, and those are your hosting company's. Ask them to put one thing back, or do it yourself with the commands above.

Where — Panel → Hosting → Accounts → the account → Backups → Browse the backups.

The screen does four things, in this order.

1. You choose a backup. The bar at the top lists every archive of this account that can be opened: the platform backups (taken by the hosting company, outside the customer's disk space) and the account's own backups. An own backup that lives at an off-site destination is listed but cannot be opened item by item — it is not on the server. Restore that one whole, from the ordinary backups screen.

2. You browse it. The list shows the six kinds out of one backup — file, folder, database, mailbox, DNS zone and crontab — and says per row what a restore would do: create (there is nothing there now) or overwrite (there is). Click a folder to look one level deeper; only one level is fetched at a time, so a home directory with tens of thousands of files stays workable. Above the list you can narrow to one kind. Clicking a row slides a panel open with the details: where it lands, how big it is, when it was last changed.

3. You do a dry run first. Tick what you want back and press Preview restore. The server then takes exactly the same steps a real restore takes and leaves out only the writing. What you see afterwards is therefore not an estimate: it is what is going to happen, item by item, with "create" or "overwrite" beside it. Before this moment there is no button on the page that restores anything — deliberately.

4. Only then do you restore for real. The button sits under the dry run. If nothing is replaced, one confirmation is enough. If something is overwritten, the panel asks you to type the account name — the same threshold as every other action that replaces data. Each item then runs as a task on the server and the progress arrives live; you may leave the page.

What you may assume, and what is tested:

• Only the chosen item changes. The file next to it, the second database, the other mailbox: all keep the state they have now.
• You never see anybody else's backups. The screen shows only the backups of the account in the address bar, and the server refuses an archive belonging to another account.
• A dry run writes nothing. A deleted file is still deleted after one.

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

What happens to extra names and subdomains

A backup of your account keeps your websites as they are — including the things a name alone cannot tell you:

• extra names come back the way you had them: whether they show the site or redirect, whether their mail goes to your main domain, and whether this server held their DNS zone;
• subdomains come back as subdomains of their main domain, and in the same place on disk. That last part matters if you ever migrated from DirectAdmin: your subdomain then lives inside the main domain's folder, and a restore that put it somewhere else would break every link to that folder.

There is nothing to do for any of this. A backup taken before this feature existed restores fine: it knows the extra names only as bare names, and they come back as "show the same site, and carry the mail" — which is what they were.

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.

Restoring a backup that came from somewhere else

When you restore an archive that did not come from this panel — an export from your previous host, a tar you edited yourself — that archive is treated as untrusted. This is not distrust of you; it is that an archive can contain file names pointing outside your own directory, and a restore that simply obeys them writes into somebody else's data.

What happens before a single file is written:

• Names pointing outside your own directory (../../somewhere/else) are refused.
• Shortcuts (symbolic links) inside the archive are checked before they are created.
• Permissions from the archive are reduced to ordinary read and write; an archive cannot smuggle in special privileges.
• An archive that unpacks to many times its own size runs into your own disk allowance rather than the server's.

Look at what would happen first, without restoring anything:

ssh root@stck1.corecp.dev 'corectl backup restore --account acc-1 \
  --archive /var/backups/corecp/acc-1/acc-1-20260814.tar.zst --dry-run'

would restore 18422 member(s) into /home/acc-1
0 member(s) would be refused (link target outside the account tree)

If the number after refused is greater than zero, those files are skipped and you are shown them by name. They are not dropped quietly — a restore that silently loses files is worse than one that stops.

Seeing how far a backup has got

While a backup is running you do not have to guess. Everything your panel starts on a server appears in the task list (see Following background tasks), and backups are part of it.

What you see there depends on whether there is anything to count:

• A backup of one account — yours — counts nothing that can be measured meaningfully. So you get running since 09:41 and a duration that climbs, and no progress bar. That is deliberate: a bar based on elapsed time rather than on work sits at 80% while there is still half an hour to go.
• A backup of every account on a server (administrator work) does count: 3 of 11 accounts. That counter only ever moves forward.

# Administrators, on the panel:
root@panel1:~# corecp-panel tasks list --active
STARTED              SOURCE  OPERATION        SUBJECT  NODE              STATE    PROGRESS       DURATION
2026-08-17 09:41:02  node    backup.accounts  -        stck1.corecp.dev  running  3/11 accounts  1m48s

Note the two different retention periods: the panel keeps the row for 90 days, the server keeps the matching log for 30. A backup from two months ago is therefore still in the list, and says plainly "the log expired on the server" instead of showing you a blank page.

Where the dry run is now

Dry run shows what a restore would change without changing anything. That report used to appear on the page behind the open panel — the one place you cannot see while the panel is open. It is in the panel itself now, with its copy button.

If the server refuses something — a destination it will not accept, a backup it cannot restore — the dialog stays open with that reason in it, above the field or the button it is about.

What your administrator keeps apart from your backups

Your backup is about your account: your files, your databases, your mailboxes and your settings. Separately, your administrator backs up the server as a whole. That one holds the server's own records — the mail list the mail server reads from, the zone data and the webmail's settings — and it is outside your backup because it is not yours.

What that means for you:

• If you lose one mailbox or one database, your own backup is the answer, and you restore it yourself.
• If something is wrong with the server, your administrator has their own copy of what the server needs in order to work. You do not have to do anything for that, and you do not have to keep anything for it either.

To be sure your own backup is current, look at the overview for when the last one finished — or ask on the command line if you use it:

corectl backup list --account youruser

The date you see there is the moment the copy was complete, not the moment it started.

If a backup keeps taking all night

Your backup runs inside your own account, with the same limits your websites have: the same processor ceiling, the same memory, the same maximum number of processes. That is deliberate — it is why a large backup cannot slow down the websites of the other customers on the server — and it has one consequence worth knowing.

If the server is holding your account at its processor ceiling while the backup runs, the backup takes longer. Not a little longer: it can be the difference between twenty minutes and all night.

You can see whether that is what is happening. Open Account → Usage and limits and look at the hour the backup ran. If your account was being held back at that hour, the moment recorded there names the process — and if it is the backup, this is a plan question rather than a backup problem.

See "Usage and limits" for what to do next.