(Lightweight) backup strategies for a LAMP application stack?

Question

I'm researching some lightweight tools to backup a LAMP stack. The two most imporatant pieces are the

• php codebase and
• the mysql database.

I can tar/bz2 the code and a mysqldump and restore it on a new server (if the old one crashes) and this is more or less fine.

Anyway, are there more complete solutions to this?

• e.g. track and re-install additionally installed pear-packages;
• track other packages related to the LAMP stack installed via linux package managers, e.g. APC;
• keep mysql and php configurations alongside backups and being able to restore them automatically ...
• possibly complete server images, which can be restored without the need to reinstall everything ..

I'm curious about hints, tips, experiences, solutions ..

Answer 1

Here is a great guide for imaging an Ubuntu machine (obviously you can use on other distros): http://ubuntuforums.org/showthread.php?t=35087

In a nutshell (from the article)

tar cvpzf backup.tgz --exclude=/proc --exclude=/lost+found --exclude=/backup.tgz --exclude=/mnt --exclude=/sys /

To back up the system, then ftp it to another server.

Answer 2

I can answer a few points. I know it is not a popular package, but I've always revisioned schema with RCS at the server. It doesn't have to be RCS, but no reason not to dump the CVS/RCS repository with the backup.

For "complete server images," instead of autonomously installing application-requirements (PHP packages &c) we deploy our own bin/ src/ usr/ var/ lib/ structure as per each application which simplifies the backup and system req's perspective.

Hope that helps.

---

I've also seen mysqldumps RCS'd to save only changes. I'm sure that would be somewhat non-trivial in terms of change management though.

Answer 3

The PHP code base should be managed in a version control system such as SVN, Git, etc. Just creating a tar doesn't give you many capabilities that a proper version control system gives you.

The trouble with mysqldump is that you have to lock the tables you are dumping to ensure a consistent snapshot. If this takes a long time, other DB operations might timeout while waiting. We use a wonderful script for snapshotting the running database without excessive locks. It was designed for the Amazon/EC2 environment but the principals apply to any Linux system with the xfs file system.