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

[Stacey_Greenwoo]

As years pass, would it hurt anything to go back and delete documents in Copy 1 if they would only need to be in a Read Only state? If would not hurt anything, is there a way to automate this deletion?

[AdamShaneHyland]

Hi Stacey.

No, it would not. But I would highly encourage you to perform a Disk Group Analysis prior to the deletion to make sure that all files on Copy 1 are on Copy 2. I would also make sure that you have a strategy in place to make sure that you have redundant copies of the data. This could be done through a file storage backup or replication.

Best wishes.

[Ashish_Srivasta]

Adam,

Are you referring in your post the scenario when during DR only primary copy location is unavailable but Prod system/front end/DIP  is still available to users? Assuming there is only 1 copy of Disk Group and it is pointing to SAN

During DR, if the entire Prod data center is down, no users can access the Prod system

Is all not well if we use SAN which points to two cluster members and if one member id down, other can serve so we will never come to READONLY ONBASE system? If both members are down(storage is not accessible but web client is accessible, DIP is accessible) then OnBase system will be READONLY and in this case, question comes - are we losing any uncommitted batches if we are using SAN, I guess No as nothing is available to store so nothing can be processed? Any insights?

Kind Regards,

Ashish Srivastava

[AdamShaneHyland]

Hi Ashish.

In a scenario where you have a SAN with multiple nodes storing your Disk Group Copy 1 (meaning the uncommitted copy), if one of the nodes is unavailable, then your SAN should fail over to a secondary (n + 1) node which is available.  If that is the case, then OnBase would not be aware of the unavailable SAN node and access to READ and WRITE should be available.  The fail over should be transparent as part of your storage technology and you should not have any down time.  As long as OnBase has a UNC accessible location (or S3 in OnBase Foundation or higher) available for the uncommitted copy (i.e. Copy 1), then it will never enter a READONLY state.

To my previous post, if only the storage location referenced by Disk Group Copy 2 (or higher) is available (meaning the Disk Group Copy 1 is not accessible), then OnBase will be in a READONLY state.  At this point, no new documents can be imported into the system (via ad-hoc imports, scanning or processes such as DIP).  However, the system will still be accessible via any of the clients (OnBase Thick Client, Web Client, Unity Client, etc) in a READONLY state.

If all access to your Disk Groups (file storage) and Database is unavailable in a DR scenario because your data center is not accessible, then your OnBase system will not be accessible.  Typically in a highly available system with disaster recovery architecture, the OnBase system is replicated to a secondary (disaster recovery) data center.  This means that while OnBase primarily operates out of one data center, in a DR scenario OnBase can operate (fail over) to a secondary data center.  Depending on the technologies you use, this can be transparent or near transparent.

If you system only operates out of one data center and the data center is unavailable for any reason, your system will not be accessible.  

Take care.

[Ashish_Srivasta]

Thanks, Adam for clarifications!

The question that still remains is "If both nodes for SAN are unavailable,  are we losing any uncommitted batches or related data?

Kind Regards,

Ashish Srivastava