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.

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.

-Doug.