Unable to restore my database backup

too an error
backup_migrate 8.x-4.0
drupal 8.5.5 (composer)

Are you restoring through the module itself or using another method?

Hi @carlosmr96 and @rinso

Sorry for the late reply. Can you please post a little bit more info about the OS / version, web server / version, db server / version and also php version ? Also if you managed to resolve the issue in the meanwhile can you please comment back with findings?

Many thanks!

Closing issue due to non-response from the original poster.

Grant the "Apache2 HTTP server" right on files folder resolved the issue for me: open a command line in "default" folder if you use a GUI, or go there if you are in console mode and run:

chgrp -R www-data files

I am now getting this error as well. Latest version of Drupal installed via the composer project template and using composer to download and install the Backup Migrate Module. Site is running on an ubuntu server on WSSL with php7.2.

The Database sql file was exported out of phpmyadmin (without the caches being cleared). Php modifications implemented via .htaccess file to get past the 2mb restriction. File is 22MB, I've increased post_max_size to 30mb.

Restoring fails without a failure or explanation. The only thing logged in watchdog is a warning about the an ID within the module not matching.

I tried to add apache to the owners group, but that didn't work for me.

Any thoughts?

Nkendall it's possible your restore is failing for a different reason than the original poster. If you like, you are welcome to open a new issue. Like you said, it could be something about a module ID match.

This is clearly a bug.

I too am having this issue. I posted another bug report and Damien was kind enough to direct me here.

I'm running a Composer based version of Drupal 8.6.7 on my dev server MAMP Pro with PHP 7.2.10 and Apache 2. I installed B&M 8.x-4.0 via composer, and I created several backups using B&M; two were saved in private_files and one was downloaded. When I tried to restore any of the backups I ran into this issue. My upload_max_filesize and post_max_size have a 32MB limit, and the .gz backup file is only 1.5MB.

Hi, i have the same issue as well.
my backup file (Gzip) size is 2MB and my post_max_size and upload_max_filesize is 10 MB. However it not allow me to restore the backup file as it have exceed the filesize limit after unzipped. Is it possible that backup_migrate-8.x make it only detect the Zip file size instead of the actual unzipped file size?

I had the same with a database that happened to be created with DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci (no particular reason for it, that was the default setting). BM gave no sensible error message, just stated that it cannot restore and the log contained a complaint about unlink() not finding the temp file (the file was actually there, correct access, everything).

I am having the same problem as djg_tram. There's nothing in the error logs other than the below error.
And this is happening only with backups from my local environment. I have the same site running in other machines, but backups from them can be restored perfectly.

Warning: unlink(): Invalid argument in Drupal\Core\File\FileSystem->unlink() (line 121 of C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\lib\Drupal\Core\File\FileSystem.php) #0 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\includes\bootstrap.inc(587): _drupal_error_handler_real(2, 'unlink(): Inval...', 'C:\\Bitnami\\drup...', 121, Array) #1 [internal function]: _drupal_error_handler(2, 'unlink(): Inval...', 'C:\\Bitnami\\drup...', 121, Array) #2 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\lib\Drupal\Core\File\FileSystem.php(121): unlink('') #3 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\includes\file.inc(1100): Drupal\Core\File\FileSystem->unlink(false, NULL) #4 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\lib\Drupal\Core\StreamWrapper\LocalStream.php(377): drupal_unlink(false) #5 [internal function]: Drupal\Core\StreamWrapper\LocalStream->unlink('temporary://bam...') #6 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\core\lib\Drupal\Core\File\FileSystem.php(121): unlink('temporary://bam...') #7 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\modules\backup_migrate\src\File\DrupalTempFileAdapter.php(63): Drupal\Core\File\FileSystem->unlink('temporary://bam...') #8 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\modules\backup_migrate\lib\backup_migrate_core\src\File\TempFileAdapter.php(111): BackupMigrate\Drupal\File\DrupalTempFileAdapter->deleteTempFile('temporary://bam...') #9 C:\Bitnami\drupal-8.7.5-0\apps\drupal\htdocs\modules\backup_migrate\lib\backup_migrate_core\src\File\TempFileAdapter.php(58): BackupMigrate\Core\File\TempFileAdapter->deleteAllTempFiles() #10 [internal function]: BackupMigrate\Core\File\TempFileAdapter->__destruct() #11 {main}.

I am having the same issue. 8MB max upload size, and a 1.5MB backup file.

Machine name: backup_migrate
Version: 8.x-4.0

DRUPAL 8.7.6

The input file exceeds the servers upload_max_filesize or post_max_size limit.

backup-2019-09-17T19-51-32.mysql.gz Tue, 09/17/2019 - 15:51 1.43 MB

PHP Version 7.2.22
Linux 4.4.0-159-generic #187-Ubuntu SMP
Apache/2.4.41

MySQL - not sure which version.

Not on a shared server, Dedicated server

What is the uncompressed size of your archive? My 10 MB backup file expanded to some 51 MB and so ran into the size limit. I increased the upload capacity on my MAMP server to 80MB and all worked well.

As a minimum, the empty return false in DrupalMySQLiSource.php should be changed to something like:

if (!$stmt) {
  throw new BackupMigrateException('Error in SQL statement (!line).', ['!line' => $line]);
}

in order to actually show some error message rather than the generic "no success, go jump into the lake". :-)

Continuing on #13,

I found the reason for my issue. It wasn't memory, but the environment I took the backup from had a Database version 8.0.17, while the environment where the restore was failing was 5.7.23.

I updated the stack and the restore is working fine now.

In case this might help others, we ran into this issue today and the problem turned out to be with one problematic table ("__ACQUIA_MONITORING" for what it's worth). The database had imported fine into most environments, but caused an issue with a high availability mysql server. Skipping that table in the export prior to retrying the import worked.

More informative error logging along the lines of what was suggested in Comment #16 would have been a big help.

Here's a patch for the change suggested by @djg_tram in Comment #16 above.

I made a full site backup and tried test the patch #19 with a backup file size 58,6 MB, but I receive this message error:

Error in SQL statement (database.sql100600 1530037715300010 10641273 14051303525 7203 -- Backup and Migrate MySQL Dump SET AUTOCOMMIT = 0;).

Moving this to the 5.x branch as the 4.x branch is no longer supported.