WCM Administration [ 392 ] The process you follow to maintain and back up your customization les depends upon the development process you follow within your organization. It is useful to maintain your customization les in some conguration management system such as CVS or SVN, which helps you to easily maintain and back up. Membership data If you have used the Alfresco out-of-the-box membership system, then the data is stored in the relational database. You don't have to do any special task to back up the data as you are already backing up the relational database tables. If you have used an external membership system such as Active Directory or OpenLDAP to have a single sign-on or centralized identity management system, then you must consider backup of your membership data as well. You will have access to back-up tools based on the membership system you have used. Ensure that the data in the external membership system is backed up. Log les The location of the log les depend upon the application server. For the Tomcat installation, the log les are located at <install_folder> itself. Tomcat application server creates a log le per day. The current log le is named alfresco.log and at the end of the day, the log le will be backed up as alfresco.log.YYYY-MM-DD (for example, alfresco.log.2010-03-25). Based on the usage of the system and on the logging level, the size of these log les might be pretty big. Hence, it is a good practice to back up the older log les and remove them from the current location to save hard disk space. Backup frequency The frequency at which you take backup really depends upon the nature of the application, your high availability requirements, and the Alfresco deployment option you have chosen. Download from Wow! eBook <www.wowebook.com> Chapter 12 [ 393 ] For example, you can consider only a one-time backup of customization les. You can back up the les whenever you enhance the application or upgrade the application to newer versions. Since the content, metadata, and tasks change very frequently, regular backup of the Alfresco lesystem and relational database is required. You have to consider the business risk and system resources availability while deciding on the back-up frequency. Backup is based on Alfresco deployment If your application is highly accessed by thousands of users, then it is important for you to deploy Alfresco in a clustered environment. If it is a critical application such as nance or insurance, then you should consider deploying Alfresco in hot back-up mode with master-slave conguration. The data backup policy and process might be different based on the way you have deployed Alfresco. The typical process to back up Alfresco repository is as follows: 1. Stop Alfresco to ensure that no one can make changes during the backup. 2. Export the MySQL (or other) database. 3. Back up the Alfresco alf_data directory. 4. Start Alfresco. To restore Alfresco repository: 1. Stop Alfresco. 2. Delete the alf_data folder and restore the alf_data folder that you backed up earlier. 3. Drop the database and import the database that you have exported. 4. Start Alfresco. Download from Wow! eBook <www.wowebook.com> WCM Administration [ 394 ] Alfresco deployed as a Repository Application Server In this deployment (shown in the following gure), the web application becomes the host for an embedded repository and remote access is via the application, that is, HTTP. This is the default deployment option chosen by the Alfresco installer. This means the repository automatically benets from any enhanced features provided by higher-end web application servers. For example, the repository can be embedded inside Apache Tomcat for the lightest weight deployment, but also embedded inside J2EE-compliant application servers from JBoss, Oracle, or IBM to take advantage of distributed transactions, and much more: In this deployment option, you need to take the backup of the alf_data folder and the database. There will be one copy of customization les. Alfresco deployed as a hot backup In this deployment, as shown in the following gure, one Repository server is designated the master and another completely separate Repository server is designated the slave. The live application is hosted on the master, and as it is used, synchronous and asynchronous replication updates are made to the slave, that is, the backup. The backup remains in read-only mode. If for some reason, the master breaks down, it is a relatively simple task to swap over to the slave to continue operation. Download from Wow! eBook <www.wowebook.com> Chapter 12 [ 395 ] In this deployment option, you don't need to take a regular backup as the data is getting backed up automatically. Upgrading to new versions of Alfresco You can consider upgrading to a new version of Alfresco if you are expecting one of the following benets: • Security patches • Bug xes • New features • Compatibility with other systems Even if you are not getting the benets listed earlier, sometimes you might consider upgrading to a newer version, as you do not want to maintain a big gap between the Alfresco version on which your application is currently running and the latest Alfresco version. If this gap is too big, it might be very expensive for you to upgrade later on. This is the scenario with most enterprise software. Download from Wow! eBook <www.wowebook.com> WCM Administration [ 396 ] Alfresco has upgrade scripts, which helps you to upgrade to newer versions automatically. However, it is essential to follow certain best practices while upgrading your system. Always try upgrading the test or staging server rst before trying on production server. It is essential that you back up your existing data before attempting an upgrade. Follow the information and instructions given in the Data backup section. Upgrading to a minor release An Alfresco minor (or dot) release typically contains bug xes and minor enhancements. There will not be any new features. An example is upgrading from Alfresco 3.2 to 3.2.1 release. Since there are no new features, typically, the database schema remains the same. In this situation, you can replace only the web application (WAR) le to upgrade. The WAR le ( alfresco.war) for Tomcat installation is located in the <install_ folder>/tomcat/webapps folder. Follow these steps for minor upgrades: 1. Download the latest alfresco.war le from the Alfresco website. 2. Stop Alfresco. 3. Back up all of the data including customization les (as explained in the earlier sections). 4. Delete the web application folder <install_folder>/tomcat/ webapps/alfresco . 5. Replace the alfresco.war le in the <install_folder>/tomcat/webapps folder with the latest one. 6. Restore the customization les. 7. Start Alfresco. Test your application after upgrading it to ensure that the upgrade is successful. Upgrading to a major release An Alfresco major release typically contains new features, performance enhancements, and bug xes. An example is upgrading from Alfresco 2.x to 3.x releases. The upgrade scripts will be executed automatically by the server when starting up against an existing database. Scripts that support the various Hibernate dialects can be found in the <configRoot>/alfresco/dbscripts/upgrade/* folders. This means that you don't have to do manual upgrades any more. Download from Wow! eBook <www.wowebook.com> Chapter 12 [ 397 ] For example, let us assume that you are using the Tomcat bundle of Alfresco 2.1 (installed in C:\alfresco2.1 folder) on a Microsoft Windows operating system, and you want to upgrade to Alfresco 3.3 release. Follow these steps for major upgrades: 1. Stop Alfresco in your current installation folder C:\alfresco2.1. 2. Back up all of the data, including customization les (as explained in the earlier sections). 3. Download the complete Alfresco package, Tomcat bundle for the Microsoft Windows operating system. 4. Perform a new installation in a different folder (say C:\alfresco3.3). 5. Copy the older Alfresco le content folder to the newer installation (copy the C:\alfresco2.1\alf_data folder to C:\alfresco3.3\alf_data). 6. Create a new database table and restore the relational database content from the older database. Update the Alfresco conguration le in the new installation to point to this new database. 7. Restore the customization les in the new installation. 8. Start Alfresco in the new installation. Though most of the upgrade happens automatically, you might have to perform some manual steps to restore your customization les in a new installation. There are some conguration les and a properties le in Alfresco's cong folder (/ tomcat/webapps/alfresco/WEB-INF/classes/alfresco/), which you might have updated, which require manual updates. While I was writing this book, I upgraded the example application from Alfresco 2.1 version to Alfresco 3.3 version. I used the following script to restore some of the customization les. I manually updated some of the conguration les. Refer to the batch le that I used to restore the customization les on the Windows platform. rem rem Replaces/Adds Alfresco Custom Files to new Alfresco installation rem set L_LOCALDIR=%CD% set L_SRCDIR=C:\alfresco_book_21 set L_DESTDIR=C:\alfresco_book_30 rem Replace Logos CD %L_DESTDIR%\tomcat\webapps\alfresco\images\logo move AlfrescoLogo32.png AlfrescoLogo32.png-ORIGINAL move AlfrescoLogo200.png AlfrescoLogo200.png-ORIGINAL move AlfrescoFadedBG.png AlfrescoFadedBG.png-ORIGINAL Download from Wow! eBook <www.wowebook.com> WCM Administration [ 398 ] copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoLogo32.png . copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoLogo200. png . copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoFadedBG. png . rem Copy files in extension folder CD %L_DESTDIR%\tomcat\shared\classes\alfresco\extension copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\custom-model- context.xml . copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\customModel. xml . copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\web-client- config-custom.xml . CD %L_LOCALDIR% echo I am done pause You can create your own batch scripts to automatically restore your customization les. Typically, most of the developers use tools such as Eclipse to build and deploy the customization les to the newer installations. Test your application after upgrading it to ensure that the upgrade is successful. Cleaning up deployment history There are two ways to clean out old deployment reports in WCM: • Using Alfresco Explorer • Using scheduler Using Alfresco Explorer Administrator and Content Managers of the web project have the right to delete the Deployment Reports. Follow these steps: 1. Go to the Staging Sandbox area of the web project. 2. Click on the Actions menu. Download from Wow! eBook <www.wowebook.com> Chapter 12 [ 399 ] 3. Click on the Delete All Deploy Reports submenu. 4. It will ask for conrmation; click on Yes to delete the reports. Using scheduler Using scheduler you can delete the reports older than the given number of days. You can congure this scheduler to run on a periodic basis. Follow the next steps to congure this scheduler. 1. Rename the le deployment-attempt-cleaner-context.xml.sample to deployment-attempt-cleaner-context.xml specied at the location <alfresco_home>/tomcat/shared/classes/alfresco/extension. 2. Congure the following highlighted changes: <bean id="avmDeploymentAttemptCleaner" class="org.alfresco.repo.avm.AVMDeploymentAttemptCleaner"> <! number of days to keep deployment attempts > <property name="maxAge"> <value>1</value> </property> <property name="nodeService"> <ref bean="NodeService" /> </property> <property name="transactionService"> <ref bean="TransactionService" /> </property> <property name="searchService"> <ref bean="SearchService" /> </property> <property name="importerBootstrap"> <ref bean="spacesBootstrap" /> Download from Wow! eBook <www.wowebook.com> WCM Administration [ 400 ] </property> </bean> <bean id="avmDeploymentAttemptCleanup" class="org.alfresco.util.CronTriggerBean"> <property name="jobDetail"> <bean id="avmDeploymentAttemptCleanerDetail" class="org.springframework.scheduling.quartz.JobDetailBean"> <property name="jobClass"> <value> org.alfresco.repo.avm.AVMDeploymentAttemptCleanerJob </value> </property> <property name="jobDataAsMap"> <map> <entry key="deploymentAttemptCleaner"> <ref bean="avmDeploymentAttemptCleaner" /> </entry> </map> </property> </bean> </property> <property name="scheduler"> <ref bean="schedulerFactory" /> </property> <! trigger at 5:00am each day > <property name="cronExpression"> <value>0 0 5 * * ? </value> </property> </bean> This will purge all deployment attempt nodes older than one day at 5 a.m. every morning. Deployment report 1 day before Go to the Staging Sandbox of the web project. Click on the View Deployments link. You will nd the history of all of the deployment reports on that page as shown next: Download from Wow! eBook <www.wowebook.com> Chapter 12 [ 401 ] Deployment report 1 day after Since we have congured to clean up reports that are one day older, on the next day, we can see only those reports which are deployed today. All other reports, which are shown in the previous screenshot, have been purged. General maintenance tips If you maintain the system regularly by cleaning up the database and xing the system errors, your system runs faster. Some of the tips are given in this section. Examine log les Your log les tell you very important issues and problems about your system. The level of details logged will be based on the level of logging (INFO, ERROR, and DEBUG). The log les are named as alfresco.log (current one) or alfresco.log.YYYY-MM- DD (older ones). Examine one of the log les and you will notice the log entries made in the following categories. • ERROR: Error occurred (requires FIX) • WARN: Warning messages (requires your attention) • INFO: General information about the system Download from Wow! eBook <www.wowebook.com> . %L_SRCDIR% omcatsharedclassesalfrescoextensioncustom-model- context.xml . copy %L_SRCDIR% omcatsharedclassesalfrescoextensioncustomModel. xml . copy %L_SRCDIR% omcatsharedclassesalfrescoextension web- client- config-custom.xml. steps to congure this scheduler. 1. Rename the le deployment-attempt-cleaner-context.xml.sample to deployment-attempt-cleaner-context.xml specied at the location <alfresco_home>/tomcat/shared/classes/alfresco/extension. 2 at the end of the day, the log le will be backed up as alfresco.log.YYYY-MM-DD (for example, alfresco.log.201 0-0 3-2 5). Based on the usage of the system and on the logging level, the size of