Hi Paragi,
In regards to OnBase disk groups specifically, you can use DFS for copy 2. You address OnBase to the DFS namespace. In the event of failing over to your DR site, you would be able to bring up OnBase however; it would be in a read only state until you configured a Copy 1 disk group location. OnBase cannot ingest files unless the Copy 1 mass storage location is present.
Assuming all of your disk groups are configured for Copy 2, any committed data would be on your DFS shares. Any uncommitted data would not be on the DFS shares. You would have to determine whether you have batches on a scheduled commit. Uncommitted batches reside only on the Copy 1 disk group location. Committed batches and files are distributed by OnBase to the configured online copies. In the event of a disaster (you lose the main datacenter) if Copy 1 was not being replicated outside of OnBase, the batches would not be in the DR copy and would have to be reprocessed.
So - as long as all disk groups are configured for Copy 2, and DFS is working with a node at the DR site, and all files and batches are committed upon indexing, all of your disk group data should be on the Copy 2 DFS node at the DR site.
On failover, you would need to create and assign storage to OnBase to be the DR Copy 1 location. Once storage was available, each Copy 1 disk group volume would be force promoted and the new UNC path to the DR Copy 1 storage would be set in platter management. Doing this would restore the ability to ingest files at the DR site. Pre-disaster data would be read from the Copy 2 DFS storage while new data would be written and read to/from the newly assigned DR site Copy 1 storage.
Now that you have that information – consider configuring Copy 1 of OnBase using DFS. As long as you had a functioning DFS node at your DR site, all of your committed AND uncommitted files would be replicated. On failover to the DR site, no adjustments to the OnBase disk groups would be required since the DFS namespace would not change.
Of course, you have more to account for in DR planning than just OnBase disk groups. You would want your plan to account for time to validate that your disk groups and OnBase database were in sync since, in all likelihood, your database files may be replicated at different rates than your disk groups.
Hyland wants and expects our customers to call tech support when they have DR events affecting OnBase. Hyland also offers Disaster Recovery consulting services through our Global Services group. We can help identify how to leverage technologies in your environment to integrate with OnBase functionality in order to meet your recovery time and recovery point goals.
