Bxp - BCP Notes

Revision as of 16:24, 10 September 2019 by Thomas Glennon (talk | contribs) (Created page with "=<span dir="auto">BCP Notes</span>= <div id="bodyContent" class="clearfix"><div id="contentSub"></div> <div id="jump-to-nav"></div> <div id="bs-bodytext"><div id="mw-content-t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Revision as of 16:24, 10 September 2019 by Thomas Glennon (talk | contribs) (Created page with "=<span dir="auto">BCP Notes</span>= <div id="bodyContent" class="clearfix"><div id="contentSub"></div> <div id="jump-to-nav"></div> <div id="bs-bodytext"><div id="mw-content-t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Contents

1 BCP Notes

1.1 Contents

 [hide] 
  • [index.php/Bxp_-_End_to_End_encryption_and_High_Availability#Overview 1Overview]
  • 2Back-ups
  • 3  Recovery times
  • 4Logical Architecture
    • [index.php/Bxp_-_End_to_End_encryption_and_High_Availability#Web_Tier 3.1Web Tier]
    • [index.php/Bxp_-_End_to_End_encryption_and_High_Availability#Database_Tier 3.2Database Tier]

1.2 1 Overview

Below are set notes on bxp's back-up redundancy operations


1.3 2 Back-ups

1 - Image Level -  Snap shots are held of our Live servers. These are available to us to rollback the windows instance in the event of failure


2 - File level - Our database files are backed up nightly. We currently hold 7 days in a roll followed by backup increments of one file per week dating back 6 months from the current date


1.4 3 Back-up recovery

1 - Image Level -  Snap shots are held of our Live servers. These are available for us to rollback the windows instance in the event of failure. The time for a image recovery can be up to 8 hours


2 - File level - For database files we can recover data from backup files 1-2 hours upon client request. 



1.5 4 Logical Architecture - High Availability

[[]]


1.5.1 bxp uses an n-Tier design architecture ( http://en.wikipedia.org/wiki/Multitier_architecture )

1.5.2 This allows us to provide the client with no single point of failure. All resources have a replica waiting to take the load while we replace the defective server/service

1.5.3 3.1 Web Tier

The web tier is implemented using the High Availability Microsoft Internet Information Server (IIS) again in an architecture way that allows numerous servers to be added as demand requires.


It is finally at this tier that the encrypted SSL packets from the users browser are decrypted and used. Instructions at this stage usually require some form of database interaction. Communications from the web servers to the database tier are then encrypted using SSL over ODBC. ( http://dev.mysql.com/doc/refman/5.6/en/ssl-connections.html )


At no point is decrypted data stored on the IIS server.


1.5.4 3.2 Database Tier

Finally the data, such as a customer record, reaches the database tier. The data is stored in a primary server, with a secondary mirroring backup server in identical configuration logging the data.


The data from IIS is decrypted and stored in the database.


However the hard drives in the database server are also encrypted at the operating system level. The term for this is that "the data is encrypted at rest". ( http://technet.microsoft.com/en-us/library/cc732774.aspx )


All data backups at this point are encrypted into Zip files using AES 256 encryption. ( http://www.winzip.com/aes_info.htm )