Docs / Shared hosting

Backups: what we keep and how to restore

Automatic backups on separate physical infrastructure, how to take a manual snapshot before big changes, and exactly what restoring does — and doesn't — bring back.

Automatic backups are included on every plan — Solo, Studio, and Org alike. They are not an upsell, and restoring one does not require a ticket. Snapshots run automatically every 12 hours, and we keep 14 days of them — older ones roll off as new ones arrive. They’re stored on separate backup infrastructure — a different physical server than the one running your site — so a problem with your web server doesn’t take your backups down with it.

You manage all of this yourself from the Backups tab in your customer portal at my.candorhost.com, under Files & databases. (The same backups are also managed through your control panel — how the platform fits together.)

What the Backups tab shows

Open your hosting service in the portal and choose Backups. You’ll see a list of snapshots, and for each one:

ColumnWhat it means
SnapshotWhen the snapshot was taken, with an auto or manual badge showing whether it was scheduled or one you created yourself
SizeHow much data the snapshot holds
ContentsTwo status indicators — Files and Databases — showing whether each part of the snapshot completed successfully
RestoreShown on any snapshot whose files or databases completed successfully

If your account is new you may see “No backups available yet” — your first automatic snapshot arrives within 12 hours, or take a manual one right away (below).

Two things the portal list makes explicit, because they matter:

  • A snapshot covers your website files and your MySQL databases. Those are the two contents indicators, and they’re what a restore brings back.
  • The list is the source of truth for what exists. The snapshots you see, with their dates, are the snapshots you can restore: every 12 hours automatically, kept for 14 days, plus any manual ones you’ve taken.

Take a manual backup before big changes

Before a major plugin update, a theme change, a PHP version switch, or any bulk edit you might regret: take a snapshot first. It takes one click and turns “I broke the site” into a five-minute fix instead of an afternoon.

  1. In the portal, open your hosting service and go to Backups.
  2. Click Create backup now and confirm. The snapshot may take a moment to complete.
  3. It appears in the list marked manual, alongside your automatic snapshots.

Then make your change. If it goes wrong, restore the snapshot you just took and you’re back exactly where you started.

How to restore, step by step

Read this first: restoring overwrites your current website files and databases with the backed-up versions, and it cannot be undone. Anything that changed after the snapshot — new orders, comments, uploads, edits — is replaced along with the problem you’re fixing. If the current state has anything worth keeping, click Create backup now before you restore, so you can get back to it.

  1. Log in at my.candorhost.com and open your hosting service.
  2. Go to Backups, under Files & databases.
  3. Find the snapshot you want, using the date and the auto/manual badge. Check the Contents indicators — restore is only offered when the files or databases portion completed successfully.
  4. Click Restore and read the confirmation carefully — it repeats the date of the snapshot you’re about to bring back.
  5. Confirm. The portal reports that the restore has started; it runs in the background, so give it time to finish before judging the result.
  6. Check your site. If something still looks wrong after the restore completes, open a ticket.

One honest limitation to know in advance: a restore brings back files and databases together. There is no portal option to restore only the database or only the files from a snapshot. If you need a partial recovery — one table, one directory — take a manual snapshot of the current state first, then restore, or ask us before you click anything.

What backups protect you from — and what they don’t

Backups are insurance, not magic. Being clear about the boundary is the whole point of this page.

They protect you from:

  • A bad update, migration, or bulk edit — restore the snapshot from before it.
  • Accidentally deleted files or dropped tables.
  • A hacked or defaced site — restore a snapshot from before the compromise.
  • Hardware failure on your web server — snapshots live on separate physical infrastructure.

They don’t protect you from:

  • Changes made since the last snapshot. A restore rewinds everything to the snapshot’s date — data created after it is gone. This is why you take a manual snapshot before big changes.
  • Restoring the problem along with the site. If your site was already compromised or broken when a snapshot ran, restoring that snapshot brings the problem back too. Pick a snapshot from before things went wrong.
  • Anything a snapshot doesn’t cover. The contents indicators are files and databases. Content that lives elsewhere — mail in your mailboxes, DNS records you’ve customized — isn’t part of what the Restore button rewinds. If you’re unsure whether something is covered, ask before you rely on it.

Keep your own copies too

We keep backups so you don’t have to — but for anything irreplaceable, an offsite copy you control is cheap insurance, and every plan includes the tools:

  • Download your site files over SFTP or SSH.
  • Export any database from phpMyAdmin, one click from the portal.

A copy on your own machine before a big change costs five minutes and answers every “what if” this page can’t.

If a restore doesn’t fix it

Open a ticket. If your site is down, we respond within 1 hour during business hours (Mon–Fri, 9am–6pm ET); everything else gets a first response within 1 business day. Automated monitoring runs around the clock either way, so a down site is usually flagged before you finish typing the ticket.

Something here wrong, unclear, or missing? Tell us — docs get fixed like bugs.