Backups and cron

Backups

If your plan includes backups, your site is backed up automatically on a schedule — files, and optionally your databases too. The site’s Backups page shows when the last backup ran, when the next one is due, and lets you start one by hand, up to a daily limit your plan sets.

Restoring

Restores are self-service. Choose what to bring back:

• The whole site
• Files only — everything, or a single file or folder
• A database only

Pick a snapshot from the list (with its date and what it contains) and start the restore. It runs as a background job you can watch in real time. Whatever the restore replaces isn’t deleted — it’s moved to a short-term recovery area first, so a restore you didn’t mean to run isn’t itself unrecoverable.

Tip

Backups also run automatically before risky operations — a restore, or a WordPress update — so there’s almost always a very recent snapshot even outside your regular schedule.

If backups aren’t available

Some plans don’t include backups, or a backup destination hasn’t been configured yet for your account. The Backups page tells you which, and if it’s a plan limitation, your provider can tell you which plans include it.

Cron jobs

Add scheduled tasks from the site’s Cron page: a command (or a URL to fetch, for sites without shell access) and a standard cron schedule (minute, hour, day, month, weekday). Jobs run inside your site’s own sandbox, with the same isolation as everything else on the site, and their output and any errors are kept so you can check whether a run succeeded.

Note

A cron job that fetches your site over HTTP counts as a real visit, so it wakes the site’s PHP if it was asleep — see PHP and performance. Jobs that run scripts directly (not over HTTP) never need PHP to be awake at all.

Your plan sets a minimum interval between runs of the same job, to keep cron from being used to hammer the site or the server.