¿Qué pasa si un tornado atraviesa SU centro de datos?

Durante el pasado fin de semana tuvimos tormentas severas aquí en Virginia y, por supuesto, la crisis en Japón es un recordatorio de que las cosas pueden salir mal en un instante. Una pregunta que me hago "¿Qué pasa si un tornado golpea mi centro de datos, estoy preparado?"

Tengo excelentes sistemas de copia de seguridad "en mi rack", incluida una copia de seguridad en cinta. Debido a que el centro de datos no está cerca, no es posible mover cintas fuera del sitio. Lo que me gustaría encontrar o crear es un sistema que, en un horario, pueda hacer copias de seguridad de elementos críticos como sitios web, bases de datos y copiarlos de forma remota, es decir, mi servidor en casa. Tengo FIOS con servicio de 35 mbit, así que tengo banda ancha, lo que necesito es el "sistema" para hacer esto. Soy un programador, por lo que podría crear algo que la información de FTP no funciona en un horario, pero tengo curiosidad por saber si hay algo que llene esta necesidad de copia de seguridad remota ahora. Mis servidores SQL están respaldados en matrices de almacenamiento, podría reducir esas copias de seguridad o incluso programar mi servidor SQL aquí para que se sincronice con los servidores de producción en un horario. Yo uso Windows Server 2008 R2 y SQL Server 2008 R2.

¿Qué recomiendan todos para la estrategia fuera del sitio en una crisis como un desastre natural que noquea nuestro centro de datos? ¿Estas preparado? Espero que otros se hagan esta pregunta y aprendan de estos desastres naturales que hemos estado viendo con demasiada frecuencia.

Sus opciones deben ser dictadas por sus acuerdos de nivel de servicio con sus clientes y limitadas por su presupuesto.

Como mínimo, debe tener copias de seguridad externas de todos los datos críticos. Es decir, cualquier dato que no pueda volver a crear desde cero debe almacenarse en otro lugar. Las copias de seguridad sin conexión son mejores: las copias de seguridad en línea o la replicación pueden ayudar cuando ocurre un tornado, pero ¿qué sucede si un empleado enojado deja caer una base de datos o destruye un sistema de archivos?

Desde una línea base de copias de seguridad fuera de línea, puede comenzar a explorar opciones que acelerarán la recuperación a cambio de un costo más alto. Aquí hay una gran cantidad de opciones que van desde un único host para copias de seguridad en línea que usted describe hasta entornos completamente replicados con replicación de datos síncrona que se ejecuta activa (-activa) + para un tiempo de inactividad casi cero.

Descubrirá que la recuperación desde cero es mucho más fácil si separa sus datos de su infraestructura de la mejor manera posible. Por ejemplo, la recuperación desde cero será mucho, mucho más rápida si implementa utilizando sistemas como títeres o chef en lugar de hacerlo a mano. Rehacer todo el trabajo que ha realizado para construir sus sistemas será mucho más rápido si puede automatizar tanto como sea posible. Mantener los datos separados también reduce la cantidad de datos que necesita hacer una copia de seguridad: no genere gigabytes de sistema operativo si solo necesita unos pocos megas de configuraciones del sistema y datos de aplicaciones.

Las opciones pueden ser bastante costosas, por lo que debe determinar cuánto está dispuesto a gastar su empresa en recuperación de desastres y cuánto tiempo de inactividad pueden tolerar sus clientes. Elimine las opciones que son demasiado caras o lentas para sus clientes.

Una vez que elija una solución de recuperación ante desastres, asegúrese de practicarla. Recomendaría al menos una vez al año o cada vez que cambie su arquitectura, lo que ocurra con más frecuencia.

Business Continuity va mucho más allá de asegurarse de tener acceso a copias de seguridad legibles. Pero al limitar el alcance de la respuesta a eso, en última instancia, solo será viable cuando el ancho de banda de extremo a extremo desde el centro de datos hasta la ubicación de la copia de seguridad sea lo suficientemente grande como para manejar el volumen de cambios de datos.

Cuando se habla de un centro de datos, entonces, para la mayoría de las personas, ese es Gigaytes de datos por semana.

IME, incluso a pequeña escala, la mejor solución es una operación distribuida (o reflejada). Planifíquelo bien y debería haber una pequeña sobrecarga de costos en comparación con un solo centro de datos.

Pero si debe copiar todos los datos en una ubicación en espera o incluso en un almacenamiento remoto, entonces

1) no use FTP: es la forma incorrecta de hacerlo por muchas razones

2) para archivos genéricos, use algo como rsync que está optimizado para este propósito

3) para las bases de datos, mire las herramientas disponibles específicamente para su DBMS: la estructura del archivo puede cambiar enormemente sin que los datos cambien mucho. Nota: esto incluye el registro de MSWindows y los datos de MSAD.

Tenemos una VPN desde nuestra oficina hasta nuestro centro de datos externo. En el centro de datos externo, tenemos un servidor que tiene una red compartida montada que configuramos como destino en nuestro software de respaldo (ejecutamos Symantec BackupExec), es decir, \ OFFSITEDATACENTER \ OFFSITESTORAGE

Luego hacemos - una copia de seguridad completa durante el fin de semana en ese lugar
- un incremento cada noche

Además de nuestras copias de seguridad normales "en el sitio"

También ejecutamos VMWare VDR para tomar imágenes de nuestros servidores principales cada semana que se colocan en un disco SATA de 2TB encriptado usando FreeOTFE, que me llevo a casa cada semana.

Tenemos varios centros de datos activos / activos o activos / semiactivos separados con> 50 millas entre ellos, diferentes proveedores de energía, seguridad, enlaces mallados de 10 GBps enrutados de manera diversa entre ellos, y también enviamos nuestros discos de respaldo entre ellos. Esto hace por nosotros.

Los detalles del manejo de un cierto esquema de respaldo han sido cubiertos hasta la saciedad aquí y en otros lugares. Voy a abordar esta pregunta desde un punto de vista de más alto nivel de las pautas generales para ayudarlo a decidir cómo abordar la recuperación ante desastres. He estado en bastantes situaciones en las que la planificación tenía que estar en su lugar en caso de que el centro de datos se convirtiera en un cráter humeante. Afortunadamente, solo tuvimos que usarlo una vez. Las cosas más importantes para recordar son:

1) No pierda su tiempo tratando de diseñar demasiado y haga que todo falle con una precisión de <1 ms si no es necesario. Un fracaso completo de esa magnitud generalmente excusará unas pocas horas de recuperación.

2) Como corolario del n. ° 1, asegúrese de que las expectativas estén determinadas y codificadas de manera realista en una política en alguna parte. Tener un objetivo establecido que alcanzar en cuanto al tiempo de recuperación es importante, ya que puede dedicar tiempo ilimitado y la obtención de fondos es "aún mejor".

3) Prioriza tus sistemas. El plan de recuperación debe construirse alrededor de una lista definitiva de la importancia de todos y cada uno de los sistemas. No te pierdas las cosas obvias, como obtener DNS y AD antes que el resto de los servidores de Windows.

4) Si no está fuera del sitio Y fuera de la red, es solo una copia. Esto va en línea con otra cosa clave para recordar: RAID no es un plan de respaldo.

5) Prueba, prueba, PRUEBA! Pruebe cada centímetro de su plan que pueda. Si puede obtener un fin de semana libre por un período de mantenimiento, desconecte el enlace ascendente y / o la energía del edificio y pruebe el tiempo de reacción y la efectividad de su equipo. Un plan de recuperación ante desastres que nunca se prueba es solo una ilusión.