I crafted my drush/sites/self.site.yml like below* and verified that drush rsync @prod:%files @self:%files worked. However, drush sql-sync @prod @self results in the following error:

  The command "/usr/local/bin/drush sql-query --strict=0 --file=/tmp/termitral_db_20211011_110905.sql.gz --file-delete --uri=drupal --root=/var/www/drupalvm/drupal/web" failed.

  Exit Code: 1(General error)

  Working directory:


  Error Output:

  In SqlCommands.php line 199:

    Query failed.

  sql:query [--result-file [RESULT-FILE]] [--file FILE] [--file-delete] [--extra EXTRA] [--db-prefix] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--database [DATABASE]] [--target [TARGET]] [--db-url DB-URL] [--notify [NOTIFY]] [--druplicon] [--xh-link XH-LINK] [--] <command> [<query>]

On closer look (aka verbose), I noticed this** and I was told on Drupal Slack that --file only takes an uncompressed SQL file (I later verified this). So my question is, how can I fix this dreadful error?


  host: example.com
  user: user
  root: /data/web/public_html/web
  uri: default
   - files: sites/default/files


// Copy new and override existing files at
// /tmp/termitral_db_20211011_103342.sql.gz. The source is
// termitral@termitral.com:/data/web/drush-backups/termitral_db/20211011103342/
// termitral_db_20211011_103342.sql.gz?: yes.


The command "/usr/local/bin/drush sql-query --strict=0 --file=/tmp/termitral_db_20211011_103342.sql.gz --file-delete --uri=drupal --root=/var/www/drupalvm/drupal/web" failed.
  • 1
    I remember this issue from one DDEV project and the workaround was to simply check the /tmp directory, because the file gets downloaded but not imported somehow, and then gunzip and import the database from there. ddev ssh and there cd /tmp, then ls -lhA to get the latest database file name, and then gunzip < test_20210928_110056.sql.gz | drush sqlc. It's just a workaround though. And only happened in one single DDEV instance. Still not solved, yet.
    – leymannx
    Oct 11 '21 at 12:27
  • Which version of Drush BTW?
    – leymannx
    Oct 11 '21 at 12:27
  • Yeah, sorry. 9.7.3.
    – Kartagis
    Oct 11 '21 at 13:13
  • Can you confirm the workaround? That the downloaded database actually exists in the /tmp folder and just the import didn't work?
    – leymannx
    Oct 11 '21 at 15:09
  • It exists in /tmp and import didn't work. It only works if I decompress it.
    – Kartagis
    Oct 11 '21 at 16:23

More information about others with the same problem (https://github.com/drush-ops/drush/issues/4319#issuecomment-790558557)

There are two ways to solve this:

  • Upgrade drush to v10 (better even would be 11)

  • Or, patch your current drush using something like the following:

    diff --git a/includes/drush.inc b/includes/drush.inc
    index a8f356ff8..85d56f617 100644
    --- a/includes/drush.inc
    +++ b/includes/drush.inc
    @@ -352,6 +352,7 @@ function drush_file_is_tarball($path) {
       $supported = [
    +    'application/gzip',

Good luck!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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