Wedge

Yesterday we learned that SMF's database backup "feature" is somewhat of a mixed-blessing - and I'm being polite here. Apparently the backup files may not necessarily be complete - contain all the records for all the tables. As it stands it serves little more than provide a false sense of security.

As I understand it, that feature was added to help those on free hosting where there may be a limited host Control Panel that doesn't include MyphpAdmin which would otherwise be used to backup and restore databases. But since SMF doesn't include a "restore" counterpart, it's all a bit half-arsed.

Now I do, I think, understand why the backup could fail and if I understand correctly, it's all about maximum execution times. But that surely is down to bad design in the first place?

Here's an idea for you. Would it not be better to have a backup system that runs in background via a scheduled task and rather than emitting a SQL "dump", it outputs table structures and data in XML format. It could do this table by table either as a complete backup or as a partial - all records added from a given date - thus allowing for incremental backups (but I do recognise that may entail time-stamping all records which may not be desirable). A complementary "restore" system would then simply prompt for a (compressed) backup file which is then decoded and updates the database. As both backup and restore would process manageable "chunks" of data, obtained via queries, the maximum execution time limit should not be exceeded.

Or am I being naive and overly simplistic? Forgive me if I am, please.

I mentioned "Repair" in the title for a reason. Would it be possible for Wedge to inspect its various tables and remove records that are incomplete or appear logically to be extraneous? My reason for asking this is simple: I appear to have a number of extra rows in the Aeva Permissions area - ie sets of permissions for membergoups that don't exist and have no membergroup name assigned and I don't know if I can safely remove them (and the only way I can see of doing that would be to edit the SQL to remove them, put the site into maintenance mode, delete that table and recreate it at the server level).[1]

I do appreciate that an analysis/repair function is a bit of a tall order and not really necessary as a core function - although backup/restore arguable should be - and best dealt with by a plug-in.

Again, my apologies if I'm being a prat!

1.	I am not asking for support for Aeva here, it's up to me to sort this out best I can, but merely mention this as a live example of why an analysis/repair module would be a desirable feature.