Failed Backup (or backup doesn't save)

This is just the header and footer of the sql file. All these lines are doing is setting the SQL connection to UTF8 so that if you use another tool to import you will not have character encoding issues. On their own, these lines do nothing.

Looks like the module is not finding any tables to back up. Are you using table prefixes? Have you tried the 6.x-2.x branch? Not sure that will help but that code is almost entirely rewritten so this bug may have been inadvertently fixed in there.

I'm setting priority to normal since the bug doesn't seem to be causing any critical problems with the rest of your site and I have not had any other reports of this.

I've been getting this behaviour too with the 6.x-2.x-dev version, after upgrading from the 6.x-1.0 version.

With compression turned off the manually created database backup was just the utf set command as above. With compression turned on the database is saved as expected.

I've also just found that if I rename the profile from 'Default profile' it seems to work without compression as well.

Still have not been able to reproduce this, but I wonder if it's still happening in the most recent dev? If lots of people are experiencing this it'd be a show-stopper for a 2.0 release so I'd like to figure out what's happening here if I can.

Thanks for your help debugging this.

Ronan

In my case, backups are just 1.xxMB when my DB is about 30MB.
Is this correct? Does this module make (somehow) differential backups?
My guess is it's not working properly for me either. :(

Cache and watchdog tables are excluded from the backups by default, so that could easily account for the missing 29Mb.

Also, if you're choosing to compress the backup files that will take a lot of size out of them. The best way to check is to restore to a development copy of your site. That's something everybody who is using this module for backups should do anyway (always test your backup plan no matter what tools you use).

Ronan

it the same prb no save database and message when module is activate:
(Gnu/debian Lenny, apache, suphp and pgsql)

* warning: pg_query() [function.pg-query]: Query failed: ERREUR: erreur de syntaxe sur ou près de « table » LINE 1: show table status ^ in /..../includes/database.pgsql.inc on line 139.
* user warning: query: show table status in /...../modules/backup_migrate/backup_migrate.module on line 682.
* warning: Invalid argument supplied for foreach() in /..../includes/form.inc on line 1423.
* warning: Invalid argument supplied for foreach() in /..../includes/form.inc on line 1423.

This must be the same problem as http://drupal.org/node/541530 but with the 5.x-1.2 version.
Anyone knows a proper solution for this?

@AldoReset, @LeVA

This module does not support pgsql (#341277: New backup source: PostgreSQL (D7)). I should have an error checking for that in the module but without running pg on my dev I'd be unable to test and maintain that code.

If you want to help get it working on postgres, there's work going on in the thread above.

Also for me backup is failed, for both manual and scheduled backup, I get an internal server erro page and remain just big file into tmp folder, but nothing into folders of backup and migrate (in past it was all ok instead an I have some old backups, maybe when I was on servrent.com vps, insead now i'm into dreamhostps.com with about 200mb of garanted ram).
Instead using 800mb of ram it worlk greatly and backup is done in few seconds, gzipping a .sql file of about 1.3gb.

I was having an issue where is I try to backup more than once per hour (mainly for development purposes). The file will not be written because it already exists.

To overcome this, I added a little code to: backup_migrate/includes/destinations.file.inc (at line 31). This small addition will check for an existing backup file with the same name, and if it exists, append a number before .mysql.

For example:

MySite-2010-05-28T15-.mysql (default name)

Adding multiple backups:

MySite-2010-05-28T15-1.mysql
MySite-2010-05-28T15-2.mysql

etc...

Maybe not the best solution, but it works. Just did it a few minutes ago, so testing is limited.

(original code)

$filepath = rtrim($dir, "/") ."/". $file->filename();

(added code)

$f = 0;
if (is_file($filepath)) {
	while (is_file($filepath)) {
		$f++;
		if ($f > 1)
			$oNum = ($f-1);
		else
			$oNum = "";
		$filepath = str_replace($oNum.".mysql","$f.mysql",$filepath);
	}
}

(original code)

rename($file->filepath(), $filepath);

Have you edited the filestamp format in your settings profile? Because by default the file should be saving with minutes and seconds as well as hours in the name so there's shouldn't be an issue of duplicates. By default the stamp format should be:

Y-m-d\TH-i-s

Adding at least minutes back is a lot easier than appending a counter.

Closing this to clean up old tickets. Please reopen if it's still applicable.