Using Life Cycle Management for Changes AND Backups

Lifecycle Management is most commonly used to promote changes from one environment to another.  However, there’s no reason that you can’t use this same tool to recover back into the same environment. With that in mind, LCM can become a terrific backup solution.
The steps are simple enough. A bit of up front work, a bit of scripting, and you will have a nightly “hot backup” that can be used to recovery almost everything from a lost app to a single report that was accidently deleted or modified.
First, we have to create the definition. From Shared Services, access LCM as you would for a live migration. Define what you want migrated (normally everything) and walk through the pages to define the migration. However, instead of selecting “Execute Migration”, you select “Save Migration Definition”. This will output an .xml file that holds the LCM export definition.
This is repeated for each item in the LCM tree (Shared Services, Planning applications, HFM applications, EPMA, Reporting and Analysis, etc.), giving each their own distinct and identifiable backup file and xml file. I recommend you keep these 2 names the same and something very obvious to the casual reader (i.e. HSS.xml, MYAPP.xml, Reports.xml, etc.). A couple of warnings here – first Essbase is not migrated via LCM – the export gets SubVars and not much else – no outlines, etc. Second, if your reporting folder structure gets too large, you will find that backup taking hours (at one point I saw it approach 24 hours). If this happens, break it into several backups, one for each reporting folder (i.e. Reports-FolderA, Reports-FolderB). For this approach to work, you will need to severely limit or keep reports out of the root folder altogether.
Now that you have migration (or backup) definition files, you need to get an admin-level encrypted password into them. Otherwise you’ll be asked for username / password every time they are run, making them useless as an automated backup. I always use the ‘admin’ account. It is an automated process and should have all the rights required for the backup. It is also a “known value” that won’t change.
Login to the Shared Services server, make sure you place the xml file somewhere local on that server and set up a backup directory. Once you have done this, run the LCM tool from the command line. You can run it on either Windows or UNIX – it works the same way. In a Windows environment, the command would look something like this:
D:\Hyperion\common\utilities\LCM\9.5.0.0\bin\utility.bat <xml file name> -local -b <backup directory>
You will be prompted for username and password. Once you provide them, they will be encrypted and placed in the .xml file, so that you won’t be prompted again. Repeat this process for each xml file.
Now you’re ready to script. Use a scripting language you are comfortable with, that works on the OS you are going to use. My most commonly used are Perl, Bash, and (reluctantly) windows CMD scripting.
You can make the script as intelligent or as simple as your needs require. Some basic steps would be:

1. Make sure the backup directory exists
2. Clear / move / delete previous backups in that directory
3. For each xml file found, run the utility.bat like was done manually above (you’ll want to capture both normal output and error output to a log file)
4. I always zip of the output directory to save space and also to make it easier to move to an archive location.

Note –You will need to use 7zip on a Windows system because of limitations of normal Zip and the requirements to zip up Reporting and Analysis directories.
Some more advanced steps would be to kick off the LCM backups in parallel, email upon error and/or completion, test for older backups and remove any that are more than a week / month old. These are nice, but not central to the basic steps – as I said, you can make this as simple or complicated as your needs dictate.
Test the script a few times manually; keeping an eye on the time it takes to run.  If you get the results you expect, you’re ready to schedule this nightly. There is no downtime required. Keep in mind, however that this will impact system performance, try to schedule it when there aren’t competing processes (consolidations, data loads, etc.).
Finally, a backup is only good if you can actually do a recovery with it. Make sure you use the backup to recover some sample data and verify it. If you’ve zipped the backup to a file, unzip it to the import_export\<user> directory (otherwise just copy the outputted LCM application directory for one backup to that location). Open Shared Services and make sure you can select items for import. To be completely certain it’s working, move a sample item (i.e. a report) to another name and actually perform the import for that item. Verify the imported item matches what it should be from the time of backup.
There is a side benefit from this process. When it comes time to promote changes to a new environment, you already have an export ready to go from the last backup. This may not be the most efficient way to promote a single form, but works great when the promotion is more comprehensive.