Why You Should Always Backup

Published on Feb 22, 2009 by Jamie Munro

Man, what a week it has been.  As you may have noticed it's been a few days too many since my last post.  The reason for that is a hectic week at work has prevented me from having time.

Now that the week is over and it was hectic because of my own stupidity, I mine as well write an article about it to save you some time.



On Tuesday, my client gave me the go ahead to launch 3 months of development work live.  We had been testing it for several weeks off and on making some tweaks and everything had been running quite smoothly.

So, I gathered up the SQL commands to create the new tables, alter the existing ones, populate a few new ones, etc...  Zipped up the new code, uploaded it to the server, extracted it and we were good to go.  3 months of development work was now live.

I had a co-worker help me test out the new work.  Everything went smoothly.  It had to be the smoothest launch ever, until of course I said that it was the smoothest launch ever...

The next day, a few leaks in the hose seemed to be appearing, we weren't really sure what was happening, but something certainly was.  The night I came down with the flu and all hell broke loose on Thursday while I was at home extremely sick.

Along came Friday and still not feeling well, I went in and made a few fixes, got things somewhat better.

The moral of this story is, we could have avoided some major headaches if prior to releasing three months of code if we would have run to simple commands.

First one would be to backup our Mysql database:

mysqldump -u [username] -p [password] [databasename] > [backupfile.sql]


And the second line would be to backup our code:

tar -cvf - <directory name> | gzip -c > <directory name>.tar.gz


The next time, no matter how small or big the work is, you can guarantee those are the first two things I will do!

Tags: gzip | mysqldump | tar | Theory

Related Posts

blog comments powered by Disqus