Add the possibility to easily pack a development website to a tarball with 1 easy command and 1 argument (--domain).

$ drush quickstart-archive --domain=test.dev

Restore a previously pack development website with 1 easy command and 2 arguments (--domain, --archive).

$ drush quickstart-restore --domain=new.dev --archive=working.tar.gz

It's very conveniant to:

  • send your development website to someone else (using drupalpro);
  • create an archive before trying something dangerous on your installation;
  • restore an old version of your development website if you make it explose;
  • clone a development website (archive it and restore it on a different domain name).
CommentFileSizeAuthor
#1 drupalpro-7.x-3.x-dev_drush_qa_qr-1708418-1.patch7.31 KBKLicheR

Comments

KLicheR’s picture

KLicheR commented
Status: Active » Needs review
StatusFileSize
new drupalpro-7.x-3.x-dev_drush_qa_qr-1708418-1.patch7.31 KB

This patch add the 2 commands. I didn't use the Drush commands archive-backup and archive-restore but I don't think they offer the possibility to restore a website with another domain name.

drush quickstart-archive (qa)
(required) --domain=the_site_you_want_to_archive.com

  • Create a tarball with the code and the DB in ~/websites/.
  • The database name/username/password of file "/sites/default/settings.php" are replace with "#######_###".
  • All the instances of the old domain in the dump sql are replace with "#######.###".

drush quickstart-restore (qr)
(required) --domain=the_new_site_you_want_to_create.com
(required) --archive=the/path/of/the/archive.tar.gz

  • Create the DNS config.
  • Extract the code to a new directory.
  • Fix permissions.
  • Replace the "#######_###" values in "/sites/default/settings.php" with the new ones.
  • Replace the "#######.###" values in the dump sql with the new domain name.
  • Correct the length of strings in PHP serialized in the DB.
  • Import the new dump sql.
  • Create the apache configurations (and restart it).

Todos

  • Add the possibility to archive/restore a multi-sites installation;
  • Add an option (--destination) to store the tar.gz file wherever you want;
  • Add an option (--cache) to not automatically clear the caches when archiving.
mike stewart’s picture

mike stewart commented

seriously awesome! I've been planning to do this ... and have some bash scripts I have been using to packup/backup an entire installation. but this should be easy for me to include.

plus the benefit: a simple pull on the drupalpro directory will update older installations!

I can't review it right now... but should be able to get to it by tomorrow or Friday

chrisschaub’s picture

chrisschaub commented

Could the backup be done with drush arb or ard instead? That would make it easy to bring non-quickstart sites into quickstart. We have sites in production that we might want to bring down to dev, db, files, everything. Being able to bring a drush backup into quickstart would be very handy, and give us a neutral backup format. Heck, you could deploy with drush archive-restore from a quickstart site if you wanted.

mike stewart’s picture

mike stewart commented

@cschaub -- drush arb and arr currently work.

The only default drush 5.x command not working (to my knowledge) is the quick-drupal alias: qd

qd in quickstart, the drush plugin currently included with DrupalPro, is an alias for quickstart-destroy; which is kind of scary in the sense it has the opposite expected behavior as qd == quick-drupal (which creates a site using sql-lite)

chrisschaub’s picture

chrisschaub commented

I think what I was saying was instead of creating another backup strategy within quickstart, why not just use arb and arr. And do restores into quickstart with arr behind the scenes. So, instead of doing mysqldump etc in his patch, just use arb to create the tarfile backup of the site. And use arr in the patch to do the restore. That way, the tar.gz format would not be custom, but just a regular arb format. That way, you could dump a site with arb and bring it into quicstart with a drush qr command which knows about drush arb backups.

KLicheR’s picture

KLicheR commented

I ran into the multisites backup problem and I'm actually looking at the Drush built-in command for backup/restore integration.

The primary "problem" with Drush ard is that it dosen't do the "find and replace" in the SQL dump and the settings.php file. But I'll look if I can use a hook to alter some actions.

I would like to have something that can be use to easily (without too much parameters) backup a production environment without sensitive information (DB connection infos for example) that can be restore to a developer workstation.

I'll keep you updated.

chrisschaub’s picture

chrisschaub commented

Yeah, I've done some similar sed magic to make this happen in our environment. The real issue with sed is that people can tweak the settings.php file. Probably better to just read it in and modify the arrays, spit out a new file. I'm happy to help with this.