comparison of database back ups results in different size using phpMyAdmin and backup_migrate

By BassPlaya on 9 Aug 2009 at 10:02 UTC

working with D6.13
I have installed backup_migrate-6.x-1.2. and I've been checking if this really does the trick, you know just in case.
Now I found that if I manually back up the db via phpMyAdmin it resulted in 1.1MB as opposed to 804KB with the module.
I know that the module omits certain tables from backing up, I did the same thing, I omitted the same tables while backing up via PMA.

So, why is there a difference? Why is that? What is not backed up? Can we rely on it?

Comments

Diff? Compression?

choster commented 10 August 2009 at 21:02

This may sound obvious, but did you check the pMA-generated file versus the module-generated file to see that they are, indeed, saving the same tables?

How far apart were the backups? Some tables, such as logs or caches, may have been trimmed by a cron job between one and the other, or grown due to traffic.

This may also sound obvious, but are both files using the same compression scheme (bz, gz, etc.)?

backup_migrate module doesn't backup certain tables

BassPlaya commented 19 August 2009 at 10:00

Hi Choster,

while I've done it again to be sure and to answer some questions of yours:
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. same compression
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?

Authentically,
BassPlaya

Default Table Selection

meason commented 19 August 2009 at 19:02

I'm not an expert on this but when last I checked, by default, the tables marked for backup in the backup & migrate module don't include the cache tables. Maybe this can account for the difference?
.
.
.
Ok I just re-read your post and it seems you know about this already. I'd delete this comment if I knew how... :-)

I use this module all the

picardo commented 19 August 2009 at 21:00

I use this module all the time. Never noticed any missing data during migration. Did you make sure the files were compressed in the same manner? bzip and gzip have varying outputs.

If the cause is the module, I'd like to know what causes the filesize difference.

Project issue queue?

dddave commented 20 August 2009 at 14:49

Shouldn't this be discussed there where the maintainer can react to it? IF there is a legit issue it would have to be discussed there anyways.

dddave, I think you're right!

BassPlaya commented 25 August 2009 at 09:26

dddave, I think you're right! BUT..
where is that link on the project page that brings us to the issue queue? http://drupal.org/project/backup_migrate
I finally found a link via drupalmodules.com, here it is for those who are confused as well:
http://drupal.org/project/issues/backup_migrate

correction: my apologies dddave, I've found the issues links in the side bars on the left while I was looking for them at the bottom next to view statistics and such.. still I think there should be an obvious link to that page..

I will post my issue there, please refer from now on to the issue queue.

@picardo: yes, I used same file extension see above, basically no compression, straight .sql But the thing is that even cache maybe left out.. it only backed up the table UNTIL system.. so from System till Watchdog... nothing!

Authentically,
BassPlaya