Backups progress
Okay, i thought i’d provide an update as to what’s going on with the backups module. Everything functions fine as to creating a backup and the process for restore is very similar but putting domain backups inside reseller backups and things like that are more complicated. Due to this i have followed the policy of one run of backup.php means one reseller, domain or user backup so far.
I have since decided to move backup.php to backups_backup and to make this run as a hook. The alternative was forking a backup function (which would have been very similar to just calling the hook anyway). If the hooks method doesn’t work out i will go back to the forking idea. But for now i’m working towards easy maintainability which means hooks.
I just committed an update in the CVS to webcp.php to improve the method used to tell the backend to call a hook. This now allows you to send $data to it in the $extra part of commit with the module to run rather than just the module to run. Whether data is global or not isn’t really helpful to me because obviously the backend and frontend are seperate so data has to be sent anyway. Now you can call a hook with some data in the backend from the frontend. In future i think forking the call_hook would be a good idea for security and performance. Maybe the seal should be checked or something i don’t know.
The idea is to register hooks as follows to allow a single call to call_hook(’server:commit:backup’, $data) to run the whole process from start to finish.
// Setup backup hooks
register_hook('server:commit:backup', 'backups_backup');
register_hook('server:commit:backup', 'backups_generate_archive');
register_hook('server:commit:backup', 'backups_ftp_archive');
register_hook('server:commit:restore', 'backups_ftp_archive');
register_hook('server:commit:restore', 'backups_restore');
Clearly calling server:commit:backup will be done by webcp.php using commit(’module’….). The idea is that the backup, generate_archive, ftp_archive and any other functions will all run on the data in sequence (i may have to sepcify priority to confirm they run in order i know there’s a way to do that with register_hook). This should make maintaining the module simple if all goes to plan.
Right now i’m working on moving to hooks rather than relying on calling backup.php from the backend with specific data and gathering it later.
EdG
Just realised that the backup hook cannot backup, generate an archive and ftp the data all at once, or else it makes the frontend / GUI part much harder without an extra level somewhere. So i have opted to seperate it into two hooks:
server:commit:backup
server:commit:backup:store
The first creates a backup of a reseller/domain/user, the second gathers together what is necessary e.g. for reseller backup would gather domains and users into one archive, then ftps to the local or remote server. This makes much more sense
EdG
Comment by edg — July 29, 2007 @ 11:54 am