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.
| Comment | File | Size | Author |
|---|---|---|---|
| Select a backup to restore the site to | 37.67 KB | adrian |
Comments
Comment #1
anarcat commentedSo I think this is related to the hosting module.
Comment #2
anarcat commentedComment #3
adrian commentedFrom the comment i just put into provision.inc
Comment #4
adrian commentedcompleted 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
Comment #5
adrian commentedComment #6
adrian commentedThis is in the latest commit. needs testing.
Comment #7
boris mann commentedAdrian, 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.
Comment #8
anarcat commentedI 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:
Comment #9
adrian commentedThis is fixed, i've tested it on 3 different servers, and is live on hm2.bryght.com.
Comment #10
anarcat commentedI confirm the fix.