How do backups work, and can I restore just one file

Automated backups run daily and weekly for every plan, from the smallest order upward, and they are not a paid tier. Restores go through the control panel and are granular: a single file, a single database, or the whole account. You are not forced into an all-or-nothing rollback that undoes three days of unrelated work to recover one deleted page.

Why granularity is the important part

The frequency of a backup schedule gets all the attention, and it is the less useful half. The realistic disaster is not a server that vanished. It is somebody deleting the wrong file, a plugin update breaking one table, or a client asking for a page that was replaced last Tuesday.

An all-or-nothing restore turns each of those into a choice between losing the recent work of an entire site or living with the damage. Granular restore turns them into a small operation with no side effects, which is the difference between a backup system you actually use and one you avoid.

What you can pull back

• A single file or directory, without touching anything else.
• A single database, useful when an application update has left the tables in a state the code no longer understands.
• The whole account, for the case where starting from a known-good point is genuinely simpler.

The gap in any schedule

Between two scheduled runs sits a window, and the change you most want to undo is often the one you made inside it. Nothing about a schedule closes that gap; a habit does. Before any change you would describe as significant, take your own copy of the files and database first. It takes a minute and it covers precisely the case the schedule cannot.

Keeping an off-platform copy of anything genuinely irreplaceable is the other half of the same habit. Platform backups handle ordinary failures well. A copy that is not on the platform is what handles the unusual ones.

Test it before you need it

This is the recommendation people acknowledge and skip, so it is worth being blunt: a backup you have never restored is a belief rather than a safeguard. Do it once, deliberately, on a site where the outcome does not matter, and find out how long it takes and what it does not include.

1. Restore a single file to a test location and confirm the contents.
2. Restore a database copy and check the application still starts against it.
3. Note how long each took, so a real incident has a known cost rather than an unknown one.

On an estate, do this on one account rather than all of them, then trust the result across the rest. What the availability commitment covers is in Uptime and Backups, and if you want to own the restore strategy end to end, a VPS hands you the operating system with it.