People can simply examine the backup to see if it's good...
Most people wouldn't know if a backup was actually any good or not, just by looking at it. Even doing a test restore isn't foolproof, if the backup quit part way through while leaving a valid .sql file. SMF's backups can have some very subtle problems, including
- Hex strings are unquoted, leaving cases like 1234e567 which MySQL tries to read in as a floating point number.
- Sometimes integer fields get a '' empty string default.
- The backup can end in the middle due to timeouts, and the poor user is none the wiser.
- SMF backs up in chunks of 250 records per INSERT. If there are 250*N records, you end up with a superfluous INSERT with no data.
- Field names should be within ` because sometimes there are reserved keywords used as field names.
These are only the ones I know about. Some of them are fixed in my sig > Fixes. All of them can be fixed after the fact by editing the .sql file, except for loss of data due to timeouts, but it's delicate and time-consuming work (I know -- I've fixed several large backups for people).
Something is usually better than nothing...
Absolutely not. A backup should be complete and reliable, or you shouldn't produce one. People are
relying on this backup to protect them, and it looks very bad when it's no good.
Not all hosts offer database backup and restore functions...
That
is a problem. Question: if there is no way to restore a database, what is a user on such as host supposed to do with their SMF backup? Perhaps the solution would be to offer as a separate download utility (i.e., not built into SMF, to discourage people from using it) a simple
repaired backup and
restore utility. It could set the forum into maintenance mode, and run in smallish chunks to keep from getting timeouts. What say?