Running Data ONTAP 8.2.1 and have a FAS8020 at our Production and a FAS2240-4 at our DR site. We currently use Snap Mirror relationships to mirror the Flex Volumes over from Production to DR. This is only for 7 days though. We want to ensure that we can keep longer term backups though for some of the flex volumes. .e.g the ones that hold the most critical data.
All of our Flexvolumes are used as VMware storage and are separated based on the OS installed. So for example we have a dedicated flexvolume for W2k3, W2k8, Linux and so on and we many of these with a size of 2TB.
I have spent reading some of the following NetApp documentation:
Data ONTAP 82 Data Protection Online Backup and Recovery guide for 7 mode
I have more questions than answers though! hopefully someone or a few others can help me with my questions
I currently have the licensing enabled on both filers, can the snapvault operation just been performed from the DR side or does it have to be created on the Production side as well? we have a snapmirror relationship already running can we not utilise the snapmirror relationship already in place and extend those with the retention time we require on the DR filer?
If this needs to be setup on both filers, do the snapshots consume space on the production filer?
We have a number of VMs per flexvol. So in one flexvol we might have the exchange server VM and a database server as well as many others. What about if we wanted to have a longer retention on the exchange server (e.g. 1 year) the others (only to have 30 days)? Is that going to be possible or would we need to categorise our VMs based on retention and then move them into appropriate flexvols/qtrees and apply a different retention based on the flexvol?
All of our flexvols are setup without qtrees, and we want to use these with snapvault. From my reading it seems it is recommended to use qtrees rather than just volumes. If this is the case is it as simple for me to create a qtree and link it to the flexvol and that resolves potential issues with qtrees and snapvaulting.
If I have Snapmirror running daily on a 7 day retention, can I avoid creating snap vault daily jobs? I am just thinking would I be duplicating workloads.
Does snapvault have similar bandwidth requirements as snapmirror? The reason I ask is if we large data changes on our flexvols we find sometimes the snapmirror lag time can be extended which is expected, also our routers on both ends are kept very busy during the transfer process with high utilization. I am concerned when we first setup snapvault for a flexvol is it going to cause a slowdown copying the initial baseline whilst also doing snapmirror updates (we have these currently set to mirror every 2 hours for most of our flexvols)?
Can I create snapvault destination on the same aggregate as where the flexvols and destination snapmirrors go to on the DR filer? As we only 1 aggregate setup both on the PROD and DR filer.
If all snapvault volumes can go into one large flexvol, can I increase the size of this snapvault dedicated flexvol like I would normally do if I needed to extend a standard flexvol
Can Snapvault destinations only be on a NetApp device? Would I be able to utilise our NexSan storage in any way?
So, let me answer the first question b/c it might save you all the trouble.
If your DR filer and production filer have enough space where you can save, lets say 30 nightlys, then you don't need snapvault
A few things - depending on how you are going to manage snapvault. Are you going to manage snapvault from OCUM or at the filer CLI? This makes a huge difference in hwo you implement sv
Are you planning off coming off the primary data or coming off the mirror copy. Note, that if you come off the mirror copy, it will lock your VSM snapshot, so your VSM will not update while you are doing an SV
The beauty of SV is you can have any schedules and retention you desire, You have more flexability in scheduling with OCUM, but there are some downsides.
If you are already setup without qtrees, then don't think to migrate with qtrees. If you have VM's in same volume, they are all along the same ride for retention on that volume. So, if you have an exchange vm and a database vm in vol1, and your retention is 30 dailys, that's what it is for both. Only way to separate is to migrate
"If your DR filer and production filer have enough space where you can save, lets say 30 nightlys, then you don't need snapvault" For this would you mean I could use VMware VSC and just extended the retention this way? or do it via snapmirror and just keep more snapshots? Would there be a disadvantage of not doing it via SV?
"A few things - depending on how you are going to manage snapvault. Are you going to manage snapvault from OCUM or at the filer CLI? This makes a huge difference in hwo you implement sv"
My preference would be to use the OnCommand System Manager over CLI
"Are you planning off coming off the primary data or coming off the mirror copy. Note, that if you come off the mirror copy, it will lock your VSM snapshot, so your VSM will not update while you are doing an SV"
My preference would be to use the mirrored DR copy as all the work is done at DR end and no performance impact on production side however we run snapmirror every 2 hours for some of our flexvols, if it makes things better maybe I could adjust snapmirror so that is only performed every 12 hours and then Snapvault is performed more frequently, we could change snapmirror schedules if it is a threat and will be in the way of Snapvault.
"If you are already setup without qtrees, then don't think to migrate with qtrees. If you have VM's in same volume, they are all along the same ride for retention on that volume. So, if you have an exchange vm and a database vm in vol1, and your retention is 30 dailys, that's what it is for both. Only way to separate is to migrate"
Is it not possible to enable qtrees after volume is in use? My concern is in what I have read when it comes to restoring it easier to work with qtrees rather than flexvol. I am guessing I would need to create new flexvols with different retention periods or maybe create new flexvol with higher retention as most would be 30 days, only few servers would require longer retention.