KFS Disaster Recovery QA

Owned by Benjamin Daniels
Last updated: Nov 25, 2014 by Former user (Deleted)
2 min read

DR Validation Schedule 

 

The below schedule of DR testing was designed to work around key critical dates.  It purposely avoids any kind of testing in the period mid June through August to accommodate year end processing.  

  Calendar 2014

  March 3-10, 2014

  June 9-16, 2014

  September 12-16, 2014

  December 8-12, 2014  (rescheduled to 1 week earlier to accommodate Upgrade project and facilitate RMAN final validation)

 

 

Calendar 2015

March 9-13, 2015

June 8-12, 2015

September - tentative cancel for upgrade

December 7-11, 2015

 

 

DR Validation Project Plan

  DR Quarterly Test Project Plan

 

DR Playbook

 UCONN KFS Disaster Recovery Plan v1.6.1.docx

 

Architecture

 

UCONN's local DR

dr.kfs.uconn.edu

dr.kr.uconn.edu

 

the above servers should be kept up to date with PRD

 

RSMART DR

The remote DR instance is managed by rsmart and resides in the cloud,

They make necessary customizations to our artifacts to make them work without UConn resources (cas / ldap).

With that being said they need to keep the cloud as up to date as possible. That's why after every PRD build, we need to scp the new WAR to rsmart.uconn.edu (scp *.war kfsappsync@rsmart.uconn.edu:/home/kfsappsync/) if you where required to make any config change, you must also make a copy of the prd config, blank out passwords (configuration-defaults-config.xml / rice-config.xml ) and scp them to rsmart.uconn.edu as well. Then notify Todd Yates tyates@rsmart.com; there are new artifacts for him.

 

Icon                

March 2014 testing. Please notify rSmart about updating "Jasper jar files" manually on the remote DR instance. This is for regression testing of JIRA ticket KCONFIG-218

DR Site Validation

Signoff Responsbility

 

 

Functional Area
Signoff (SME)
Financial Processing (FP)Lori Hansen-Roy
Capital Asset Management (CAM) Dave Ferreira
Finance Systems (SYS)Michael Virone
Accounts Payable (AP)Terri Richard
Accounts Receivale (AR)Melissa Ewing
Cash Operations (Bursar) Ann Jordan
Purchasing (PUR)Nancy Patrylak
Technical Pam Kriedeman 

 

Validation Process Overview

The goal of a DR validation effort is to provide substantative proof that the DR site implemented as a result of the agreement between UConn and rSmart is in fact viable and usable in a disaster situation. The testing process will focus on pre-selected key business functions that must be available and functioning in order for the minimum acceptable level of business to continue during a disaster.

The DR validation environment will include the test disaster site implemented in the cloud, and a local disaster environment implemented here at UConn.  These sites are intended to mirror one another in data content and software version. The plan involves establishing the local DR and the Cloud DR using the same application, system, and data files.  The testing process involves the execution of a predefied set of test scripts and scenarios against the cloud DR. Once this testing is completed successfully, the process of restoring local operations from the cloud will be executed. Following the successful restore process, actvities will be conducted in the local DR that are designed to validate that the data generated in cloud is present and intact. Lastly, functionality known to be at risk from the database export/import process will be tested.

The intention behind this effort is to formalize and document a validation process that can be to utilized to perform quaterly DR validation in an effort to ensure the readiness of both our DR provider and our internal support organizations should the unexpected occur.

DR Validation will be performed on a quarterly basis.  Each event is expected to take 5-6 business days to complete

 

 

Â