As we continue to explore the best practices around ElectricCommander, this week we will review backup strategies for your production environment. Remember, it’s not a question IF you disk will fail but WHEN. This is a too important subject to leave to chance. You spent too much setting up and growing your ElectricCommander environment to risk losing it due to a faulty disk or a bad server. There are additional ways to mitigate crashes like RAID disks, virtual machines … but this is beyond this particular article, just let’s focus on the backup part of the equation.

There are a few parts to consider in your backup strategy:

1. Database backup

2. What files and directories to save on the different servers

3. Project and server export

4. Frequency of backups

Database backup

If you have an IT group that manages your database, simply ask them to add your ElectricCommander instance to the regular backup. Do not necessarily assume they would do it by default. The exact method to use is really dependent on your environment and the type of database you have deployed in your environment. For example, you could use mysqldump if you are on MySQL or expdp if Oracle is your choice. Please refer to your database documentation for a full explanation on the different options available to you.

Files and Directories

This category regroups all the files and directories you need to think about when establishing your strategy. They include:

1. Configuration files

2. Artifacts

3. Plugins

4. Workspace directories

Much of the data you need to backup is in various subdirectories beneath the “Commander data directory”; by default this means /opt/electriccloud/commander on Linux and C:ProgramDataCloudBeesElectricCommander on Windows 7. Check the installation documentation for details. Let’s refer to this location as <DATADIR> for the rest of this article. Let’s look in details at each category.

Configuration Files

Backup the following directories and files on each server, including remote Web servers and Artifact Repository servers:

• <DATADIR>/conf: configuration files for the Server.

• <DATADIR>/mysql/mysql.ini: if you use MySQL, add that one to your selection.

• <DATADIR>/apache/conf: configuration files for the Web Server. Note that it could be installed on different hosts.

• <DATADIR>/conf/repository: This needs to be backed up only if you have Artifact Repository servers installed on different hosts

Artifacts

You need to backup this directory only if you use this feature in your deployment (which of course I highly recommend). Only the files themselves are stored on the file system, the metadata associated are part of the database. You need to backup on each Artifact Repository Server; you can have more than one and it could be a different host then the main Server.

• <DATADIR>/repository-data

You do not need to backup your artifact caches; they will be populated again as required.

Plugins

The plugins directory contains data for each of the plugins you’ve installed. The code and configuration settings for most plugins are stored in projects and properties (i.e. the database) but help files and documentation are typically stored there. The plugin location is defined in the Commander Server property /server/settings/pluginsDirectory. If you have not overwritten it, plugins will be installed in the default location:

• <DATADIR>/plugins

Workspace Directories

This one will depend on your usage. Remember that key job data like timing, user information, exit status and outcome … are stored as properties and are therefore part of the database. However step logs, diagnostics, possibly build outputs … are stored on the file system. So if you deem some of those files to be important and need to be preserved, you may want to back up your different workspaces. Depending on your usage, those may use a lot of space. The default location is:

• <DATADIR>/workspace

Projects

In addition to the “compulsory” backup described above, you may want to export your projects on a regular basis. The reason behind this suggestion is let’s imagine you delete a project by error or make heavy modification to your process and break your project, you can always restore the database but it has a lot of side effects like:

• Other people projects could be overwritten

• Jobs than ran since the last database backup

• ….

An easy workaround is to simply export each project in its own XML file. There is even an existing procedure in the optional Administration project EC-Admin available on GitHub . Once you have exported your project into an XML file, you can even check it in in your favorite CMS to simulate version control until this feature is part of ElectricCommander (I was told it will be available in version 5.0 scheduled for H2 2013 but please add the usual proper Marketing disclaimer about roadmap here). You can use this API to export part of (like important resource properties) or the whole server. Be aware this method can take a long time to export the whole server depending on the size of your database and could impact performance.

Frequency

Now that we looked at what to backup, let’s have a look at how often you want to do it. I’m going to give you the answer everybody hates: “it depends”. I know it’s a cop out but it’s true, it really depends on how often your data change, how big they grow, how you backup and most importantly how much data you can lose without impact? For example your configuration files should not change that often, so backing less frequently is fine. The same rule applies with your plugin directory. That being said, your backup system may not use more space if your files have not changed. So why take a risk? What about your workspace directories? It’s really up to you to decide about those. What about database? Personally I would do it every day. Same with project exports, especially if you’re in a development cycle. I would also add a weekly full server export.

CloudBees strategy

This is not necessary the strategy you should adopt but here is what we do at CloudBees as an example:

1. Weekly full database dump with Oracle tools

2. Nightly backup of specific project using the export API

3. Workspaces are on RAID10 disks with their own backup systems

Conclusion

My goal writing this article was not to give you THE ultimate backup strategy but to make you think about it, especially if you are a recent user of ElectricCommander. My experience shows people delay that discussion and then forget. So if you have not done so, please plan now before disaster strikes. As usual, please let me know if this discussion is useful to you by contacting us directly by email .