These are not best practices by any stretch, but in addition to running Legato backup on each appliance and backing up the RSA recommended dirs, we're in the progress of implementing a poor man’s backup and configuration control architecture across our three independent enVision environments (dev, qa, production) by doing the following...
1. Created a secure share elsewhere on our network, large enough to house our stuff.
2. ACL’d it such that only the envision admins and a service account that we control has access to it. Turned on both folder and file level auditing for successful creation, modification and deletion of everything.
3. Created a directory structure within that share that accommodates for anything and everything we'd like to either push out to and/or back up from our EnVision Appliances. It's just one share, but the dirs are along the lines of the following. It serves as the master repository so to speak.
\Secureshare\ThingsToPushToEnVision\XMLfiles\
\Secureshare\ThingsToPushToEnVision\WatchlistInputs\
\Secureshare\ThingsToPushToEnVision\OperatingEnVironmentPatches\
\Secureshare\ThingsToPushToEnVision\EBFs\
\Secureshare\ThingsToBackupFromEnVision\CustomReports\
\Secureshare\ThingsToBackupFromEnVision\ReportOutputs\
\Secureshare\ThingsToBackupFromEnVision\WhateverWhatever\
4. Created a script (still in draft/test) that runs on an appliance, typically the ASRV, that does the following:
4.a. opens a network connection to the above mentioned secureshare, using the service account.
4.b. Opens a network connection to other envision appliances, using a different service account from the .nic domain(s). (We do this not only on our production EA stack but also our dev ad QA envision systems also)
4.c. calls a series of robocopy.exe commands, each custom defined to synchronize data either from share-to-envision or envision-to-share.
<Side note> I chose to leverage robocopy.exe for two reasons
- it has the ability to first perform comparisons of two directories and only copy certain things in certain directions based on certain observed criteria like All thing older than X, or only things newer than last time I was here... etc.
- it has the ability to perform verbose logging out to a txt file of ALL of its actions. What it connected to, what it found, what it copied, etc. (Think audit trail)
-Robocopy.exe is part of the Windows Server 2003 Resource Kit and can be found by searching for it at microsoft.com/downloads
</side note>
5. Schedule the above script to run at your preferred synchronization frequency.
Usages:
1. We got horribly tired of logging into every appliance and manually mapping drives to copy down OE patches, EBFs, etc. month after horrible month. But I'm not going to beat the "RSA Needs to Improve enVision Patching" drum... that's already been done elsewhere here on the forum.
2. We strive to develop stuff on Dev, burn it in on QA if necessary, and then push it up to prod. We needed a poor man's configuration control / source code repository check-in check-out type of system that would help facilitate and automate synchronizing 3 independent enVision systems. So you just developed a new report or correlation rule and want to copy it up? No problem.. just wait 5 minutes and wala! It’s there. You just reimaged your dev applaince and don't want to manually restore from tape backup... wait XX minutes and... you get the idea.
3. We wanted to be able to audit all of the above. Because we have file level auditing enabled on the secure share and its subdirectories AND we're instructing the robocopy to output in verbose mode everything it does, we've got auditing covered. If you wanted to get crazy with the cheese whiz (like those of you in highly regulated industries are forced to do) you could write and schedule enVision reports that show all the windows audit events. I am planning on writing a proactive Alert to notify me if a scheduled synchronization hasn't kicked off (an absence of an event) or it has failed for whatever reason. << insert spare time here >> So that I can see it on the dashboard or get a page.
Oh yes, I should mention that our need started off like yours... to simply backup some directories, and it snowballed into a lot more. I did give consideration to the data integrity while in transit, and its all being done across well trusted paths, but if that’s an issue I'd suggest leveraging the already present WinSSHD to tunnel said traffic over ssh.
Hope some of the ideas are helpful.
cheers,
ryan
Message Edited by Ryan on10-31-200801:32 PM
but it will still work on the newer code despite what it reads. We send our logs to a FAS which is backed up nightly.
