The Journal size is a question of the required protection window (a Business requirement) and the incoming write rate of the production application. Whilst the Recovery Point Objective might be known, the incoming write rate of a newly deployed app may not be, making sizing of journal LUNs a bit “finger in the air”. EMC provide a guideline value of 20% in this instance, but it has no real foundation.
The basic calculation is ( protection window in seconds * write rate in seconds ) / 0.7
The division by 0.7 is because roughly 70% of the journal is used for replication images.
For example, if the business requires 1 day of images and the average write rate by the application is 1MB/s you will need a minimum of about 125GB journal to support it. RecoverPoint supports automatic journal LUN creation during configuration of a Consistency Group if you don’t have enough information to manually size the journal LUN up front.
During a recent deployment of RecoverPoint to support replication of LUNs to remote storage, solely for the purposes of failover, EMCs response was as follows. Please note that in this scenario, there was no requirement for the “killer functionality” of RecoverPoint, namely point in time recovery using the journaled changes in Consistency Groups. That’s not to say it won’t become a requirement later on however.
The Raid group in question would definitely be adequate to start replication, but whether it is enough to meet the business requirements, we cannot say.
Sizing aside, remember that it is very important to use a dedicated Storage Pool/RAID Group of physical disks that is entirely separate to ones used for your data LUNs and RecoverPoint Repository LUN.