C17.7. Data escrow and backup. Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.

Functional Description:

Data Escrow will be performed on a regular basis (every 24 hours) and involves the transfer of all data, programs and documentation from Unity Registry’s Registry System to the nominated escrow location of National Computing Center (NCC) (http://www.nccglobal.com/).

The NCC Group
Manchester Technology Center
Oxford Road, Manchester M1 7ED
Tel: +44 - (0)161 - 242 - 2200
Fax: +44 - (0)161 - 242 - 2400

Full details can be found in Section C13.

The data escrow process will be as fully automated as possible.

A job will be scheduled to run at a convenient time to extract the required data from the Registry’s database and generate the required files in a nominated directory, together with all required software and documentation files:

• Complete Source and executable code of Registry, DNS and WHOIS
• Database definitions and contents of the database
• Operational and configuration files and information
• Documentation covering the installation, configuration and operation of the system
• Help files, operation and user manuals.

The contents of the directory will then be transferred via the Internet (FTP or Email) to the escrow site and validated.

* 314 deposits in a Leap year

Deposits will be verified and processed by The NCC Group on weekdays only. If the conclusion of the four-hour window is before 4pm, on a business day, then the deposit can be verified on the day of transfer.  If the transfer occurs after 4.00pm then the verification of the deposit will take place on the next business day.

This relates to:

**  A slightly modified schedule will be in introduced during UK Bank Holidays.

The time taken to verify the daily deposits will increase over time depending on the execution time of the ICANN-supplied program.

Electronic copies of the deposit files and encrypted format and completeness reports are to be retained by The NCC Group.  As the size of the data increases the time taken to create a CD-ROM, or other medium, will increase and the number of media required may also increase.

The NCC Group will retain, in its Escrow storage facility in Manchester, the four most recent verified Full Deposits and all subsequent incremental deposits lodged after the earliest of the four full deposits.

Procedures:

The Escrow Folder:

A file on the nominated escrow server will be set up, any information put into this folder will be included when a full escrow is to be done, at all other times only database data is to be escrowed. Any time a code change is completed or document change etc the files in this directory will be updated, so that the full escrow is up to date.

Procedure:

A scheduled job will wake up at the escrow time and execute the appropriate scripts to obtain the correct data out of the database and dumping it in the correct format. This procedure is very quick and uses an Oracle “view” to dump the data to a file efficiently and rapidly. Once this is completed if it is to be a full escrow the file is combined with the data in the escrow folder on the machine otherwise it is the only file to be escrowed. The information is “tared” and finally PGP compressed and encrypted and then securely copied to the escrow server. Email notification is sent to the relevant people of a successful escrow and the process finishes until scheduled to run again.

Security:

The transfer of information will be done over a secure copy connection.  It is expected that the receiving party will properly firewall the machine hosting the receiving daemon on and only allow connections from IP address that Unity Registry supply. The data will also be PGP encrypted as a final security mechanism.

Data Format:

The Database data contained within the escrow data will be formatted in XML (Note this is different to the XML WHOIS data). Unity Registry will develop an appropriate XML schema (an example of which is in Appendix 0) in conjunction with ICANN to describe this database file, the XML elements of the schema will be constructed in such a way that reconstructing the database out of this data is relatively simple. XML is ICANNS preferred method and we would work on providing a schema that is mutually beneficial to both.

The data from the database and all other Documents and objects contained within the escrow will be laid out in a sensible directory structure, separating code and programs, from reports and documentation.

Rebuild from Escrow:

Rebuilding from the escrow data is to be viewed as a last ditch effort, a lot must have happened if we, or a third party, has been forced to rebuild from this level. In order to do this, a system of similar hardware will need to be set up. Rebuilding the database is as simple as installing Oracle, creating the database schema, then running the supplied plsql scripts to read in the escrow data and dump it into the tables, next the dump process would have to be verified and all indexes reconstructed. Next application machines would need to be setup, the code from the relevant directories would need to be compiled and installed on the machines. The complete instructions for doing this Escrow rebuild will all be contained within the escrow data. It is estimated that assuming all hardware is available a rebuild from escrow only, once hardware is in possession of whom ever is doing the rebuild would take approximately 1-2 days.