In a recent commit I got the site backup functionality working again, and then implemented an index for backups that are contained on a server.

I modified the front end to display the list of available backups. This is just a basic form, it desperately needs to have a confirm form added, and lots of other 'be wary there be dragons here' type language.

I added an additional hook_hosting_provision_$type_cmd , which allows you to override what is passed to the command line (and write your own commands). This still feels a bit dirty, but it works for now. (see comments in code).

I am busy working on the back end "restore" command now, which is in the format of drush.php provision restore sitename.com /path/to/backup.tar.gz

The process of an install will be :

1. Make a backup of the site as it currently is.
2. Make the site unavailable ?? - To be decided.
3. Extract the backup tarball to $backup_path/$url.tmp
4. Create a new mysql database (possibly a new user account?) (site_$siteid_tmp)
5. Import the backed up database.
6. Copy the temporary sites directory over the present one.
7. Regenerate the configuration files.
8. Rename the old database to something, and move the new one back in it's place.
9. Verify that everything worked (but how?)
10. Make site available
11. Restart web server
12. Perform clean up (drop old database, remove $url.tmp directory).

The backup that was made will be available to the user if he decides to revert back to what he had before.

Keep in mind. This is for on the same platform only. Moving a site to a different platform is all these steps, with some slight variations.

CommentFileSizeAuthor
Select a backup to restore the site to37.67 KBadrian

Comments

anarcat’s picture

Project: Hostmaster (Aegir) » Hosting

So I think this is related to the hosting module.

anarcat’s picture

Category: task » feature
adrian’s picture

Version: » 5.x-0.1-alpha1
Priority: Normal » Critical

From the comment i just put into provision.inc

/**
 * Restore command implementation
 *
 * This command when called will 
 *   1. Make a backup of the current site, before modifications are made.
 *   2. Temporarily disable the site by causing apache to redirect to a help page. Restarting apache is required.
 *   3. Extract the backup that is being restored to to a temporary folder in the sites directory.
 *   4. Create a new database, belonging to the site's user, and switch it around with the current site's database.
 *   5. Import the old database and site.php details.
 *   6. Switch around the sites directory of the current site and the backup being restored.
 *   7. Regenerate configuration files.
 *   8. TODO: diagnostic to test that everything is ok?
 *   9. Remove the temporary redirect and restart apache so the previous site is available again.
 *   10. Remove the extranuous db and duplicate site directory.
 *
 * If at any time an error occurs, before step 9. It should reverse all the changes it has made,
 * and leave the current site directory and database in the right place, and remove all cruft that
 * was created by this process.
 */
adrian’s picture

completed so far :
1, 2, 3, 6, 7, 9

The mysql bits got annoying, as i found out there's no way to rename a database.

http://drupal.org/cvs?commit=120930

adrian’s picture

Status: Active » Needs work
adrian’s picture

This is in the latest commit. needs testing.

boris mann’s picture

Adrian, one thought here is that we do something like restore.example.com -- so that restore.example.com is temporarily available for review to check that everything is working. If everything is OK, the switch happens and the restored version goes live. The same could be true for upgrades, temporarily making upgrade.example.com available.

anarcat’s picture

I think this is a seperate issue. Let's start by having restore working by overwriting site N and then we can think of doing restores in a new site or over a different site.

restore doesn't currently work:

sh-3.1$ php "/var/hostmaster/webroot/profiles/hostmaster/modules/drush/drush.php"             -r /var/hostmaster/webroot             -l hostmaster.koumbit.net -v hosting tasks 
Task starts processing
Executed: '/var/hostmaster/webroot'/'profiles/hostmaster/modules/drush'/drush.php 'provision' 'restore'  'test.hostmaster.koumbit.net' --root='/var/hostmaster/webroot' --uri='hostmaster.koumbit.net'  --task_id='137' --publish_path='/var/hostmaster/webroot' --site_id='8' --site_db_host='localhost' --site_db_type='mysql' --web_id='3' --web_host='hostmaster.koumbit.net' --client_id='1' --client_email='webmaster@localhost' --backend
Could not find backup file 
warning: Missing argument 2 for _provision_restore() in /var/hostmaster/contributions/modules/provision/provision.module on line 600.

adrian’s picture

Status: Needs work » Fixed

This is fixed, i've tested it on 3 different servers, and is live on hm2.bryght.com.

anarcat’s picture

Status: Fixed » Closed (fixed)

I confirm the fix.