Backup Up Essbase Cloud (EssCS) Applications

Print
The good news is migrating to the cloud doesn’t change a lot when it comes to backing up your Essbase applications.  Conceptually, it is the same.  The utilities used are slightly different.

Enter CLI

If you are new to Essbase on the cloud, the CLI, or command line interface, is something you will want to download and configure.  It is a pretty useful utility and easy to use.  I will say that it is new and missing a lot of functionality you may want.  I was just as frustrated using EPMAutomate with PBCS when it came out.  Three years later, however, EPMAutomate is pretty complete.  I am hoping for the same progression with CLI.  For backing up your apps, the CLI will give you everything you need.

Running An LCM Backup

There is really only one command that is a must.  I will get into why I say this in a second.  LcmExport will run an LCM and store it locally, which is a nice bonus.  There is no need for any other commands to download and rename it.

LcmExport has the following parameters.

  • -verbose (or -v) will provide a more complete response description, especially if there is an error
  • -application (or -a) requires an additional parameter that identifies your application name
  • -localdirectory (or -ld) requires an additional parameter that tell the command where to store the backup file
  • -zipfilename (or -z) requires an additional parameter and is the name of the LCM file that everything will be stored locally
  • -threads (or -T) requires an additional parameter equal to the number of threads you want to use to run the backup
  • -skipdata (or -skip) will tell the LCM to ignore the data in the application
  • -overwrite (or -o) is used will tell the process to overwrite the zip file if it exists
  • -password (or -p) requires an additional parameter to send the password to the command

At minimum, the application and zipfilename parameters are required.  The localdirectory and overwrite parameters will likely be used in every call you make as well.

Why This Isn’t Enough

I have always felt very strongly that data exports should be done because corruption will remain in the pag files until it is fixed, and often times, it isn’t found for days, weeks, or months.  At that point, you can’t export your data and you are in real trouble.  So, I don’t rely solely on the LCM backup strategy.

There are a couple ways to export the data.  With an on-premise implementation you might use Maxl to export the data.  The other option is to write a calculation that does the exports.  The calculations route will provide more option with formatting, the delimiter, and what data is included.  It might be a little slower, but since the inclusion of this option, I have relied on it ever since.

You could integrate Maxl at this point to do the same thing, but the CLI also provides you with the tools to do it if you use a calculation.  At this point, assume a calculation exists named FullExport that exports the data to application and database path on the server with a name of FullExport.txt.

At this point, there are two additional commands that will bulletproof your backup strategy.

Completing The Circle

Normally this would be executed through DOS, or my favorite, PowerShell.  This would allow the dynamic generation of the scripts so they could be reused.  Things like the application name, database name, local path, calc script, and possibly some others, would all be variables.  The result would be something produced similar to this.

I would add a step in my shell to rename this LCM and the data export downloaded with a date and time in the name.

A Final Note

The calculation script referenced above would look something like this.  There are many options that can be set.  If you aren’t familiar with this, a quick google will get you what you need.

As always, post and share. If you have a question, do the same.

Please follow and like us:
RSS
Facebook
PINTEREST
LinkedIn
 

4 Comments

  1. Nice overview of how to backup Essbase cloud apps.

    OAC is backing up the entire Essbase instance nightly. Can these be used to restore selected applications or can they only be used to restore the entire instance? If it’s the latter, than it would seem that there is little benefit from the OAC backups, except in the case of DR, and we each have to create a process to backup our individual apps. Is this an accurate understanding?

     
    • Thank you for the kind words. From my experience, you can’t cherry pick artifacts to backup like you can on PBCS – it does the entire application and all databases. But, if you are versed in Essbase you can open the zip file and grab what you want and put it back in the app/db folder. Although this is not strictly accurate, but it basically backs up the folder contents, so you can pick and choose what you want to unzip and upload back to the instance. Hope this helps. If not, send me an email.

       
  2. Hello Kyle, you wrote “Three years later, however, EPMAutomate is pretty complete.” I disagree and think it is far from complete. I cant make a full automation with just a handful of commands.

    But muy question is, can we export with the DATAEXPORT command directly into a SQL Table, as we can on-premise? This is something we would need, because moving text files back and forth is from the middle-ages and will not be acceptable here.

    Thx.
    Philip H.

     
    • I would love to know what you can’t do with EPMAutomate that you need to do. Outside of being able to run MDX (ASO clears with parameters), I have been fully automating projects for several years. As far as the export to SQL, I am not sure. The option is documented that it is available, but I haven’t had the need to try it.

       

Leave a Reply

Your email address will not be published. Required fields are marked *