working with D6.13
I have installed backup_migrate-6.x-1.2.
When creating the back up it doesn't back up all the tables..

I've tried a back up through the module and also through phpMyAdmin. Here are my findings:

1. the backups were made just one after the other. I found that the module was extremely fast in doing this while PMA was slower. The result of my last test was: Module: 7.3MB and Manually (PMA): 12.9MB
2. I don't think my cron settings affect this as this is a development site locally on my Mac with no access from outside
3. no compression for both
4. In my last comparison attempt I found that there were 101 tables in Module db restoration and 119 tables in Manual db restoration.
Last table that was backed up in the Module db was "system".
All the other tables after system table (alphabetically S-Z) are simply omitted !!

This sounds like a serious issue, what do you say?

Comments

ronan’s picture

Status: Active » Postponed (maintainer needs more info)

That is strange, I haven't had any reports of that before.

Some questions that may help me figure it out:

Is it possible that your php is timing out or running out of memory? Does the system table export completely with B&M or is it broken off somewhere in the middle? Is there any weird data in the backup file right before the file cuts off? Does the PHPMyAdmin dump show any weird data right after the point where the B&M dump cuts off? What is the next table alphabetically in your install? Is it 'term_data'? Is there anything weird in that table?

Would it be possible to install the latest 2.x dev of B&M in a test copy of your site and see if that does the same thing? The latest dev has a modified export and also does way more checking for timeouts and failures.

Thanks

bassplaya’s picture

Hi Ronan,

I haven't tried to reinstall that database coz I'm working on a project that needs to be finished very soon. The moment it is finished I'll give it a try and see.
Further info for now:

the system's last entry is modules/statistics/statistics.module and that seems to be the same in both (so both the last entry)

Is there any weird data in the backup file right before the file cuts off?

hmm.. not that I know of, what should it look like? I hope you know that I was able to import it into MySQL through PMA, right? What I did is: I created 2 empty db and imported the two backed up files in one of them, then compared.
the next table in the one that backed up everything is term_data table.
I cannot browse it but I can see the sturcture.. Field: tid, vid, name, description, weight. Keyname: Primary, taxonomy, vid_name

that's all that I can give at the moment.. so sorry.. hopefully later more and hopefully this helps already something.
;-)

ronan’s picture

If you have some time to try it out, give the 2.x dev a try. That version is a pretty substantial rewrite so it may have better luck. The latest dev of version 2 also times out a little more gracefully, so if that's an issue you may at least get a useful error message.

matteoraggi’s picture

Version: 6.x-1.2 » 6.x-2.2

I have got the same problem with 1.x and now with 2.2 version, I discovered it only now that all my cackups .gz of about 4.5mb was just of 48-60 tables with a total of 317 tables with a backup coming from phpmyadmin of at least 17mb, not compressed db is about 200mb.

proindustries’s picture

subscribing...the module has worked great for me, but just keeping an eye on this.

ronan’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

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