What your backups actually cover, and what they do not

Automatic backups run on every account here. That is not the same as your network being protected, and the gap between those two statements is where people lose data. What matters is retention, location, and whether anyone has ever tested a restore.

Four questions to answer for your own estate

1. How far back does it go? A backup from last night does not help if the damage was introduced three weeks ago and you only noticed today. Silent corruption and slow compromises both exceed short retention windows.
2. Where does the copy live? A copy on the same account is convenient and protects you from exactly one scenario: you deleting something yourself.
3. What is included? Files and databases, yes. Email, cron jobs, DNS zones and certificates are the ones people assume and then discover were not there.
4. Has a restore ever been tested? An untested backup is a belief, not a plan.

The three-two-one habit, adapted

The standard advice is three copies, two kinds of storage, one off site. On a hosting network that translates to something simple:

• The automatic server side backup, which you did not have to arrange.
• A copy you download somewhere else, on a schedule you actually keep.
• For anything genuinely valuable, a third copy that is not in the same place as the second.

The middle one is the step almost everybody skips, and it is the only one that survives losing access to the account entirely.

What restores are actually for

People imagine catastrophic failure. In practice restores are used for:

• An update that broke a site, discovered an hour later.
• A deletion by someone who had access and should have been more careful.
• A compromise, where you need a copy from before it happened.
• Recovering one file or one database table, not a whole site.

That last case is the most common and the most annoying to handle badly. Being able to restore a single item without rolling the whole site back is worth more than any amount of storage.

Test one restore, once

Pick your least important site. Restore it into a location that is not the live site. Confirm it loads, the database is intact, and the content is the content you expected. Then throw it away.

Doing this once tells you what your backups actually contain, how long a restore takes, and what steps you would forget under pressure. That knowledge is the point, not the restored copy.

Backups on a multi-site network

Two things change when you have many sites:

• Storage adds up. Several generations across thirty accounts is real disk and real inodes, and backups kept on the account count toward the same ceilings the sites use. See Platform and Limits.
• Timing matters. Thirty backups starting at the same minute is a load spike. Stagger them the same way you stagger cron.

Before any risky change

Take a manual backup immediately before you do something you might regret: a platform version change, a bulk operation, a migration between accounts. The automatic schedule is a floor, not a substitute for a snapshot taken thirty seconds before the thing that broke it.

The backup interface is documented at docs.cpanel.net. For the operations most likely to need a rollback, see Running Your Estate, and if you are unsure what your account's schedule covers, ask us rather than assuming.