Reason for 2 copies

[David_Kranes]

Hello. we are currently faced with growth issues and are wondering what is the true purpose of having 2 redundant copies in OnBase?  Are they truly exactly the same?  Unfortunately when OnBase was installed and configured in our environment, they placed both copies in the same folders on the same disks.  Is it really necessary to have both copies with a redundant SAN?  Can OnBase be configured to only create 1 copy and Is it advisable to do so?

Thank you in advance for whatever expert explanations and advice you can provide.

David

[Scott_Roark]

David, thanks for this question.  

As one of the Trainers here at Hyland we discuss this question quite often with our customers.

When I discuss Disk Groups I advise our customers of the following:

At any one point in time, there should always be at least 2 Copies of your Disk Groups, whether OnBase is aware of it or not.  The reason:  Redundancy and for Disaster Recovery

It is recommended that each Disk Group Copy be on it's own Mass Storage Device in a different physical location.  This way if anything happens to the first copy, if OnBase is aware of the location of the 2nd copy, it will just default over and you will not incur any disruption.

Currently we have many customers who are leveraging SAN's to store their Disk Groups.  And since SAN's basically duplicate the information, customers will ask, "Do I really need multiple copies?"

And I would say the answer is still YES.  Because a SAN only resolves the issue of Redundancy. 

Most likely, the team that handles your SAN already has Disaster Recovery plans in place. They probably have secondary SAN's lined up as back ups.  They might already be transferring data to the back up SAN's as well.  So in the event it's needed they can stand up these secondary SAN's and everything will operate as you'd expect.

So, can a Disk Group operate with only 1 Copy? Yes.

But the benefit to having 2 DOCUMENTED Copies (Meaning, OnBase is aware of the physical location of BOTH Disk Group copies),  is that in the event of a problem with your first copy, OnBase will automatically fail over to the 2nd, 3rd, 4th, etc... copies.  All this means is no disruption for you or your users.

Finally, so long as you are committing your batches on a regular basis, you can fully expect your copies to be exactly the same.  If not, you're always able to go into Platter Management and perform Analysis to resolve any missing files.

I hope this explanation answers your question and provides some insight into Disk Group copies.

Scott

[Drew_Hargrave]

This is very helpful guidance Scott! One additional question, in the event that we loose Copy 1 and are running on Copy 2 ReadOnly, is there an easy way to promote Copy 2 to Copy 1 so we can work in Write (Uncommitted) mode again? Or do we have to recovery the Copy 1 \\server\sharename path for Onbase to come out of ReadOnly mode?

[David_Kranes]

This is great Scott.  Thank you for the detailed explanation.

David.

[AdamShaneHyland]

Hi David,

I would like to expand a bit on Scott's explanation.  Everything he said is accurate and should be considered with the addition of the point I would like to make for DR.  The challenge you are going to run into with a DR scenario is that if your primary Copy location is unavailable, then your OnBase system is in a READONLY state until a new Copy 1 location is available.  Remember, you are only able to scan to the primary mass storage uncommitted location which is always Copy 1.  If you are using SAN replication for Copy 1, if one location was unavailable, the secondary Copy 1 location would be able to facility the uncommitted data. 

PLUS, if you are replicating Copy 1, this means all of your uncommitted batches will be available.  If you utilize OnBase for Copy locations, and Copy 1 is not available, then non only is your system in READONLY mode, but you lost all of the uncommitted files.

There is more information about this topic in this presentation: Tactical Storage Considerations for an OnBase Solution, this White Paper Disk Group Design for High Availability using Microsoft Distributed File Services (dFS) OR in this this White Paper Disaster Recovery and High Availability for OnBase.

Best wishes!