Page Comparison

{mockup:test|23}


This page describes how we will support the MAD in a production environment.

Enumerate the types of failures that are obviated by the redundancies built into Applogic grids.

Are these intrinsic redundancy features this the same as those offered by our ESX products?

Define the SLA for DBI.


Enumerate additional failure scenarios and describe the plans to mitigate these failures?


\- database corruption


\- physical destruction of data center



Enumerate the security risks and describe the plans to mitigate these risks?


\- DOS attacks



\- SQL injection attackes



\- account and password security


\-


Don't forget network (dis)connectivity.  I heard that the City
Hall outage the other day was due to a PG&E vault fire, and that
ain't the first time.  Anyway, network connections do drop, so
they need to be identified (e.g., DBI to cloud?), and what if
that happens right in the middle of a <worst-case-scenario>?


I went to a business-continuity seminar a couple of weeks back, you may want to take a look at the slides:


[http://10.250.60.17/citypedia/index.php/Valdez%2C_Samuel_2009-2010_Conference_Seminar_Workshop_Notes#Disaster_Recovery_Planning_Seminar_.2825_Mar_2010.29]





So what?&nbsp; Don't forget about EAS upgrades, PostgreSQL/PostGIS upgrades, Django upgrades, etc., major versions and patches.


Virus scans?&nbsp; Probably more things that elude me at the moment.

what is our Recovery Time Objective? (how soon to be back up and running)
[http://en.wikipedia.org/wiki/Recovery_Time_Objective]


access to the database is more important than access to the cached map data

upon a DC failover, we will have to reseed chache

Can we assume that we are not going to use replication?

If no replication, how much work can we loose? (1 day, 4 hours?, 2 hours?)

Recovery Point Objective (acceptable amount of data loss measured in time)
[http://en.wikipedia.org/wiki/Recovery_point_objective]

monitor disk space