Skip to main content
Backups and recovery

Backups you never have to think about

An immutable daily backup, written to separate infrastructure away from the server it protects. Restore one file, one database, or everything - over the original or beside it, so you can look before you overwrite.

14 days free. No credit card. No commitment.

Off the server

Separate infrastructure

Same price

On renewal, every year

99.99%

Uptime, last 12 mo

Daily

Backups kept up to 30 days

E

190+

Tasks Ellie handles

Where they live

Off the machine, and impossible to rewrite

Most of what makes a backup trustworthy is decided before anything goes wrong - where it is kept, and whether anything can reach it.

  • Not on the server they are protecting

    Backups are written to separate backup infrastructure in a different location from the machine your site runs on. A backup that shares a disk with the thing it is backing up is a copy, not a backup.

  • Every backup is immutable

    A backup is written once and cannot be edited afterwards. Nothing running inside your hosting account can alter one, overwrite one, or encrypt one - there is no writable path from your site to your backups at all. Ransomware that reaches your files does not reach these.

  • Your account, and only your account

    One volume per account rather than one shared archive with folders in it. Nothing about restoring your site involves reading past anybody else's data.

  • Nothing to set up

    There is no schedule to configure, no plugin to install, and no first backup to remember to take. It starts the day the account does.

What a backup is here, in one line

A complete, frozen copy of your account as it stood that day, held on dedicated backup infrastructure somewhere else. Not an archive sitting in a folder on your own server, and not something that can be rewritten once it exists.

  • Daily, automatic
  • Immutable
  • Separate location
  • Per account
  • On every plan

Granular recovery

You almost never need the whole site back

The usual disaster is one file, one table, or one afternoon. Restoring everything to fix one of those causes a second problem, so you can restore at any of three sizes.

  • A file, or a folder

    Open a backup, browse it like a file manager, tick what you want and restore just that. The usual case: one config file, one plugin directory, one image somebody deleted.

  • A database

    Restore a database on its own without touching a single file - and choose whether the database users come back with it or stay as they are.

  • The whole account

    Files and databases together, back to how they were on a given day. The button for the morning after a bad deploy.

Browse a backup

Look inside before you restore anything

A backup opens like a file manager. Walk the tree as it stood that day, find the thing you are missing, and take only that.

  1. Pick a day

    Backups are listed by date with their size. Choose the last one you know was good.

  2. Browse it

    Navigate the backup the way you would a file manager - folders, sizes, dates. Symlinks are shown but never followed.

  3. Select what you need

    Tick individual files, whole folders, or switch to a database or full-account restore instead.

  4. Choose where it lands

    Over the original, or into .recovery/ for a side-by-side look. This is the decision the rest of the page is about.

  5. Watch it run

    Restores are queued and logged. The log is kept, so "what did we put back, and when" has an answer later.

Symbolic links are shown but never followed, so browsing a backup cannot wander outside it.

Where it lands

Over the top, or beside it

This is the choice that decides whether a restore is a fix or a second incident, and it is one toggle.

Restore in place

Straight back to the original path

The files go back exactly where they came from, and anything currently at that path is overwritten. This is what you want when you know the live copy is wrong - a corrupted upload, a broken edit, a plugin that mangled a template.

Nothing else is touched

Only the paths you selected are written. The rest of the site keeps running on the files it already has, so a one-file restore is a one-file change rather than a rollback of everything.

Restore beside it

Into a .recovery folder instead

Flip one toggle and the same selection is written under .recovery/ rather than over the top. Your live files are left completely untouched.

For when you are not sure yet

Put yesterday beside today, diff them, and copy across only what you meant to. This is the option to reach for when the problem is "something changed and I do not know what" - because restoring in place would destroy the evidence.

If you are not sure what broke, restore beside it

An in-place restore overwrites the evidence. Putting the old copy in .recovery/ costs you one toggle and keeps both versions on disk, which is the difference between diagnosing a problem and guessing at it afterwards.

How far back

Your window, and what happens outside it

Two numbers that sound like one, and the difference is worth a paragraph because it decides what an upgrade actually gets you.

Every plan gets a daily backup. How far back you can restore from is what changes with the plan - seven days at the entry level, up to 30 on the top one.

A backup that falls outside your window is not deleted. We still hold it, and it becomes reachable the moment you move up a plan. Upgrading gives you access to backups that already exist rather than starting a new clock.

Take one yourself before anything risky

