One 'trick' is to use snapshots on the production side. Let the snapshot run the same time you want your replication schedule to repeat on and the snapshot will show you how much your data change was in that period of time (add 100% to that and you should have a remote reserve for that volume). The problem is of course that you end up using snapshot reserve on the production side to figure out your numbers, and unless you run this snapshot as a schedule for an extended period of time, it may not be representative of your peak requirements.
We have a high rate of change with our data so often times we get alerts telling us we have to increase the percentage that we are going to reserve on replication for the data. Often that amounts to increasing the amount delegated to the group. We have around 30 SANs and this happens often enough that we need a faster way to manage the space and changes. Once a volume gets replicated it doesn't need nearly as much space reserved for the changes on a daily basis. I'd like to drop that % down so that the replication group can reclaim that space and use it for other nodes. But I never know how much lower I can drop it. If I'm at 180% can I drop it to 110%? 140%? etc. Is there anything statistically that can give me insight into this, hopefully something I can track via snmp? What usually happens is I drop it down 10% for a day. If no issues I drop it again. I do this until one day it complains. Then I move it higher and leave it at that. Problem is with 30 arrays this gets very time consuming and costly as we have tons of wasted replication space being oversubscribed by the volumes. Secondly I was hoping there was some automated way to increase the space needed when needed (and ideally drop it down). If it runs out in the middle of the night I am screwed unless I set up a txt message or call back from a call center which then wakes me and my wife up, I have to turn on the PC and update the numbers and hope to fall back asleep easily. If I miss all this I wake up to a volume that is severely backed up in how much data is waiting to be replicated. Lastly, does anyone know for sure that this would not be an issue if the replication pipe were large enough, assuming the production and replication groups were too busy, IO wise? I'm wondering if I have a big enough pipe it simply won't fluctuate like this.  Thanks!
Calculate reservation amount needed for replication