Woooah! Mystery related to Backup mySQL

[Feznizzle]

So I was updating a category description last night, received an abrupt error (Server Internal Error 500). This was very surprising, something I've never seen happen. Because the change to the category description did not take, I went back and resubmitted.

Nervous, I decided to back up using DrByte's Database Backup Manager.

This morning I noticed that my backup file weighed less than half of what the other backups weigh! Another back up made in the morning yesterday before I began all the work weighed just over 1MB (all my other backups weigh about the same). But the one I made yesterday afternoon only weighed 324kb!

Thinking maybe last night's backup just did not complete or something, I rebacked up this morning. Same result, file 324kb. Since I always let it use gzip, the thought occurred to me that maybe gzip wasn't working before but now it is and that is why the file was smaller. So I rebacked up again, this time choosing "No Compression"... same result, file 324kb.

I have poked around on the client side of the web, all the products still seem to be in place. Everything seems normal. Only, my database seems to have gone on a massive diet.

I'm totally freaking out here! Does anybody have any ideas/suggestions for me? I don't want to continue working, only to find out critical things have gone missing and I have to revert, thus loosing even more time!

[RodG]

I'm totally freaking out here! Does anybody have any ideas/suggestions for me? I don't want to continue working, only to find out critical things have gone missing and I have to revert, thus loosing even more time!

Is it possible that one of the cache tables and/or the admin activity log got reset?

Have you tried comparing the size of the individual tables in the database?

From the sounds of things you don't have anything to worry about just yet.

Cheers
Rod

[Feznizzle]

Thanks for the calming words, Rod. :)

You are right, I did purge the admin history yesterday! Wow. Man, I hope that's it.

I did a text comparison of the two files about an hour ago, looks like most of the difference was the admin log.

But the weird thing is that weight of my backups have been growing steadily as I work, NEVER losing weight. And I have purged the admin log before. I always backup just before purging and just after.

Weirdness.

Anyway, thanks!

[RodG]

Wow. Man, I hope that's it.

Probably. That table can get very large very quickly.

I did a text comparison of the two files about an hour ago, looks like most of the difference was the admin log.

I'd take this as pretty conclusive evidence that this is the reason.

But the weird thing is that weight of my backups have been growing steadily as I work, NEVER losing weight.

This is normal and expected.

And I have purged the admin log before. I always backup just before purging and just after.

The purge should always make the database smaller. If it doesn't then something has gone amiss (or there was nothing to purge).

If I were to clutch at straws for an explanation I'd suggest you possibly had some kind of error relating to this table and your 'abrupt error (Server Internal Error 500)' caused the server to restart and in doing so initiated an automatic 'repair tables' and things are now back as they should be.

Cheers
Rod.

[Feznizzle]

If I were to clutch at straws for an explanation I'd suggest you possibly had some kind of error relating to this table and your 'abrupt error (Server Internal Error 500)' caused the server to restart and in doing so initiated an automatic 'repair tables' and things are now back as they should be.

Wow. Very plausible explanation. I hadn't considered that. And if that is what happened, then this debacle is actually a good thing! :)

Thanks, Rod!

It's been a while, hope all is well. Are you guys still experimenting with SEO?

[RodG]

Are you guys still experimenting with SEO?

I don't know about the others, but I'm sill carrying out the occasional comparison tests with the "Wurldbitzer Debibulator" products. (One static, the other having the various changes).

Google search for the 'standard query':
"Wurldbitzer Debibulator" +"Lain"

Search Results
(About 317 results)
1) Wurldbitzer Debibulator V3 : VCSWEB Online Store!, You never ...
shop.vcsweb.com › Odds 'n Sods‎
2) Wurldbitzer Debibulator : VCSWEB Online Store!, You never know ...
shop.vcsweb.com › Odds 'n Sods‎
3) Wurldbitzer Debibulator V5 : VCSWEB Online Store!, You never ...
shop.vcsweb.com › Odds 'n Sods‎
4) Wurldbitzer Debibulator - The Art of E-commerce
w w w.p r o m-m a rt.c o m/demo-2/wurldbitzer-debibulator-p-183.html‎
5) Wurldbitzer Debibulator - Tomatocart 1181
w w w.p r o m - m a r t. c o m/tomatocart.../3.../22-wurldbitzer-debibulator.html?...‎

'tomatocart' takes the next 300 or so top spots, but they all give a server not found error, and many of them look 'spammy' in that the URL's are pointing to locations unrelated to the search query.

As we know, the order of the results will vary depending on location, and from my part of the world, the #1 spot is still being held by the store using ZenCart native URL's with no special SEO techniques/enhancements of any kind. The #3 spot has a 'friendly URL' (not that you can tell from the google display), and this is the one I've been trying to 'optimise' to take the#1 spot (without success). The #2 spot is the zencart native URL of the page redirected to by the 'friendly' URL of the #3 spot. IOW, if these results are to be trusted, and all else being equal (as they are between #2 & #3), the zencart native URL trumps the the re-written 'friendly' URL.

Anyway, that's where I'm at. :)

Cheers
Rod

[DrByte]

So I was updating a category description last night, received an abrupt error (Server Internal Error 500). This was very surprising, something I've never seen happen. Because the change to the category description did not take, I went back and resubmitted.

It's not uncommon for that to happen if you use certain words/phrases that your server's security administrator (usually via the mod_security module in Apache) has deemed dangerous, such as words often used by hackers attempting SQL Injections.
As with any 500 INTERNAL SERVER ERROR, the details will be in the server's logs.