In the world of community software, you find yourself stuck without the fancy software support that exists in enterprise Commercial Off The Shelf (COTS) packages.  Consider Alfresco CMS with a community versioned Mysql DB. 

With Alfresco CMS, it is recommended to turn off the system before taking a backup of Alfresco.  This hinders true 24/7 operations of web sites.  The following is a description of using a "Paused Replication" backup technique with Alfresco operating live.

The Alfresco CMS data system is a combination of a database and a flat file system.  These two systems must be in sync in order to bring up the Alfresco system.  Technically, the file system can be up to two weeks newer than the database.  Alfresco CMS is primarily a write only system with a 2 week old garbage collector.  In essence the database is the "authority" on data and the file system has additional copies of content versions.  As long as the file system version is younger than the DB backup by up to two weeks, the version supported by the DB should match up, and all should work.

Knowing that the Alfresco system can be backed up in two phases, a backup of DB followed by a backup of the file system.  A backup server design was created that provides a "warm running copy" of the Alfresco primary operations system.  The backup server maintains the most recent backup in an operational state for switch over.    The backup server can be advanced to a newer backup state through operation of the "Paused Replication" backup operation.

"Paused Replication" Backup of MySQL DB

The Alfresco CMS system is very transaction aware.  This means you want to make sure that you have solid transaction boundries when you take a backup of your database.  To recap our configuration, we have a community version of MySQL with Alfresco CMS.  We cannot simply take a traditional MySQL dump and fully address the transactionally completeness of the DB.  We solve our problem with Replication.

The first step in the "Paused Replication" backup process is to build the replication db on the backup server.  Once you have a healthy slave for the master Alfresco DB, we are ready to take the backup.  To backup the DB: 1) log in to mysql and stop the slave, 2) shutdown the DB with mysqladmin, 3) make a copy of the cold datafiles to a new location, and 4)  restart the slave DB with replication on.

If you follow the above steps, you have a cold backup of the slave db.  To convert this copy to a running "standby" master: 1) delete master.info file of backup copy, 2) alter mysql.conf with serverid=1 and correct port and bind_address, 3) place the datafiles into a new mysql var->data directory, 4) startup the backup copy db.

There is now a running copy of the Alfresco DB that is transactionally complete to the time the replication was stopped pre backup.  Transactionally completeness is guaranteed after 1) the binlog file generated on master only includes commited transactions, 2) the replication process when paused should recognize transactions, 3) when the db server is rebooted with incomplete transactions, they are rolled back. 

The final part of the Alfresco backup is the file system.  For this, you can use whatever file system copy method you like.  Once you have the file system in place, and the db is running, startup Alfresco.

Alfresco should start.  If Alfresco has problems starting, consider that the lucene indexes may need to be rebuilt. 

If you want to have an Alfresco failover system ready to go, consider using this approach, scripting it, and putting it on a cron job.