I'm having a problem with the DB Backups utility in the Admin section.

I just finished my upgrade from GL 1.6.1 to GL 1.7.1sr1 today.

When I first went into the DB Backups section it looked "normal" and there were no backup files listed.

So, I created a new backup...

And now, when I go back into that section of the website I get this...

2 - filesize() [function.filesize]: stat failed for /home/panamax/backups/geeklog_db_backup_2011_01_25_13_51_33.sql @ /home/panamax/public_html/admin/database.php line 125

My database is relatively large - more than a couple of gigabytes. I think there might be a problem somewhere in the way the data is being called or displayed?

And suggestions would be greatly appreciated. Thanks.

Don Winner
www.panama-guide.com
Faithful Geeklog User Since 2004

If you're getting in the critical range (2 GB or even 4), there's the risk that something somewhere is running into a 32-bit barrier ...

How big is the backup exactly and which operating system is your site running on?

In any case, this is worthy of a bug report - please submit one. Even if things fail, we should catch this gracefully.

bye, Dirk

Yes, I think that's the problem, a backup larger than 2 GB.

How big is it exactly? I don't know, because it's not properly displaying.

Where should the file be in the directory tree?

Don

Never mind, I found it (hiding in the "Backups" directory - go figure...)

The file size is 4,280,157,958

Don

Maybe you want to try http://www.mysqldumper.net/ for large backups?

Well, I could, I guess. But I think I would rather see Geeklog capable of handling anything I can throw at it, after six years of growing pains, no?

Don

I use mysqldumper to save automatically and FTP the file to another server for security. It is worth a look.

Sounds like the backup is created just fine. The problem only occurs when the list of backups is about to be displayed.

bye, Dirk

That's exactly right. The backup file seems to be there just fine, and the problem occurs when the system is trying to regenerate the screen for the DB Backups section of Admin. When I go there now, after that DB Backup file was created, I get the error message. Before the backup file was created the screen formatted correctly. If you want I could try to go in and manually delete the backup file that was created, and I bet the DB Backups Admin screen will format and display correctly.

Don

I downloaded, installed, and configured mysql dumper to try it out. Everything seemed to be working property with no problems. When I tried to create a backup of the database, it crashed. Well, it took about ten minutes to think about it, then it crashed.

Don

Don't bother. I think it's pretty clear what's happening. Now we would only need a bug report to remind us to look into it (nudge nudge, wink wink, ...)

bye, Dirk

OK, but since I have not filed a "bug report" before, how do I do that - if it's not here and through you?

Don

That is a huge database file. Do you happen to be running the GUS plugin? If so I would empty the log tables as they can make a database grow very large, very quickly.

Tom

OK, done. I filed my first bug report - IN number 0001257.

Don

I was running GUS, but it has caused way too many problems on my system that what it's worth, so I've disabled it. As part of this upgrade I'm going to root around in the directories and burn out all evidence of GUS because it has caused me a whole lot of problems and headaches.

Don

Guess what? That was exactly the problem. I went into phpMyAdmin from there I first emptied and then deleted (dropped) all of the tables related to GUS in the database. Even though I had disabled the plugin a long time ago, all of the weight and data was still sitting there.

I then went into the Plugins section of Admin and confirmed that GUS was still installed, but not enabled. I used the Plugins Admin section to delete the plugin.

Even though I had done that, all of the GUS files were still in the /plugins directory, so I deleted them manually, as well as any other evidence of GUS that I could find, anywhere.

Then, I went in and deleted the existing 4 GB + backup that I had tried to make before (large because of the old GUS data), which caused the system to crash.

With that done, I went back into the DB Backup section of Admin (which came up fine because I had deleted the 4 GB + backup file that contained all of the old GUS data) and then I created a new backup.

It worked perfectly, no problems. Total size = 91,534,249 Bytes.

So, problem resolved. The answer was to shoot GUS in the head.

However, that "bug" created by the really large DB file is still there, for what it's worth.

Thanks again for the help.

Don