Backup and Restore (Talk)

[acommons]

The article seems too simple. What are the requirements for this to work? Are there dependencies that restrict the recovery platform? For instance, does the version have to match? What if the server name(s) is/are different?

Start alfresco before loading modules?

If your old installation had extra modules installed (say the Records Management module), it may be necessary to install the new version of the same module prior to starting Alfresco 'just to see if it worked...'

Bnordgren 19:46, 19 April 2010 (BST)

I think you are in trouble if you follow this!

I'm very new to Alfresco and due to some unpleasant experiences I'm _very_ interested in backup & restore. I'm looking at cold backup. My thoughts at the moment (for a Tomcat based installation) are:

• Make a backup of the entire Alfresco installation immediately after the install. There is no repair/reinstall option so if anything unexpected happens this may be your only way to get back the original files without a reinstall.
  

Mrogers 17:09, 9 March 2011 (UTC) You can still do a manual install of the war file or even from build everything from source and deploy.

Acommons 08:05, 11 March 2011 (UTC) I'm addressing this from the perspective of a user/sysadmin who is not a java developer.

Mrogers 14:25, 11 March 2011 (UTC) SysAdmins should understand how to configure an application server.   So they should know about WAR files, and know their way around tomcat.  And if they don't they should make it a priority to learn.   WAR files are sqarely in the 'sys admin' domain and are not 'java developer' things.     I agree that there is an issue for non sys admins to be able to back up and restore alfreso.    You also probably need occasional help from a DBA to administer your database.  

Acommons 12:01, 12 March 2011 (UTC) So Alfresco is for 'Pro Shops' and is not, and never will be, a black-box that a small business with document management and intranet/extranet aspirations can use. That's a shame really. A bit of decent documentation and a few scripts would probably narrow that gap but it looks like that will have to be a reverse-engineered community effort. But that's the business model 🙂

• There is a lot more than alf_data and mysql to worry about:
  

1. Configuration information is stored in a number of places in the Tomcat structure. Without detailed knowledge of where these might possibly be it would be prudent to grab all of the Tomcat structure in the regular backup.
   

Mrogers 17:09, 9 March 2011 (UTC) Yes it makes sense that you should backup or version control your alfresco configuration files.   In particular your alfresco-global.properties file.  Its probably easiest just backup the shared folder.

Acommons 08:05, 11 March 2011 (UTC) Will certainly look into that.

1. Ditto for the virtual_tomcat structure on the grounds that it has tomcat in its name and I have no idea what it is used for.
   

Mrogers 17:09, 9 March 2011 (UTC) The configuration is a single properties file, back that up if you want.

Acommons 08:05, 11 March 2011 (UTC) Thanks for that.

1. amps and amps_share should also be included since this is where additional modules seem to be added.
   

1. The rollbackBackupDirectory has a really interesting name... maybe it should be captured as well?
   
2. There may well be other places where configuration information may be buried...when you find them include them!
   

• MySQL should be catered for by its own backup procedures but it might be wise to grab everyting apart from 'data' just in case.
  

I'm sure there are bits I've probably missed at this early stage. I'll add them as and when I find them.

Here is a diagram showing the Tomcat based installation structure and areas of interest for backup:
Structure.pdf