There is a change in behaviour between Commvault version 7 and version 8 in the way that the Public Folder iData Agent handles public folders.
In Commvault version 7 the Public Folder iDataAgent will only back up content for local public folders. Any public folders for which there is no local replica on the Exchange server being backed up will not be included in the backup.
In Commvault version 8 the Public Folder iDataAgent will back up both local and remote public folders. This means that if the local public folder database has replicas for say 5Gb of the total 20Gb of data in that public folder hierarchy, it will back up the remaining 15Gb from a remote public folder database.
If the remote public folder database that it connects to is over a slow WAN connection then you run the risk of two undesirable outcomes:
- WAN link saturation during the backup window
- Very long running public folder backup jobs
There are three approaches that you could take to resolve this:
- Replicate all public folder data to any server that is running Public Folder iDataAgent backup jobs. This may increase local storage requirements and WAN utilization caused by public folder replication (though you can optimize this in the public folder replication settings to suit your network).
- Only run the Public Folder iDataAgent backup job at a central site that holds replicas for all public folders in the hierarchy. This is probably the least administrative effort. However it requires that any data restores also be run at that site and then replicated to the remote site that needs it, which potentially lengthens the total restoration timeframe.
- Narrow the scope of the Public Folder iDataAgent backup job to only those folders in the hierarchy for which there are local replicas. This solves the problem now but could lead to new folders created later not being included in the backup scope.
