Monday, August 18, 2008
Essbase Backup Methodologies
I admit it. I like to keep things simple. I am also a rather complex person. Is this a dicotomy or a natural
result of one begets the other? I don't know, but what I do know is that simple cannot be defined from a universal
perspective. What is simple for one person is more often than not very complicated for others.
1:08 pm est
Take for instance
the task of backing up databases. The simplist approach from an IS perspective is to just throw a tape drive at it and
call it done. Most IS professionals will tell you that they have software than can back up files while they are in use,
so this is all that is needed. While it's tempting to laugh at this concept, it's often hard to convince certain
people that this is not the wisest choice of actions to take. What's worse, the tape access to the machine is often
done at the worst possible moment during the day (thank Murphy for that one), in the middle of your key calculation -- despite
assurances that the backup window is set in stone and won't be violated.
Do I blame IS for this? No.
I blame the underlying concept of backing large files up directly in a non-static environment. This is the issue, and
once you understand that, you can free yourself from the problem entirely. It really is that simple. No matter
how big your database is, the backup must be of high enough priority to justify keeping a static copy of the data. The
backup can access this "dormant" copy at any time, especially if that copy is not on the same drive set as production.
So how best to do this? Well, this gets back to the definition of simple. In my case, I use the archive.cmd
file from the downloadable content section here. It's a simple command script, meaning that you don't need
to have additional skill inventories to support it. What you DO need, is a good understanding of notepad and command
scripts though. This "throwback" technology is a lost art, admitedly, but easily mastered -- at least sufficiently
to do the installation and extremely infrequent maintenance for the backup. Other than reconfiguring the script, I haven't
changed it in many years (and I haven't even edited the script in more than two years now). It's complete, one
call and it does the whole thing.
So what else? Well, how about what and when? I perform a backup whenever
I do the primary data load for any production database. This way, the downtime is just a part of handling the data load
itself, and kept minimal at that. I also keep three copies of the database, although the script can do up to 9 generations
without modification with any number of uniquely named "types". Why three? Mostly to allow a Monday
recovery of Friday's data -- but this was just a matter of simplicity on the automation side.
What else should
be considered here? How about the server's configuration itself? I have three drive sets for the production
server. The "C" drive is dedicated to the operating system, as most people would guess. The "D"
drive is for backups ("Data"), and the "E" drive is for essbase. This simplicity is just a matter
of isolating one set from another. It also allows me to tell IS to backup the C and D drive however they want -- although
I recommend a Weekly Full drive C/D backup and Daily Differential backup of D. Either way, using this configuration
keeps things simple from an isolation perspective, even if it seems like three drives are otherwise more complex than one.
Yes, I often make things more complex on the automation/design side to keep them simpler on the maintenance/user side.
In other words, it's not about making it simple for me to design, but simple to use and maintain. Often,
the two are in harmony, but not always.