I choose Gzip in the profile settings. The backup file is still suffixed ".gz" but it is just plain text. This may be related to #2393615: Compression not running (only when backing up entire site), I don't know. It only started since moving to 7.x-3.1, though.

Comments

brad.bulger’s picture

Zip seems to work, in that it's actually a zip file. Bzip is the same as Gzip, suffix applied but file is plain text.

brad.bulger’s picture

it's only a problem for downloads, caused by this line (for gzip):

    if ($this->mimetype() == 'application/x-gzip') {
      $headers[] = array('key' => 'Content-Encoding', 'value' => 'gzip');
    }

i guess what's happening is that the browser interprets this as the page having been compressed for transmission and decompresses it. if i comment that line out, the downloaded file is a gzip file as expected.

ShaunDychko’s picture

Just want to confirm that this is an issue, and add that different browsers interpret things differently. With the same website accessed from a Mac OS X:
1) using Firefox the downloads are compressed
2) using Chrome they are not compressed despite the .gz file extension.

quantos’s picture

Hi guys. Would this explain a sudden hike in current backups that were working perfectly (on Chrome) roughly four days ago? I was just online trying find out why on earth my usual site backup size has leapt from circa 2.3 MB to 28.6 MB? I only noticed this today after a 3 day UK holiday - but have spent the last 1+ hr rolling back to previous site versions but each fresh backup (Backup Migrate v 7.3.0) is now exactly 29,359 KB (28.6 MB) regardless of previous size.

PHPmyadmin is still backing up fine (using gzip, also only tested in Chrome so far) and the full sql.gz backup size is around 5.2MB. I.E. something is adding more than 24MB of data to the Backup Migrate backup (data only) back-up. My only previous backup that didn't have the problem has the data/time stamp of xxx-2015-05-21T18-51-47.mysql.gz.

Is the same problem? Is there anything I can supply to help diagnose?

Q.

quantos’s picture

Update: Thanks for the tip @shaunDychko. I can confirm my issue seems to be the same in that Firefox can backup/compress properly with the same (gzip) settings - so this would appear to be a brand new Chrome issue (in my case at least).

Do let me know if you could use any other data/info to help with this.

Q.

EDIT: just for further clarification: dev set-up here is Windows 7. Chrome browser is latest. Firefox version is also the latest (38.0.1) on the same machine.

rtrapmonf’s picture

I am seeing exactly the same in Chrome on Windows 7. Typical gzip files have suddenly ballooned in size with Chrome, but have remained nice and lightweight with any other browser. This looks to be a Chrome (version 43.0.2357.81 m) issue that's cropped up, not a Backup and Restore issue.

ergophobe’s picture

I can confirm this behavior - since updating to 3.1, the gzip save works fine in Firefox, but in Chrome I get a plain text file with a .gz extension.

Chrome (version 43.0.2357.81 m) issue that's cropped up, not a Backup and Restore issue.

I might be inclined to blame the browser or a host of other things if it concerned compression of a standard page. When serving a regular page, the server should respect the browser's Accept Encoding and only send compressed files if the browser can accept it. Of course Chrome can, but many anti-virus programs strip the Accept Encoding header because the AV software can't scan gzipped files. But since this is essentially a file download, it's surprising the browser has an effect.

Anyway, the simple test is to see if you can download a .gz file in Chrome (you can). Also, this was working fine until I upgraded Backup and Migrate. It's not a Chrome upgrade that triggers this. So it's most likely something in Backup and Migrate and specifically something that has changed since the last version.

brad.bulger’s picture

i confirmed that this is broken in the 3.x branch. it's the Content-Encoding header - you can download a gz file directly because that heading isn't set in that case. a simple PHP test confirms it's what's making the difference in Chrome (and whatever other browsers might have this problem). that header was added to fix a problem with files being compressed twice
https://www.drupal.org/node/1564408#comment-9332441

so presumably any fix has to solve both problems. if that's possible...

brad.bulger’s picture

usmanjutt84’s picture

There is no .zip compression option on my site to set up profile. It was available before.

couturier’s picture

Status: Active » Closed (outdated)

@usmanjutt84 I am closing this issue because it is based on a version that no longer exists. Please try the new 7.x-3.x version released September 27, 2017, and see if it resolves your problem. If not, please open a new issue with the correct version listed. Also note that a new stable release of D8 Backup and Migrate is expected soon if you are moving sites to D8.

brad.bulger’s picture

this is one way to clear a bug queue i guess. yes it still happens. i will create a duplicate issue.

couturier’s picture

@brad.bulger I apologize for the confusion, but you could also set this issue to active again and simply update the version if you haven't already filed a duplicate issue. If you did file a duplicate issue, would you mind linking it here for reference? Thanks.

BrankoC’s picture