Website backups and recovery points

A recovery point is the whole website at a moment: its databases and then its files, in that order, so the database is never newer than the files that expect it. A file snapshot is the files alone, which is the quicker thing to take before you change something and the quicker thing to put back when a deployment goes wrong.

Databases are also backed up on their own, and Dashmox keeps up to ten of those per database, which is what you want when the mistake was a bad query rather than a bad release.

Under Automatic backups, a website is set to daily or weekly and Dashmox keeps up to seven, replacing the oldest as it goes. Daily with seven kept means a week of history; weekly with seven means roughly seven weeks of it. Choose by how much work you would be willing to redo, not by how much disk you have.

Frequency    daily
Hour         3        (the server's clock)
Keep         7        (a week of history)

And a site that only changes when you change it:

Frequency    weekly
Day          0        (Sunday)
Hour         4
Keep         7        (about seven weeks of history)

• Daily for anything with customers, orders or comments in it.
• Weekly for a site that only changes when you change it.
• A manual one before any upgrade, whatever the schedule is. It will not be swept away by the retention.

A schedule that stops producing backups looks exactly like one that is working, right up until somebody needs to restore. That is why it is one of the health checks, and why the check is worth leaving on.

Website backups kept on the machine are there for the ordinary case: a bad deployment, a wrong delete, a broken plugin. They do not survive the server itself being lost, which is the case people actually fear.

Off-site backups send copies somewhere the server itself is not. Set that up once and the same schedule that fills Local website backups fills the off-site copies too.

A website snapshot carries files alone. A recovery point carries the databases too. An off-site copy of a snapshot is the same archive as the local one, so it holds the public, private and app directories and nothing from the databases. A recovery point holds the files and a dump of every database together, and it can be copied off the server as a whole: press Copy off-site on the point and every part is sent, one at a time.

A point counts as copied only when every part has arrived. A link that drops half way through leaves it partly copied, which the panel says plainly, and Finish copy sends what is missing. A partly copied point cannot be restored from elsewhere at all, deliberately: restoring a website whose database is missing gives you an application that starts and has nothing in it, which looks like the backup having failed when it is the half that never arrived.

So for an application, copy recovery points off-site rather than snapshots. Snapshots are the right thing for a bad deployment or a wrong delete, where the database was never the problem.

Three Dashmox servers Each sends last night's archive in pieces.

Only what changed A piece already held is not sent again. 25.3 MB the first night, 216 kB the second.

One backup server Anything the three have in common is stored once. No licence, no database, no sign-in of its own.

There are two ways to do it, and they cost very different amounts of bandwidth.

A Dashmox backup server is a machine of your own running one small program. It stores an archive in pieces, so the next night it takes only the pieces that changed. On one measured run over the internet on 27 September 2026, a 108.9 MB archive sent 25.3 MB the first night and 216 kB the second, after a single file had been edited. One backup server can receive copies from several Dashmox servers and stores anything they have in common once, and it needs no licence, no database and no sign-in of its own. What one server sends is invisible to the others: none of them can see, fetch or even test for another's backups.

S3-compatible storage or an SFTP server works with anything you already have, and sends the whole archive every time. That is the difference between the two, and for a small website it may not matter.

Either way, a restore is checked against the backup's own record before a single file is written.

Setting a backup server up is the same one command that installs Dashmox, with --server-type backup added. It installs none of the panel on that machine: no web server, no database, no PHP and no licence. It prints the machine's host key, which you confirm in the panel when you add it under Off-site backups; the panel then shows you a line, and running the command once more with that line's name and key lets that panel send its backups. Repeat it for each panel that should share the server.

The panel's own configuration is backed up and restored separately from the command line, so rebuilding a server does not mean rebuilding every website by hand.

A restore asks you to type the website’s domain back before it runs. That is the only guard between an afternoon and yesterday’s data, so it is deliberate friction rather than a formality.

While a database backup runs, that database is briefly held read-only so the copy is consistent. The window is bounded at an hour and normally lasts seconds.

An untested backup is a belief, not a plan. The cheapest way to find out whether your website backups work is to take a copy of a site, which gets its own database and so is a real staging site rather than a second name for the live one, then restore a recovery point onto that instead of onto anything that matters.

Do it once, while nothing is wrong. The thing you learn is usually not whether the backup exists, but how long the restore takes, and that is the number you will want on the day.