Exactly how do SnapManager products integrate with DFM & Protection Manager?
We thought that Protection Manager would provide us with a single console for managing all snap backups....meaning, I would never have to open the SMEX console to schedule a SMEX job...I could create SMEX backup jobs (not just a regular snapshot) through protection manager. We thought the same concept would apply for all SnapManager products (VI, etc). We don't want to open SMVI console to manage VI snaps, SMEX console to manage Exchange snapshots, etc, etc.
We have protection manager installed and I'm struggling to find any SnapManager specific integration in it... It's all very new so maybe I'm not looking in the right place. For the servers running SMEX we do have SnapDrive 6.1 installed and the DFM integration options set. I created a dataset containing the volumes for the Exchange storage groups & transaction logs...but in protection manager when I create protection policies & schedules, there are no SnapManager specific settings. When I run the backup wizard from SMEX I can choose several options...where to run the integrity check, which storage groups I want, backup DB and/or trans logs, _recent naming, etc. Where are these options in Protection Manager? Am i missing something?
Thanks
Can anyone elaborate on Protection Manager & DFM integration with SnapManager products?
Sorry for the delayed reply.....
We have somewhat documented the interaction in TR-3784, check volume 3 for more detail.
As of right now, SnapManager and Protection Manager do have integration, but not to the level you are asking. SnapManager will still be responsible for initiating the creation of the application consistent snapshot on the NetApp storage system. Also, the jobs will still need to be created/executed from within the SnapManager products, but once they are complete, the snapshot that is taken will be handed off to Protection Manager, and Protection Manager will then "archive" (replicate) that snapshot - you will see "on demand" jobs within Protection Manager.
In order to fully exploit this integration, a few steps need to be followed. First, the protection policy must be created prior to running through the configuration tasks within SnapManager. The policy that's created needs to have a local backup of "none" (the reason for this is so that the snapshots that are created are done through SnapManager and application consistent), and the replication schedule should be set to none...in other words, for SnapVault integration, you would just specify retention on the secondary system.
After the protection policy has been created, you can then step through the configuration of that server in SnapManager. When you get to the "Data Protection" section of the configuration wizard, you will see a list of databases that can be replicated and the protection policies (created above) that fit. Select the database(s) and the protection policy you wish. Once the configuration is comlete, check back with Protection Manager, and you should notice that there is a new Data Set, which was created by the integration of the 2.
I would really say the integration of the 2 will more or less give you the ability to monitor and report on your replication sessions for the SnapManager data. You will still need to configure the snapshot creation from within SnapManager, and as part of that job, tell SnapManager you want to replicate that data - SnapManager will send an API call to Protection Manager to start that transfer.
Hopefully that somewhat helps answer your questions.
Thanks!
Jeremy Merrill
One important caveat when archiving your SME snapshots via Protection Manager is that your underlying Exchange databases have to have been created on qtrees. SnapVault uses qtrees, so if your databases, logs are not architected on qtrees then you're out of luck. This use to be the case, but if I'm incorrect now I'd love to know.
That is correct, the LUNs must reside in qtrees, but that can easily be fixed with a lun move, after you create the qtrees. The reason for this is 1, that's how SnapVault works and 2, in 7.3, non-disruptive incremental restore was added. If the LUNs aren't in qtrees, that functionality is lost because SnapVault must restore to a qtree.
Thanks!
Jeremy Merrill
Agreed. I think the problem with a LUN move is that most people architect their capacity for a certain amount of capacity based on Exchange sizing. You'd have to have at least twice the space available to move your LUNS from source volumes to target volumes. Their would also be a lot of downtime as you'd have to disconnect your luns from snapdrive and create new luns with the new paths. If there was a way to nondisruptevely do that, perfect.
Definielty be easier to architect using qtrees from the outset, but unfortunately things like archiving snapshots using snapvault aren't thought about until a much later time.