Data Backup and Recovery
Data Backup and Recovery
I have 2 diffrent netapp under 1 roof (AFF250 running ONTAP9.10 and FAS2650 running NTAP9.9.1). The AFF250 has a CIFS SVM thats hosting a file server of some sort and i want to create a "realtime" snapmirror replication between the AFF250 and FAS2650. I understand i have to create a new SVM and Cluster/SVM peering with the AFF250. But when it comes to actually implementing what i want to do, where can i configure it so that the snapmirror will be done almost real time?
To be more specific, when a user creates a file in AFF250/CIFS, i want the created file replicated to the FAS2650 almost immediatly.
Any advice is more than appreciated. Thanks!
Solved! See The Solution
You should probably set up a synchronous snapmirror relationship:
Zero RPO is supported by SnapMirror Synchronous. The basic best practices are defined in TR4733 as well as the SnapMirror documentation:
hey guys, thanks for the information. i have decided to go with Synchronous Snapmirror, i have created both the cluster/svm peer and then the actual SM-S job. But it isnt syncing realtime as it says it shoud. When i click refresh, it replicated the new data but when i create a file on the source volume, it doesnt replicate it to the dest volume real time, any idea whats casuing this? i cant even edit the synchronous policy so im in need of some help lol
How do you know that the new files are not replicated to the destination? what's the indication?
well, i had 2 window opened, 1 is the source volume CIFS window (opened via windows explorer) and the other window was the destination volume CIFS window (also opened via windows explorer).
when i create a new file on source volume, i thought if i refreshed the destination CIFS window, the created file would appear. But it didnt. I had to manually press initiate "snapmirror update" in order for the new file to appear on the dest volume.
i read on the KB below that the replication happens once every hour and if i were to go and change it, i can only do so within the time frame of 30min-2hour. It seems like im better of using A-sync snapmirror with schedule time of a minute?
SnapMirror Synchronous doesn't show changes on destination volume - NetApp Knowledge Base
@remr1n You will not see the "Active File System" when you are connected to the R/O DR volume...you only see the volume based on the last "common snapshot copy". We do not provide access to the AFS via CIFS/NFS.
Rest assured, the data is replicated. SM-S is meant for DR purposes more than for data distribution / secondary use cases.
You can shorten the common snapshot copy schedule to a minimum of 30 minutes.
do they actually have to be on the same ONTAP version? the source is 9.11 and the dest is 9.9.1
The doc (https://www.netapp.com/pdf.html?item=/media/17174-tr4733pdf.pdf) says:
SM-S interoperability SM-S supports volume replication relationships between clusters running different ONTAP versions if the difference between those ONTAP versions is no more than two higher or lower than the ONTAP version on the cluster hosting the source volume.
thank you, i have confirmed that 9.9.1 and 9.11 are compatible. ive also found another thread thats similar to mine Solved: Snapmirror Synchronous isn't synching immediately - NetApp Community
i dont need to be able to write to the destination volume but i need the data written on the source volume to show up almost immediatly on the dest volume. can i achieve this without flexcache or flexclone?
According to documentation and my testing it's not possible to schedule the async snapmirror for every 1 minute (unless you use some external scripting mechanism I guess), the minimum is every 5 minutes.
If that suits you (every 5 minutes) then async snapmirror is probably the preferred method
hey after trying several things, i was able to create a snapmirror task that replicated every minute, i did ti by creating a schedule policy using the cron option. thought id let you know!
p.9 Common Snapshot Copy
By default, a common Snapshot copy is created every six hours. The interval between creation of each
Snapshot copy can be modified by creating a custom schedule with a minimum interval of 30 minute and
maximum interval of 24 hours. This custom schedule is then used in a custom SM-S policy or applied to
an existing SM-S policy.
manually created cron job is applied on a policy level - not relationship and it won't give you a chance to add schedule with an interval less than 30 min
here is an example from the documentation (please bear in mind this option is available within advanced level of shell)
Cluster::*> cron create -name 3hourly_schedule -hour 01,04,07,10,13,16,19,22 -minute 03
(job schedule cron create)
Cluster::*> snapmirror policy modify -policy Sync -common-snapshot-schedule 3hourly_schedule -
forgot to mention that i changed it to a-sync replication and created a schedule to replicate every minute
@remr1n What you can do and what is supported are currently two different things...sorry. SnapMirror async is qualified and supported with a minimum schedule of 5 minutes.
hey thanks for the reply. i did change it to a-sync and created a 1 minute schedule.
if there is any documenatation regarding the supported scheule being 5minute, could you direct me to it? i wanna know why 1 minute interval is not supported
Async is 5 minutes for FlexVol volumes and 30 minutes for FlexGroup volumes.
For SVMs (SVM-DR), the minimum is 15 minutes.
Sync has a common snapshot creation of 30 minutes.
thanks i was able to find the KB for supported schedule timings.
is there a specific reason less than 5minute schedule is unsupported? like is it because if its less than 5min, itll put more stress on to the system?
There is aways a balance between available resources, network contention, data change rates, etc. For async, there is not as much pressure to have a "real-time" duplicate on the DR...if there was, you should just use sync SM, SMBC, or even MCC.
As I mentioned earlier, what you CAN do, may not always work depending on the environment. 5 minutes for individual FlexVol volumes is where we find the best compromise to supportability and meeting customer requirements.
With more "complex" volumes, such as FlexGroup volumes, we limit to 30 minutes because we want to be sure we can replicate the volume even when there are a high number of constituent volumes.
If a scheduled SnapMirror replication event attempts to start, while the previous one is still in process, you will receive an error message.
thanks for the reply.
as ive gathered throughout this thread, sync SM is what seems like the viable way to go but since the user cannot see the latest data since it redirects them to the latest snapshot, i cant really achieve what i want to do. (my understanding was that if the write happens on the source and dest vol, you can see the real time latest written data on both but im wrong on this from the information i gathered here)
which leaves me to utilize the async with the lowest schedule i can achieve which was a minute, but the supported schedule is 5 minutes so i guess the user has to deal with it or i would have to find another way to achieve what i want to do
You correctly found a KB.
Depending on the policy sync or stictsync the writes are or aren't accepted on the source until they are written to the destination.
However the visibility of the data on a destination depends on the snapshot.
Meaning that when you try to read data on a destination side you always read the picture of the last replicated snapshot, however all newer data is also being replicated to destination and can be visible only in case of disaster when the relationship is broken and writable