You can trigger a backup at any point, and it sits alongside the daily ones. The right habit before a major plugin update, a theme change, or a deploy you are unsure about - and one you took yourself stays restorable by you regardless of the plan window.

Moving in?

Migration has its own pages now

Bringing a site across from another host is a different job from protecting one that already lives here, and it is covered properly elsewhere.

  • The WordPress plugin

    One plugin on your current site, no SSH, and it stays online while we pull it across.

  • Over SSH

    Shell access to the old server means we find the installation ourselves and move it with rsync.

  • Or we do it

    Included on paid plans. Our team runs it, checks the result, and walks the DNS switch with you.

Pricing

Simple, transparent pricing

Every plan includes managed WordPress, SSH access, daily backups, and enterprise-grade security. Start with a 14-day free trial.

Startup

Great for growing businesses

$7.99/mo

$94.99 billed annually

  • 1 website
  • 10 GB storage
  • ~10,000 visits/month
  • 5 MySQL databases
  • 250,000 inodes
  • 5 FTP users

What's included:

SSL & Domain

  • Free SSL certificate
  • Free starter domain

Apps & CMS

  • 1-click WordPress
  • Managed WordPress
  • WordPress staging
Most popular

Advanced

For professional websites

$14.99/mo

$179.99 billed annually

  • 5 websites
  • 20 GB storage
  • ~110,000 visits/month
  • 10 MySQL databases
  • 500,000 inodes
  • 10 FTP users

Everything in Startup, plus:

Backups

  • 14 days of backup history

Performance

  • Memcached object cache
  • Redis object cache

Monitoring

  • 5 minutes between checks

Pro

Maximum performance and features

$22.99/mo

$274.99 billed annually

  • 10 websites
  • 40 GB storage
  • ~200,000 visits/month
  • 20 MySQL databases
  • 750,000 inodes
  • 20 FTP users

Everything in Advanced, plus:

Deployment

  • 2 SSR applications

Backups

  • 30 days of backup history

Monitoring

  • 1 minute between checks

On every plan

The layer you are glad of later

Immutable daily backups, kept off the server and out of reach, with a restore you can point at a single file. Included in every plan, running from the first day.

Questions

Frequently asked questions

When do backups run, and do I have to set them up?
Daily, during off-peak hours, and no. There is no schedule to configure and no plugin to install - it starts with the account. You can also take a backup yourself at any point, which is the sensible thing to do before a big update.
Can I restore a single file?
Yes, and it is the most common kind of restore. Open a backup, browse it like a file manager, tick the file or folder you want, and restore only that. You can do the same for a single database without touching any files.
What is the difference between restoring in place and to .recovery?
Restoring in place puts the files back exactly where they came from and overwrites whatever is there now - right when you know the live copy is broken. Restoring to .recovery writes the same selection into a separate folder and leaves your site completely alone, so you can compare the two before deciding. If you are not certain what changed, use .recovery: an in-place restore destroys the evidence you would need to work it out.
How far back can I go?
Seven days at the entry level, up to 30 on the top plan. Worth knowing: a backup outside your window is not deleted - we still hold it - so moving up a plan gives you access to backups that already exist rather than starting a new clock.
Where are the backups kept?
On separate backup infrastructure in a different location from the server running your site, not on the same disk. Each account has its own storage volume, and the backup taken each day is written read-only so it cannot be changed afterwards.
Could ransomware encrypt my backups too?
No. Your backups are immutable - written once, on separate infrastructure, and never writable again from your side. There is no path from your hosting account to your backups that could encrypt or overwrite one, which is the whole reason they are kept off the machine rather than as files in a folder somewhere on it.
Whose responsibility are the backups?
Ours to run, yours to verify. We take the backups seriously - they are automatic, they are immutable, and they are kept away from the machine they protect - but no provider can promise that a backup will be there and complete on the one day you need it, and ultimately it is your responsibility to know that you have a working copy of your own data. The practical version: download a copy from time to time, and restore something into .recovery once so you have seen it work. A backup nobody has ever restored from is an assumption.
Can I download a backup and keep it myself?
Yes. Any backup can be packaged and downloaded through a secure link that expires after 24 hours. Useful for an archive before you cancel something, or for handing a copy to somebody who is not on your account.
Is a backup enough on its own?
It is the layer that makes a bad day survivable rather than the layer that prevents one. Container isolation, the firewall and bot protection reduce how often you need it. Backups are what you are glad of when all of that was not enough - which is why they are on every plan rather than sold separately.