1.2 beta No opengoo_backup.zip File

[werner.wuerfel]

The backup prozess completed successfully, but ist no ZIP-File.

I'm testing with a local XAMPP installtion, so I can see that the db-export (File db.sql) were created, but no ZIP-File.

[Karl]

After starting the backup process I get an error message: "Error while creating database backup. Check MYSQLDUMP_COMMAND constant."

Remember that it worked with version 1.1.

Karl

[werner.wuerfel]

Hi Karl,

I checked the MYSQLDUMP_COMMAND  - this Part will work. I can see the file with the SQL-export for a short time.

I think there is a problem to generate the ZIP-archive. This seems to bee a new part in BackupController.class.php in application\controllers

Can you generate a successful backup with a complete ZIP-archive?

[Karl]

No, I can't generate anything. The error message appears directly after starting the backup process and terminates it.

[mailnet_uk]

I added the MYSQLDUMP_COMMAND constant to my config file, and tried to run a backup.  It says it completes the backup successfully - but no files are generated.

Interestingly the command I specified in the constant actually fails if I run it manually, (due to the way my MySQL is set up) but OpenGoo didn't throw an error 

[werner.wuerfel]

Hi,

I added the following code after line 147 in application\controllers\BackupController.class.php

Code: [Select]

$db_backupww = BACKUP_FOLDER .'/'. 'dbww.sql';
exec("$mysqldump_cmd --host=$db_host --user=$db_user --password=$db_pass $db_name > $db_backupww",$ret);This generated a second SQL-export file with the name dbww.sql

A the end of the backup I can see the file dbww.sql - so I thing the SQL-export with the MYSQLDUMP_COMMAND will work.

There is a problem to generate the ZIP-archive and to include all the opengoo files inlucde the SQL-export.

[ignacio]

Hi,

We have changed the zip generation to use PHP's zip extension, maybe you don't have that extension installed.

[Karl]

But what could be the reason for this error: "Error while creating database backup. Check MYSQLDUMP_COMMAND constant."?

[ignacio]

Apparently you get the same error message for all errors, and it may have nothing to do with the MYSQL_COMMAND constant. to fix it temporarily and to be able to see what the error is, edit file 'application/controllers/BackupController.class.php' and change the line 161 from:

Code: [Select]

flash_error(lang('error db backup') . $ex);to:

Code: [Select]

flash_error($ex);

[Karl]

I changed and uploaded the file but getting the same error.

[werner.wuerfel]

Hi ignacio,

I am using 2 computers with local XAMPP 1.7 installtion. On both you can see under registered PHP Streams with phpinfo the following:

   php, file, data, http, ftp, compress.zlib, zip

On one computer the backup work's fine on the other is no ZIP-archive. I see no error in opengoo during the backup.

[mailnet_uk]

I tried making the change suggested by ignacio, but on my system it still says "backup created successfully" even though, technically, it shouldn't because the command specified by MYSQLDUMP_COMMAND fails when run manually.

I also don't see a backup file anywhere.

I do have zlib enabled in PHP - from phpinfo():

zlib
ZLib Support    enabled
Stream Wrapper support    compress.zlib://
Stream Filter support    zlib.inflate, zlib.deflate
Compiled Version    1.2.3
Linked Version    1.2.3

[ignacio]

We are talking about two different errors here:
    1) You get a 'check MYSQLDUMP_COMMAND contant' error
    2) You run the backup process but get no zip file.

For the first one, one thing that changed from last version is that now the database host is included as an argument to the mysqldump command. So if the backup worked before and it doesn't now, it may have something to do with that. You can try editing line 147 of 'application/controllers/BackupController.class.php' and remove '--host=$db_host':

Code: [Select]

exec("$mysqldump_cmd --user=$db_user --password=$db_pass $db_name > $db_backup",$ret);
For the second one, you need the zip extension, not the zlib extension. We changed to this extension because the class we were using previously didn't handle correctly big files, and could cause 'memory exhausted' errors, but now I'm thinking we should still default to that class if the zip extension is not available.

[Karl]

We are talking about two different errors here:
    1) You get a 'check MYSQLDUMP_COMMAND contant' error
 
For the first one, one thing that changed from last version is that now the database host is included as an argument to the mysqldump command. So if the backup worked before and it doesn't now, it may have something to do with that. You can try editing line 147 of 'application/controllers/BackupController.class.php' and remove '--host=$db_host':

Code: [Select]

exec("$mysqldump_cmd --user=$db_user --password=$db_pass $db_name > $db_backup",$ret);

Sorry, didn't help.

[mailnet_uk]

    2) You run the backup process but get no zip file.

For the second one, you need the zip extension, not the zlib extension. We changed to this extension because the class we were using previously didn't handle correctly big files, and could cause 'memory exhausted' errors, but now I'm thinking we should still default to that class if the zip extension is not available.

Sorry, I got zlib and zip confused, but I do indeed have zip enabled too:

zip
Zip    enabled
Extension Version    $Id: php_zip.c,v 1.1.2.46 2008/11/12 17:50:37 felipe Exp $
Zip version    1.8.11
Libzip version    0.9.0

I would also add that there's a third error - backup command failing but reported as a success, in my case.  (I'm still trying to get it sorted so the command actually works):

Code: [Select]

root ~ (networkmail): su websrv
$ /opt/nmail/mysql/bin/mysqldump --user=my_user --password=my_password my_db > /tmp/dump.sql
ld.so.1: mysqldump: fatal: libssl.so.0.9.8: open failed: No such file or directory
Killed
$ echo $?
137
$
As you can see the command doesn't exit with 0, but 137.