Woooah! Mystery related to Backup mySQL

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!

Feznizzle:

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

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!

Feznizzle:

Wow. Man, I hope that's it.

Probably. That table can get very large very quickly.

Feznizzle:

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.

Feznizzle:

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.

Feznizzle:

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.

RodG:

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?

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.
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.

Feznizzle:

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

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).

That's good to hear, Rod. I'm glad you are still toying with it, I still think it a worthy endeavor despite naysayers~! Carry on, sir! :)

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.

Hmm. I wonder how I could have triggered that? I was writing html by hand, no wysiwyg.

But funny you should point that out. When I opened the SQL, I found some 56 notes in the admin activity log that said this: "ALERT: Please review for possible XSS activity:"

All (that I looked at) had my ip in front of them.

Should I be freaked out by that?

Feznizzle:

When I opened the SQL, I found some 56 notes in the admin activity log that said this: "ALERT: Please review for possible XSS activity:"

All (that I looked at) had my ip in front of them.

Should I be freaked out by that?

I would be. If I was trying to hack into my own system and didn't know I was doing it I think that would be cause for concern. What other sites are you hacking into that you don't know about. (Don't look now, but I think you might be a sleeper agent for ........

aatghh. vv

they

got

me

RodG:

I would be. If I was trying to hack into my own system and didn't know I was doing it I think that would be cause for concern. What other sites are you hacking into that you don't know about. (Don't look now, but I think you might be a sleeper agent for ........

aatghh. vv

they

got

me

[Again you're forcing me to put on my moderator hat ...]
Enough with the NSA innuendo nonsense, both here and in your posts in other threads.
A joke is one thing. Twisting it into slighting others by alleging that they don't know what they're doing is another. ergo last week.

Feznizzle:

I found some 56 notes in the admin activity log that said this: "ALERT: Please review for possible XSS activity:"

All (that I looked at) had my ip in front of them.

Should I be freaked out by that?

Freaked out? No.
Should you look at them? Yes.
That flag is set when it discovers that someone using your Admin has submitted data in an <input> form field that contains potentially risky content like < and > symbols such as could be used to stuff <script> tags into content.
The flag is set to tell you to make sure that you knew about the content being submitted, by basically alerting you to pay attention to those log records specifically.

If you did post the content it mentions and intended it to contain whatever it contains, then of course there's nothing to worry about.

Is your "backup mystery" resolved now?

rofl (at Rod's joke)
++++
I think (hope) I figured it out. I had created a bunch of tables in openoffice, turned them into html, then grabbed all the <tr> cells and dumped them into preformatted product cross-referrence sheets. The hotlinks were all domain nuetral, went something like this:

However, due to some quirk, openoffice kept giving me hrefs like this:

I just the current admin log sql, found a single warning pointing at "file://" as being the trigger.

I will def be keeping a close eye on this, can't imagine how someone could highjack my sessions! Or why, for that matter. The thought is that either it was just that "file://" business (most likely, I hope) or there was a trojan in my template or one of my mods (yikes!).

Didn't see all your posts b4 I posted, DrByte.

I think Rod was right, the SQL going on a diet must have been the purged admin log. Though I am confused why it was so dramatic of a change in comparison to other purges. But, again, Rod had a pretty plausible explanation for that (Internal Error 500 causing restart and table repair).

As for the xss stuff, I am comfortable that I triggered it myself and it was not malicious. And I don't think I have lost anything important from the dramatic DB diet.

So yes, I think it's resolved. Thanks for the input, DrByte and Rod!