Today I faced problems generating on the fly files on my test server at work. It cost me quite a bit of grief because I trusted my systems to actually work as expected. Thankfully, I got the important database dumps from my production server. However, I lost quite a number of hours redesigning the XOOPS templates that I had done previously.
I discovered the problem when I wanted to test out a data migration script I’ve written in PHP. Nothing rocket science, just pretty much your average SELECT and INSERT routine. Needless to say, something cocked up (like they usually would, especially on a first test). However, I’m not bothered in the least by this because I did use phpMyAdmin to get a database dump before actually running the script.
No biggie… i just dropped all tables in the database and attempte to restore it from the backup. Imagine my suprise when suprise when phpMyAdmin threw a “0 instructions executed” notice when I did just that!
Being the seasoned veteran that I am, I thought there must be something flakey with gzip handling for uploads… small issue, I’ll just ungzip the backup file and use the plain text sql file instead. That is when the big WTF?! hit me. The file size is 0 bytes! Now I’m definitely screwed… I didn’t check the content of the dump file AND I’ve just dropped all tables in the database!
I spent the first half of today trying to find out what the hell went wrong. Checked my
httpd.conf and my
php.ini for anything that might contribute to this. I was chafed to say the least. After disabling and re-enabling a few PHP modules, reinstalling PHP and Apache and combing through the Apache error logs… the problem still persisted.
Eventually, I thought of increasing PHP’s
memory_limit setting from the default 8MB to 32MB just for fsck’s sake. Restarted the Apache service and walla! Everything worked perfectly.
Moral of the story: it’s not enough making backups, make bloody sure you’ve backed up the correct things. Hopefully this will help somebody facing the same problem.