Drush archive-restore not restoring database nor giving error

Question

I have a Drupal 7 site and database in an archive created via Drush. I'm trying to restore it with Drush on a Mac running MAMP.

When I tell it to restore the site it says "[ok]" afterwards and the site files are in their correct destination, but it doesn't create and populate the database nor does it give an error that it couldn't.

I've made sure that their is a database user with the same name and password that is in the settings.php file.

My command is: drush archive-restore /Users/abailey/Downloads/dev-sbirt-reg.20140321_200259.tar.gz dev-sbirt-reg --destination=./dev-sbirt-reg

I added the -v tag hoping it might show me what the problem is and it outputs:

Mime type for                                                           [notice]
/Users/abailey/Downloads/dev-sbirt-reg.20140321_200259.tar.gz is
application/x-gzip
Executing: tar  -C /tmp/drush_tmp_1395439263_532cb69f676ea -xzf dev-sbirt-reg.20140321_200259.tar.gz
Archive restored to ./dev-sbirt-reg                                  [ok]
./dev-sbirt-reg
Command dispatch complete                                               [notice]

Any idea what I could be doing wrong or at least how I can figure out what I'm doing wrong? I would think at the very least I would get an error saying it can't connect to the database or something.

I'm running this from the directory I've set MAMP to use for holding site documents.

-Thanks

Answer 1

run the same command with --debug and a MYSQL error will likely be outputted to the screen.

So try:

drush archive-restore /Users/abailey/Downloads/dev-sbirt-reg.20140321_200259.tar.gz dev-sbirt-reg --destination=./dev-sbirt-reg --debug

Answer 2

It's definitely a long-time behaviour/bug(?) with ard/arr. I watch this behaviour since version 5.x that even if you give credentials --db-su / --db-su-pw to have rights to create new database on local lamp, the database gets created but not filled. But if you create the parallel named database before and run it with the same command it works. Since this happens under many circumstances in the last years there are no real details to provide for this to reproduce. Many cases, many servers, many years. It seems like the db creation process is interrupting the db build or the permissions are not correct when it tries to create AND to build from dump file in one step. It always needs a little kick to get finished correctly. Creating the db before, even if it suggests that this would not be needed, made it here mostly. I was thinking that I miss something or do something wrong in earlier days, but I came to the conclusion later, that this functionality is too case-sensitive to maintain it for all users and scenarios correctly, so I don't care to give the script some kicks to work.