Backups and restore verification
It backs itself up, then proves the backup works
The previous version of this website told you backups were your job. They are not, and saying so was throwing away the single best-engineered thing in the product. Here is exactly what runs, and exactly what it will not do for you.
- Every night
- Database, media, private documents
- Integrity
- A SHA-256 for every file, in a manifest
- Kept
- Seven runs by default
- Every Sunday
- The dump is rebuilt and row-counted
Nightly
What the nightly run writes#
At half past two each morning, into a folder named for that run:
- The database, as a compressed dump taken in a single transaction so the site does not have to stop.
- Media, meaning everything on the public disk: photographs, logos, uploads.
- Private documents, meaning the private disk: association documents, contact-form attachments and member-import files. These are backed up separately because they are separate.
- A manifest recording the format version, the timestamp, the site address, the database name, the list of tables, every file size, a SHA-256 for each file, and a hint about how to restore it.
A dump is rejected outright if the export command failed, if the result is under a hundred bytes, if it contains no table definitions, or if its first line does not look like SQL. The whole run happens in a folder marked incomplete and is only renamed into place when it finished; a failure deletes it, and an abandoned partial is swept up after a day. Successes and failures are both recorded, so the admin screen can tell you the difference between "no backup last night" and "nobody has looked at this since March".
Location
Where it is written, and where it refuses to write#
Backups go outside the web root: to a path you set, or to a folder beside the application, or to your home directory. The directory is refused, with a written explanation, if it is inside the public folder, inside the uploads root, inside the document root, inside the application folder, or if any part of the path is one of the usual public directory names. A backup somebody can download over the web is not a backup, it is a disclosure.
The folder is created private to your account and the files inside it likewise, with a deny rule and a blank index file added as a second layer in case the first assumption is wrong.
One detail worth the paragraph: the database password is never put on the command line. It is written to a randomly named, permission-restricted options file for the duration, because on shared hosting every other account on the machine can read the list of running commands.
Verification
The bit almost nobody does: proving it restores#
A backup nobody has ever restored is a rumour. So every Sunday at four in the morning, AlumDeck restores one.
Step 1
It makes a scratch database
Through your control panel's own interface where that exists, otherwise by creating one directly, otherwise by using a name you supplied. It refuses point blank if that name is the same as your live database.
Step 2
It imports the newest dump into it
And it will not import a dump that contains database-level commands, which is the class of mistake that turns a restore test into an outage.
Step 3
It counts every row in every table
Table by table, against the live database, and warns about any live table that is missing from the backup altogether. This is what turns "the file exists" into "the file contains what it should".
Step 4
It cleans up whatever happened
The scratch database is dropped or emptied in a guaranteed final step, so a failed verification does not leave debris behind on your hosting account.
The honest half
What backups will not do for you#
| Backups | AlumDeck does it | You do it |
|---|---|---|
| Taking the backup | Every night at 02:30, from cron | There is no "back up now" button. A backup killed by a request timeout is false comfort. |
| Checking it is not junk | Four integrity gates, plus a SHA-256 per file | Nothing |
| Proving it restores | Rebuilt into a scratch database every Sunday, every table row-counted | Nothing |
| Keeping old copies | Seven runs by default, older ones removed | Nothing |
| Getting a copy off the server | Not offered | FTP or SSH. There is no download route and no button. |
| Restoring | Not offered | The documented commands on the backups screen, or phpMyAdmin. Never call it one-click. |
Scroll sideways to see every column.
Two host requirements, both checked up front with a plain-English message: MySQL or MariaDB, and PHP's exec function. Where exec is disabled, backups do not run at all.
The one thing you must do
It only runs if the cron line is there#
One line in your hosting control panel runs the whole scheduler. Without it, eleven jobs silently never happen: announcements, queued work, event reminders, birthday greetings, the weekly admin digest, the monthly member digest, audit-log pruning, engagement scoring, email campaigns, backups and the restore verification.
Nothing looks broken without it. That is the danger, and it is why the backups screen prints a copyable cron line for every command, including the flag that some hosts need or else the scheduler prints its own help text and reports success. We know about that one because it cost us six nights of backups on our own server before we noticed.
Ask your host two questions before you buy. Can I add a cron job? Is PHP's exec function available? On mainstream cPanel hosting the answer to both is yes. Where it is not, everything else in AlumDeck still works, and this page is the thing you would be giving up.
Questions about backups#
Can I press "back up now"?
No, and that is deliberate. A backup started by a web request gets killed by the request timeout part-way through, and a half-written backup is worse than none because it looks like one. Backups run from cron only.
Can I download a backup from the admin panel?
No. There is no download route and no button. Copies come off the server by FTP or SSH, the same way anything else does. The files are plain gzip and tar archives, so nothing proprietary stands between you and them.
What does the weekly verification actually prove?
That the newest dump loads. It creates a scratch database, imports the dump into it, compares the row count of every table against the live database, warns about any live table missing from the backup, and then drops or empties the scratch database whatever happened. It refuses to run against a dump containing database-level commands, and refuses a scratch name equal to your live one.
What if our host does not allow this?
Then backups do not run, and the screen tells you so in plain English rather than failing quietly. Two things are required: MySQL or MariaDB, and PHP's exec function. Both are checked up front, including reading the host's own disabled-function list. Check them before you buy if backups are the reason you are buying.
Look at the backups screen on the demo
It shows the status, the retention and the exact cron lines. The restoring section is collapsed at the bottom, with the real commands in it.