Alfresco Backup & Restore

Alfresco has been working great for over a month now.  One thing that had been nagging me was a successful backup and restore.  I figured out the problem.  I wanted to test on a practice machine, so not to brick the production site.  That was the thorn in my side.  I could create a new Alfresco setup from scratch that worked fine.  I wanted to test with the real data though.  I figured if I could accomplish this – then disaster recovery would be solved too (bring data and site up on a completely new machine in short order).

The premise seemed simple enough, but execution was unsuccessful.  I tried all kinds of methods.  I stopped Alfresco and copied the complete alf_data folder over to new machine.  I thought that should work.  It didn’t.  Then I went through various cold and hot backup procedures, like:

  • backup mysql database (while Alfresco running) to an sql file
  • stop Alfresco
  • copy the data and lucene indexes (alf_data basically)
  • restart Alfresco on production machine and stop Alfresco on test machine
  • place the alf_data folder in proper place on test machine
  • restore the mysql database by using the sql file
  • restart Alfresco on test machine

The different combinations yielded different results, but mainly the indexes would be corrupted even though the database was backup up properly.  I read somewhere that using mysqldump alone is not good enough because it does not actually backup up all the data properly.  I used Webmin and got the 3 databases backed up automatically (alfresco, mysql, test).  So that was not the problem.  Stopping Alfresco and tarring the whole alfresco folder should have done it, but that didn’t even work.

The problem?  The test machine was a 32-bit version and the production machine was 64-bit.  At first, I thought it was because I was using Ubuntu 10.10 on test machine (production was Ubuntu 10.04).  There were just too many 64-bit libraries and binaries in the 64-bit version to manually, methodically switch out on the test machine.  Since I didn’t have a spare 64-bit box lying around, I built a new one.  I did have a 64-bit AMD processor lying around and found a spare motherboard and 2G RAM – so I put it together to complete the new test machine.  Installed the same Ubuntu 10.04 on it and got everything updated and running.  Well, after this it seemed like a piece of cake.  Creating a complete clone was as simple as untarring the the opt/alfresco folder and contents to the new machine, starting Alfresco and I was golden.  Things have to be the same for it to be a total clone, like having the same SMTP server running on it.  I didn’t have Postfix running initially, so the email portions failed.  But it was sigh of relief to see the site come up without a hiccup.  OK, this works flawlessly if everything is in the same ‘/opt/alfresco’ folder (like the default).  But data really should be on a different partition or spindle (different hard drive).

So my next task was moving the data to a different area.  This is where you supposedly should have the databases backup properly and the actual data saved (in the right order).  But moving the data was actually simpler than that.  Assuming you have a stable data store, all you have to do is:

  • stop Alfresco
  • copy alf_data folder with GUI or tar it (-cfv)
  • paste the folder to new location, or untar (-xfv)
  • delete contents of /opt/alfresco/tomcat/temp
  • rename original alf_data folder to something else
  • if you don’t have a huge site, delete backup lucene indexes in new alf_data location
  • delete lucene index folder in new alf_data location
  • make sure you have the ‘index.recovery.mode=AUTO’ line  in global properties
  • change location of data ‘dir.root=/new location’ in global properties
  • restart Alfresco

This worked without a hitch.  I restarted a second time after deleting the alfresco and tomcat logs to get a clean picture of current system and site.  The site worked as it should with data in new location.  Note that I did not have monkey around with mysql database to get this to work.  This is because the mysql database was shut down properly and databases and actual data files were not corrupt.  This method wil NOT work if there is a problem (main reason why you backup and restore).  This is where the backup/restore procedures come into play.  Having data in different drive or partition adds an extra step because you must rely on the mysql database to bring back the indexing properly.  See this: