Re: SnapVault Integration with SnapManager Exchange

‎2009-05-1504:16 PM

I'm quoting for a FAS 2050, so the licening has all changed as far as software now. Ops Manager is included in the base pack (free). Snapdrive is now part of another "bundle" and licensed on the filer only - no more a la carte. It's all quite confusing and annoying, but what can ya do

Re: SnapVault Integration with SnapManager Exchange

‎2009-06-0404:40 PM

Hi there,

Do we really need to reinstall SnapDrive in order to configure the DFM integration? We have SnapDrive installed on several Exchange and SQL boxes prior to purchasing Operations and Protection Manager, so could/did not configure the OpsMgr integration at installation.

I have tried using the sdcli utility to configure the DFM configuration as in the following:

So, that doesn't seem to be workable. I have tried to account and password fields quoted and non-quoted and the username in DOMAIN\logon and UPN formats with the same result.

If we do have to reinstall SnapDrive (or run the setup and select Modify to enter the DFM settings), will this affect active iSCSI connections? Or are active sessions handled purely by the MSiSCSI service? In other words, will I need to schedule a short outage for each box this needs to be done on? Or can this be done without affective active LUNs?

Re: SnapVault Integration with SnapManager Exchange

‎2009-09-2608:18 AM

Hi there

Because one of our customers did not want to use Protection Manager I just wrote a Powershell-script, which manages by means of the sdcli-capabilities all the snapshot deleting and renaming on the secondary storage.

3. initiate the new transfer by using the *__recent-snapshots of the mount-points and then create the new snap on the secondary

The use of this scripted approach has the following advantages:

- less licenses / software required

- creation and naming of snapshots is under full control of the administrator (not those crippled names by PM with blanks in it...)

- thus having the newest snap always the same name, which allows in turn to back it up to tape automatically

- need of only one single SME-job for creating backups with generic-naming (*__recent)

- archiving is done with several scheduled jobs with different snap-names as an input (daily, weekly, monthly)

The latter two point might sound a bit strange. But imagine an exchange with several storage groups all with different backup-schedules. You need to create a job for every archive management group you whish to use...that could end up in a lot of jobs. With the script approach there is only one SME job, the "archiving-logic" is outsourced (yes I know: instead of having a lot of of SME jobs you now have a lot of script-jobs. But IMHO - listen PM-developers! - this is what I would have expected from PM: here is the place to schedule archive-events, here is the logic when and how long to retain archived backups. Why can't PM just take the most recent backup and just archive it...the scheduler and retention-definition is all there! So PM eg. would now "hey, it is the last sunday of the month - I have an event for that, let's archive this backup with monthly-retention"...no need for "archiving management groups", no jumping back and forth between two apps SME and PM....see the point?)