Ask how often a site should be backed up and the answer is usually “once a night”. It is not a wrong answer, but people can rarely say why it is the right one. Frequency should not come from a tool’s default. It should come from how much time you can afford to lose.
That figure is often called the recovery point objective. The term matters less than the question behind it: “if the database reverted to last night right now, what would we have to recreate?”
Working it backwards
The answer differs wildly between sites. On a brochure site that publishes weekly, losing a night means rewriting one draft. On a site that takes enquiries and orders, a night is a record that cannot be recreated — you cannot reconstruct what a customer wrote, and they will not write it again.
So the deciding factor is not volume or cost but whether it can be remade. Split your data into things you could redo yourself (drafts, settings changes) and things that arrived from outside and are simply gone (enquiries, orders, registrations), and the interval almost picks itself.
A different interval per part
The three parts from the first article change at different rates, so their schedules diverge too.
It is easy to see why that last line is so common: one archive is simple to configure and finishes in one go. The trouble is that the price of the convenience is paid entirely on the day something goes wrong.
What frequent backups actually cost
More often is not free, so be honest about the cost. A database dump consumes server resources while it runs. Taking a large dump during a busy period can briefly slow the site, which is where the convention of running them overnight came from.
The other cost is storage. Frequent backups accumulate quickly, and accumulated copies are both an expense and a privacy exposure — a subject the seventh article takes on its own.
In short, there is only one decision to make: not “how often”, but “how much are we willing to lose”. Everything else follows. Write that answer down as a sentence, and when you change tools you can configure the new one against the same standard.
Turning operational standards into documents is covered in the Development workflow archive, and if you want backups and monitoring watched continuously, see InfraGuard passes.
Next part
However tight your interval, a backup sitting on the same server disappears with it. The next part is about where backups have to live.