I can use drush sql-dump to get the production db from my remote server and save it to my local machine no problem using:

drush @site-live sql-dump > /home/backups/my_db_backup.sql

but i want to enable the --gzip option to make the process faster which i've tried with

drush @site-live sql-dump --gzip > /home/backups/my_db_backup.sql.gz

but i get this error from archive manager in Ubuntu:

gzip: /home/backups/my_db_backup.sql.gz: not in gzip format

For starters...can i actually use --gzip with sql-dump?

UPDATE: the problem appears to be that "stdin: is not a tty" is being appended to the first line of the file whether it is a plain .sql or a .sql.gz file

  • Which PHP version are you using?
    – kenorb
    Jan 29, 2015 at 20:20

3 Answers 3


Here are few checks you should do:

  • make sure that your gzip program is in your $PATH (just check if you've gzip command),
  • disable any drush verbose messages to avoid printing any extra lines from terminal which could break the compression,
  • temporary use -vd to check how the command look like (Executing or Backend invoke) and make sure you've --gzip in your argument list, if it's not - you're getting the plain version of it for some reason (so you can redirect to .sql file instead)

If your --gzip is not invoked, even you're specifying one and gzip is configured correctly, then it's probably a drush bug. I think this could depend on PHP version which you're using as I've the same problem with PHP 5.5.


From a quick search this seems to be a ubuntu(debian?)-specific issue, as it doesn't by default open a tty for a remote ssh session (your command worked fine for me on CentOS). Try adding --tty as an ssh option to your drush command.

Maybe of use: https://www.drupal.org/node/1783330

  • thanks for this but this is what gets written to the .sql file when adding --tty: stdin: is not a tty Unknown option: --tty. See drush help sql-dump for available[error] options. To suppress this error, add the option --strict=0. Jan 30, 2015 at 11:03

OK i managed to solve this, the first thread in this question made me check my centos server to see if the mesg y was still in any of the bashrc files and i found the culprit in /etc/bashrc on my centos box. I was logging in from a terminal to whm from Ubuntu (whether Ubuntu made a difference i'm unsure).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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