Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Jumping the gun a little. drush will soon have the archive-dump command. It would be good to support this instead of or in addition to our current backup method.
http://groups.drupal.org/node/106754#comment-403749
http://drupal.org/node/1081610
I see two current issues with using it though.
1. The --no-core option mentioned doesn't appear to be in place?
2. Not sure how we would do the remove cloaking in the backup stuff.
Can't assign this to 2.x yet, but wanted to start the discussion.
Comment | File | Size | Author |
---|---|---|---|
#14 | provision-1138882-14-Support_drush_archive-dump.patch | 6.21 KB | helmo |
#11 | provision-1138882-11-Support_drush_archive-dump.patch | 6.24 KB | helmo |
#6 | provision-1138882-6-Support_drush_archive-dump.patch | 1.16 KB | helmo |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedGreat idea, i wanted to do this in 2.x, indeed. We should be backward compatible of course, but I think that's totally possible.
This will also allow us to import complete *platform* dumps too which is cool.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedThe stripping/uncloaking is theoretically not a big problem: our backup.provision.inc might simply be reduced to uncloaking and then directly invoking the archive-dump command itself.
Comment #3
Steven Jones CreditAttribution: Steven Jones commentedSubscribe.
Comment #4
omega8cc CreditAttribution: omega8cc commentedComment #5
pearcec CreditAttribution: pearcec commentedsub
Comment #6
helmo CreditAttribution: helmo commentedAs mig5 suggested calling drush_invoke practically does it all.
I added a patch to demonstrate.
I tested this with the drush-7.x-4.x branch and provision 1.x(as the code is pretty much still the same between 1.x and 2.x)
The lack of a --no-core option should be fixable in drush. As I also would like see the opposite option, to backup a platform (e.g. before being deleted)
Obviously the restore part would have to be adapted as well..
Comment #7
Steven Jones CreditAttribution: Steven Jones commentedI reckon that we need to get some tests written that test a site migration/clone before we can do any kind of major refactoring like this. Beginnings of that are here: #1267534: Factor out Jenkins tests into git
Comment #8
helmo CreditAttribution: helmo commentedI've created an issue in the drush queue to request a --no-core option, and did some initial work in a sandbox.
#1277484: --no-core option for archive-dump
I'd love to work together on this, and could open the sandbox up for more committers...
Comment #9
helmo CreditAttribution: helmo commentedI've had a look at the archive-restore part in drush.
And have come to the conclusion the provision would need much work to directly re-use the archive-restore command. I see conflicts with the OO approach provision has taken.
What we could do:
* detect the file format, (Aegir 1.x or archive-dump)
* interpret the MANIFEST.ini
* move files around
The todo's below could be a start to solving this...
Comment #10
anarcat CreditAttribution: anarcat commentedI am *really* happy to see some progress here, keep up the good work!
I do think the --no-core option in drush is a good idea.
Also, keep in mind we need to be backward compatible with aegir 1.x here - so we'll need to interpret tarballs without a manifest as 1.x backups (ie. site only) when importing. I do not see, however, an issue with always generating drush-compatible, 2.x-style backups by default in 2.x...
Comment #11
helmo CreditAttribution: helmo commentedMade some progress on this, but still going slow.
Comment #12
helmo CreditAttribution: helmo commentedIt would be nice if we could make this more pluggable...
e.g. to also support Hosting Drupal Gardens import and Hosting upload
Xref: #322788: generic import mechanism for external database dumps and site backups
Comment #13
Steven Jones CreditAttribution: Steven Jones commentedComment #14
helmo CreditAttribution: helmo commentedJust re-rolled the patch from #11 to be able to work on it further...
Comment #15
ergonlogicNew features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.
Comment #16
helmo CreditAttribution: helmo at Initfour websolutions for Aegir Cooperative commented