Journal Volume Sizes

Realistically no...

You could take a stab at it, but you could end up over-allocating (longer protect than needed ie storage cost) or under-allocating (not meeting SLAs)...

Suggest to profile the change rate of your applications with performance data (KB/Wr) over a an expected lifecycle, prehaps a week or so (covers weekend maintenance, etc).

James.

Depends...
More smaller LUNs are good as long as they dont cause spindle contention on the back end.

Some people use smaller LUNs so they can get more performance from the back end.....depends on requirements...

You could also just allocate small LUNs and then monitor the consistency groups and the journal to see what time period the bookmarks span before being overwritten. If the time is too short, just add more Journal volumes. That has worked for me.

Yep, as James stated we achieve good performance for our Journal volumes by spreading out on the backend the disks that make up each volume. We are replicating OLTP databases with very high transactional rates so we need the performance edge everywhere we can find it.

Interesting idea. Is there a negative to having multiple small journal volumes for one consistency group, as opposed to 1 correctly sized journal volume?

Chris

Man, that would have been a nice tool to have when we deployed RP a couple of years ago We had to just monitor backups and log files and used trial and error for Journal volume sizes.

Agree with James, the best avenue is to use empirical data to size, absent that you would need to assume % of change rate for the protection window period needed and size journal based on the assumption.

EMC has developed tools to size journals for both existing apps as well as net new apps where you may not have the historical data. Contact your local EMC Technical Consultant for assistance and they can help you address this.