Maintaining and upgrading the system is as equally important as implementing it. A well-maintained system will give the highest return on investments. This chapter provides a high-level overview of administering and maintaining your Alfresco implementation. It includes information about backing up your valuable content, upgrading your system to newer versions, enabling full audit trail, and setting up a multi-tenant system configuration. You will also find general maintenance tips such as maintaining log files and periodically updating your admin password.
By the end of this chapter you will have learned how to:
- Back up your data on a regular basis for storage and retrieval
- Perform general maintenance tasks such as examining log files
- Upgrade your Alfresco application to newer versions
- Provide Administrator rights
- Clean up deployment history
This is one of the most important, yet also one of the most neglected, areas of computing. Backing up your data should be at the top of your computer maintenance list—right next to virus protection. Without data backup, you are running the risk of losing your data.
Data loss can happen in many ways. One of the most common causes is the physical failure of the media that the data is stored on. In some situations, users of the system might have deleted the content due to some error. No matter what, your data is your intellectual property and you need to protect it by doing proper backups regularly.
Alfresco stores the content information in both the database and the filesystem. You need to back up both the filesystem and relational database. As a part of the implementation, you might have customized Alfresco, and hence you need to back up customization files. If you have used an external membership system such as Active Directory or OpenLDAP, then you might have to back up the user and group data as well.
You can set up automated processes to back up data periodically. On Linux operating systems, you can write a cron job to run a back-up script on a regular basis. Similarly, all other operating systems support back-up utilities.
Most often, people tend to store the back-up data on the same server. This might create issues when the server crashes. Hence, it is recommended to move the back-up data on to some other external server to store it.
Now, let's examine various types of data which need to be backed up.
Typically, the content in the filesystem is stored in your<install_folder>/alf_data folder as shown in the following screenshot. The folder contentstore contains the binary content with all of the versions. The folders lucene-indexes and backup‑lucene-indexes contain search information. The folder audit.contentstore contains audit trail details:
You need to back up the entire folder alf_data and the contents. Most of the operating systems provide back-up utilities.
If you are a Windows user, you may use the back-up utility that comes with Microsoft Windows XP (it is installed by default with the XP Home version). You will find it from the Start menu under All Programs | Accessories | System Tools | Backup. When you start it, you are presented with the back-up wizard.
A relational database contains a bunch of tables defined as per the Alfresco schema. These tables hold information about users, security, audit, spaces, metadata, rules, scripts, and various business processes (jBPM).
Most of the database vendors (commercial or open source) provide utilities to take the database dump. Based on the database you have selected during installation (MySQL, Oracle, or MS SQL Server), you can use an appropriate utility to take the database dump.
The MySQL database provides a utility called mysqldump to back up both the database table definitions and contents. It can be used to dump a database or a collection of databases for backup or for transferring the data to another SQL server (not necessarily a MySQL server). The dump contains SQL statements to create the table or populate it, or both.
The following is the command to take database backup in MySQL:
Syntax: mysqldump [options] db_name [tables] [> output_file_name]
An example command is:
> mysqldump alfresco > alfresco_outfile.sql
You might be customizing your Alfresco application over a period of time. Typically, you might have added or updated the following files:
- Logos, images, and stylesheets
- JSP files (dashboard)
- Presentation templates
- Configuration files, property files
- Files in the extension folder
- Custom application code (WAR file, source Java files, and so on)
The process you follow to maintain and back up your customization files depends upon the development process you follow within your organization. It is useful to maintain your customization files in some configuration management system such as CVS or SVN, which helps you to easily maintain and back up.
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.
The location of the log files depend upon the application server. For the Tomcat installation, the log files are located at<install_folder> itself. Tomcat application server creates a log file per day. The current log file is named alfresco.log and at the end of the day, the log file 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 files might be pretty big. Hence, it is a good practice to back up the older log files and remove them from the current location to save hard disk space.
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.
For example, you can consider only a one-time backup of customization files. You can back up the files 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 filesystem and relational database is required. You have to consider the business risk and system resources availability while deciding on the back-up frequency.
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 finance or insurance, then you should consider deploying Alfresco in hot back-up mode with master-slave configuration. 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:
- Stop Alfresco to ensure that no one can make changes during the backup.
- Export the MySQL (or other) database.
- Back up the Alfresco
alf_datadirectory. - Start Alfresco.
To restore Alfresco repository:
- Stop Alfresco.
- Delete the
alf_datafolder and restore thealf_datafolder that you backed up earlier. - Drop the database and import the database that you have exported.
- Start Alfresco.
In this deployment (shown in the following figure), 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 benefits 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 files.
In this deployment, as shown in the following figure, 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.
In this deployment option, you don't need to take a regular backup as the data is getting backed up automatically.