viernes, 7 de junio de 2013

The Master of Disaster. Estrategias para un plan de desastres. 1 de muchos...

Copias de seguridad !! Si la haces 3 veces aparece un personaje de terror tipo Hollywood y se come tus servidores !!!.

No voy a contaros nada nuevo sobre este tema. Suele ser la asignatura pendiente para muchos de nosotros, administradores de redes y sistemas, y se suele confiar en el criterio de cada profesional para establecer los parámetros de los backups.

Mucha gente piensa en copias de seguridad y backup en casos extremos, por ejemplo, una catástrofe natural, un virus potente que infecta equipos y servidores, una caída de un elemento hardware, como pueda ser un servidor... Si te basas en estos términos para establecer tu plan de copias de seguridad, quizás pienses: Yo soy de Murcia, aquí nunca llueve, y en caso de un incendio de la empresa, no pasa nada porque se pierdan dos días de trabajo. Mi servidor es nuevo, y por lo menos va a durar 5 años sin roturas...
Hemos hablado ya en este blog de la diferencia de hacer las cosas, sabiendo o no. A priori puede que a corto plazo los resultados sean parecidos, pero a largo plazo...


La dependencia que se tiene en las empresas de hoy en día con la tecnología hacen que una parada de servicio de una hora, ocasione perdidas importantes para la organización. Debemos estar preparados, en la medida de lo posible, para hacer frente a todas las adversidades conocidas que se nos pueden presentar en en nuestras implantaciones, y así minimizar el impacto sobre el negocio de una caída. Si se rompe la tarjeta de red del servidor, el informático no tiene la culpa. Pero el informático si tiene la culpa de no haber previsto esta cuestión, y tener instalada una segunda tarjeta. El caso intermedio podría ser el contar en almacén con una tarjeta nueva de repuesto, pero esto implicaría perdida de tiempo.

En el mundo de la consultoría, el humo negro de Lost (Perdidos) y demás profesionales no técnicos se ha impuesto la moda de Plan de continuidad de Negocio, donde la parte de sistemas informáticos cuenta con un gran peso. He visto consultores, relacionados con esta materia, realizar guias de mejora, de las típicas checklist, sin tener ni idea de la organización y sus medios.
Con este post no quiero decir que haya que contratar un servicio de este tipo, ni tan siquiera que prepares un plan a modo manual de calidad, con una estructura formal, índice, objeto, alcance, audiencia, cambios de versión etc. Si lo haces así mejor, pero no es la parte que ahora nos toca. Ahora vamos a hablar de las medidas técnicas concretas para garantizar la continuidad de negocio en el ámbito TIC. Si lo quieres formalizar en un documento ofimático, bien, si lo quieres desarrollar como un procedimiento formal dentro de la empresa, bieeeeeen, pero insisto, lo importante es estar preparado.



Entonces, vamos a empezar a pensar en planes de desastres, más que en copias de seguridad, para cubrir la mayor parte del abanico de posibilidades:

Identificación de activos. Esto quizás sea lo más importante. Tener una lista de recursos, bien sean servidores físicos, virtuales, datos, aplicaciones, procesos administrativos,etc es imprescindible. Como vas a proteger lo que no sabes que tienes?. El típico caso de una pequeña aplicación, que se usa los días 5 de febrero solo los años bisiestos... Podrás haber sufrido un percance, haber restaurado datos y servicios como un campeón, que llegaría ese día 5 de febrero, no funcionará el aplicativo y habrás fallado en tu misión. Es interesante realizar unas encuestas a los trabajadores de la organización, sobre todo si llevas poco tiempo en ella, para identificar elementos susceptibles a ser salvaguardados. Hablo de la típica hoja de cálculo con "valiosiiiiiiiiiisima informacion" que tiene el usuario en su Outlook, y que tú no realizas backup de el....

Tolerancia a fallos en servicios de Networking. DHCP, DNS, Active Directory, Remote Services, etc. Son servicios usados en todo momento dentro de nuestras organizaciones, que no requieren de un Backup clásico para restaurar en caso de accidente. Debemos configurar infraestructuras redundantes, como hicimos aquí con el DHCP, para garantizar el correcto funcionamiento de estos servicios 24/7/365.
Sería interesante, dentro de las posibilidades económicas de la organización, realizar estas acciones, no muy costosas, e incluirlas dentro del plan de contingencia de la empresa.

Seguridad física. Importante documentar las medidas de seguridad físicas implementadas en la organización y elaborar un plan de adecuación. Por ejemplo, imaginamos un CPD bien acondicionado, protegido por una sólida puerta, con una llave, que solo los dos responsables de sistemas tienen en su poder. Llega agosto, ocurre un incidente en el que hay que entrar físicamente al CPD, por ejemplo, por un problema con las baterías de los SAI. El responsable de la llave 1 está en Cancúm y el responsable de la llave 2 está a 800 km de la sede central. Parece una tontería? Esto lo podemos extender a seguridad básica de dispositivos como que en un sitio de publica concurrencia, alguien acceda a una zona restringida y robe un portátil. Ese portátil es el que tiene la aplicación monolítica de Nóminas de la empresa de toda la vida...

