Drupal Answers is a question and answer site for Drupal developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having an issue with the Drush arr command working correctly. I use drush to backup an archive on a testing server and then move it to a live server, or vice versa when needed.

Here is a typical command I use for restore

drush arr --db-url=mysql://name:pass@localhost/mydb

The database credentials on the test server are different from the live server. When drush completes the restore process it does so correctly and then says "the database credentials are appended to the bottom of the settings.php file"

That's great, and it indeed appends the correct information about the database, but this never works.

drupal always tries to read the original database configuration that comes before the appended information.

So, I always have to open up an editor, open up the settings.php file, scroll down to the bottom, remove the appended information, then manually go back and change the config information.

This is a huge waste of time.

How do I use this command correctly to avoid that? I want to seamlessly be able to type the command and immediately start using the site without having to manually edit anything.

Also, given that the database config variable is an array, how do I just tell the settings.php file, via drush, to use one or the other? If I have config for a testing environment and a live environment, I simply want to tell it which one to use as needed.


I wanted to add some more information as to the errors I get as well as the settings.php information.

So, immediately after using the command above, this is the error I get on the server I am restoring to:

PDOException: SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost'
(using password: YES) in lock_may_be_available() (line 167 of 

Here is what the settings.php file contains for the original db configuration:

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'mptest',
      'username' => 'root',
      'password' => 'mypass',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',

Here is what is appended to the end of the settings.php file:

// Appended by drush archive-restore command.

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'driver' => 'mysql',
      'username' => 'name',
      'password' => 'pass',
      'port' => '',
      'host' => 'localhost',
      'database' => 'livedb',

This looks to be the same except that the sequence for the config is different than the original. Even so, I get the error as stated above. Could the config property sequence be causing this?

share|improve this question
up vote 3 down vote accepted

settings.php is just an executable php file, so it seems on the surface that there should be no reason for you to do the editing step described above as long as

a) you have not inserted anything in your settings.php file (like a 'return' statement) that halts execution before the end


b) the database information that Drush writes at the end of settings.php is the same as the database information you hand-edit into the normal location.

If you are doing the editing information because the database information on your testing server is DIFFERENT than the database information on your production server, then you would be better off using sql-sync to migrate your database from one to the other, and migrate your code with either drush rsync or a version control system such as git. By default, drush rsync will not transfer your settings.php file, so you can customize it in each location and not have to worry about it being overwritten. If you use a vcs, you could exclude settings.php e.g. by using a .gitignore file.

Finally, I should add that it is only viable to use sql-sync or archive-dump/restore to move a whole site from testing to production BEFORE you have user generated content. If you ever have users who create accounts, add content, post comments, etc., copying the whole site will overwrite all of that information. Usually, folks copy the database from live to test only, and copy only code from test to live. To move configuration, look into the features module, or drush ctools export bonus.

Update: archive-dump / archive-restore does support changing database specs, and seems to be working correctly per your use case described above. Note, however, that you said in your updated text that the two db records are the same, but in fact they have different database names. This, I expect, is as it should be; I further presume that the database info archive-restore is writing to the end of settings.php matches the info you pass in on the command line.

share|improve this answer
added some extra info that may help. Also, I have changed the settings.php file. I have added the memcache module settings per the memcache installation instructions, which includes 2 'include_once' calls and additions to the $conf variable. – blue928 Jan 8 '13 at 7:35
the answer is in my reply above; Drush archive dump saves the name of the database as you dump it, and restores it as it was saved. Since you want your database to be 'mptest' on one system, and 'livedb' on the other, archive dump does not meet your requirements. Try sql-sync. – greg_1_anderson Jan 8 '13 at 15:15
Said something crazy above - please ignore. Anyway, it looks like archive-dump is working correctly. Try adding a var_export($databases); at the end of your settings.php. If this works, your page render will be all messed up, but you can prove that execution reached the end of settings.php if it is. If nothing is printed, isolate your problem by putting print statements elsewhere in your settings.php file. If this sounds too inelegant, you could set up a source level debugger, and step through settings.php. See drupal.org/node/147267 and elsewhere on google. – greg_1_anderson Jan 8 '13 at 15:22
thanks for the var_export suggestion, that's a good idea to test it out. Once I have this all sorted, I'm happy to play with sql-sync and rsync. Being new to drush I didn't even know what those are for. But, tangent question. Is arb and arr mostly for just the creations of backups and restores on the same server? How and when is the best use of those commands? – blue928 Jan 8 '13 at 23:58
I don't use arb and arr much. Mostly I run this from cron: github.com/greg-1-anderson/utiliscripts/blob/master/… You have to set it up manually, but once it's running, it makes daily backups of my sites, and also makes update.example.com with all of the latest module updates applied, so that I can easily test and deploy whenever I have time. – greg_1_anderson Jan 9 '13 at 2:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.