Backups are the easiest thing in hosting to claim and one of the harder things to do properly. The claim costs nothing. The proof costs storage, time and the willingness to discover that something is broken.
The Failure Modes Nobody Advertises
A backup job that has been failing silently for five months because a disk filled up and nothing was watching the exit code.
A database dump taken while the site was mid-write, producing a file that looks fine, transfers fine, and will not import.
Backups stored on the same server as the thing being backed up. Perfectly useful for an accidental deletion. Completely useless for the failure that takes the machine with it.
Retention that quietly rolled over, so the copy from before the problem started has already been overwritten by copies taken after.
Why This Persists
Because the gap between "we take backups" and "we have restored one recently" only becomes visible on the worst day. Until then both statements look identical from outside, and only one of them costs anything to maintain.
The provider is not usually lying. They genuinely do run backups. Nobody has checked that the output is usable, because checking is dull and nothing appears to be wrong.
What To Ask
Three questions, and you can ask them before you buy anything.
Where are backups stored, on the same machine or somewhere else? How far back can I go? And can I restore one myself, right now, without opening a ticket?
That last one matters more than it sounds. A restore you can perform yourself is a restore you can test. A restore that requires a support request at 2am on a Sunday is a restore whose timing is not up to you.
Our backups run off the server, you can see exactly what exists, and you can restore from the panel without asking anyone. Not because it is clever, but because a backup you cannot verify is just a hopeful filename.