Restauración. Imaginémos el caso de un servidor de empresa, en el que realizamos copias de seguridad de todos los ficheros, carpetas de datos, configuraciones de aplicaciones y demás. En caso de una "rotura" del Sistema operativo, o lo que viene siendo una metedura de zarpa, no arranca el servidor. Cuanto tiempo nos va a costar instalar un sistema operativo desde cero, y restaurar los datos?

Política de emergencias. Seguimos pensando en casos disparatados, o no tanto. Una caída de servicio en un aplicativo un sábado a las 18:00 PM. Si es una empresa pequeña o mediana, con un solo responsable de sistemas el teléfono está apuntado en todas las mesas y todo el mundo sabe a quien llamar, pero en el caso de organizaciones con más de un técnico hay que dejar constancia de quienes son los encargados de qué cosas, y no llamar siempre al máximo responsable para solucionar un incidente que podría ser considerado de nivel bajo, y otra persona puede resolver. Contar con los teléfonos de los partners y el horario o el SLA es muy importante si necesitamos ayuda externa. En el momento del incidente lo normal es llamar corriendo. Puede ser que el partner no entienda esa actuación como algo definido en un SLA y que llegue en 10 minutos, el Sr. Lobo, resuelva el problema, y cuando llegue la factura el lunes a gerencia tengas MAS problemas que los ocasionados por la caída... Todas estas cosas parecen triviales,  pero merecen la pena sentar a revisarlas, y trabajar sobre ellas.

BACKUP. No nos vamos a olvidar de las copias de seguridad dentro del plan de desastres de la empresa, pero no olvidemos que es una "pata" más de la mesa. Podríamos contestar estas preguntas, para aproximarnos a una estrategia de copias de seguridad adecuada a la organización:

● ¿Qué importante es el papel de un servidor concreto?
 ¿Qué importancia tienen los datos almacenados en el servidor?
 ¿Son los datos únicoso hay varias ubicaciones disponibles?
 ¿Con qué frecuencia cambian los datos?
 ¿Cuánto tiempo dura cada copia de seguridad?
 ¿Con qué rapidez se necesita la recuperacion de datos?
 ¿Cuántos datos históricos no es necesario almacenar?
 ¿Tiene el equipo los medios necesarios para realizar las copias de seguridad?
 ¿Es necesario almacenar las copias de seguridad fuera del sitio?
 ¿Quién será el responsable de realizar copias de seguridad y sobre todo comprobarlas?


Dentro de las copias de seguridad hay que distinguir entre elementos propios del sistema, como pueda ser la base de datos de usuarios, o datos de usuarios, como puedan ser documentos de hoja de cálculo. Hay que preservar ambos tipos de datos en nuestro plan. Si queremos separar esta visión de copias de seguridad, no sería muy útil la utilización de copias del tipo Imagen completa, ya que estas se suelen hacer en momentos de baja actividad, por la noche, y si bien los datos de Active Directory o sistema en un día no cambian mucho, la perdida de granularidad a la hora de restaurar un dato usado con frecuencia por los usuarios daría como resultado pérdidas de información y tiempo.

Otro caso habitual en las organizaciones es el de ficheros abiertos constantemente, con mucha carga de modificaciones, y encima pesados. Si tenemos un MDB de apoyo para el departamento comercial, que está siendo actualizado constantemente, posiblemente tendremos problemas con nuestra copia de seguridad por estar en uso el fichero. Hablamos de copias de seguridad "echas a mano" como pueda ser un Xcopy *.* /v/e/s en un programador de tareas. Para este tipo de escenarios lo mejor es recurrir a Shadow Copy disponible en los sistemas operativos modernos de Microsoft. De esta manera no solo podemos realizar las copias de seguridad, sino que la restauración por alteraciones indeseadas es prácticamente automática.


Puede ser que os  aburra todo esto, porque todos conocéis este aspecto, el de los planes de contingencia. Lleváis años haciendo vuestras copias de seguridad en la unidad de cintas que comprasteis hace 5 años... Has cambiado las cintas? Es importante la rotación de medios de almacenamiento empleados en las copias de seguridad. Cada organización tiene sus características y sobre todo presupuestos, pero si estás escribiendo tus backups en una NAS o en un disco externo conectado a un servidor, compra alguno más e intercala su uso para garantizar que cuando lo necesites, funcionará. Hay soluciones NAS compatibles con tráfico SMB y NFS con estructuras de disco en RAID por menos de 200€ ( D-Link) que para pequeñas y medianas empresas puede servir como un medio de almacenamiento más para nuestras copias de seguridad. Si quereís aprovechar un sistema antiguo, e instalar un servidor Linux con FreeNas para aprovechar el almacenamiento disponible, no es mala opción, y sobre todo barata. Aquí tienes como iniciarte con FreeNas.

Después de esta introducción a los planes de desastres, en próximos artículos hablaré de copias de seguridad con el servicio de backups de Windows Server 2012, el típico documento de recuperación de Active Directory mediante los FSMO y Ntdsutil, y más cosas que no os podéis perder !!!.

Como siempre, espero que os guste y gracias por leerme.