Failed Backup (or backup doesn't save)
gbrussel - November 24, 2008 - 20:33
| Project: | Backup and Migrate |
| Version: | 6.x-1.2 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I'm trying to use this module to do a scheduled weekly backup of the Drupal 6.6 site I'm running. The only table I've excluded is "watchdog" (i.e. this is the only table selected).
The backup that gets saved is 387 bytes in size. The only file is the .sql file and the contents are as follows:
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=NO_AUTO_VALUE_ON_ZERO */;
SET NAMES utf8;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;I have the Site Documentation module enabled and it is telling me the database size is approximately 26.0MB. I've also tried the 6.x-1.x-dev version, with similar results.
I don't know much about SQL, but when I created a new database and ran that query in it, it said query ran fine, but I wasn't expecting anything to show up in the database (and nothing did).
#1
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.
#2
I will give the 6.x-2.x-dev version a whirl when I get a chance. I'm not sure why it was set to critical, that was an inadvertent mistake.
#3
I have a quite similar issue.
I made one manual backup and a few seconds after I ran cron in order to execute a scheduled backup.
Here are the respective sizes :
The same backup profile was use.
And here follow the smaller and bad file contents :
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=NO_AUTO_VALUE_ON_ZERO */;
SET NAMES utf8;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
Gotcha give a try to 6.x-2.x-dev version.
Thanks for this work !
#4
Oups !
I already use the 6.x-2.x-dev (2008-sept.-29) version meaning the potential bug still in it.
Days ago I had such a problem but I did not spend time on it. I believe I resolved it by changing the compression format. But not sure of it !
For the today bug this is .gz compressed file. Maybe this will help a few.
#5
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.
#6
I've tried and failed with the 6.x-2.x-dev version as well - the file is still just a few hundred bytes.
#7
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
#8
I've stopped using this module, unfortunately. I've been doing my backups straight through phpMyAdmin.
#9
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. :(
#10
Cache and watchdog tables are excluded from the backups by default, so that could easily account for the missing 29Mb.
#11
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
#12
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.
#13
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?
#14
@AldoReset, @LeVA
This module does not support pgsql (#341277: Does not work on pgsql ). 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.
#15
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.