Cliffhanger: Las copias de seguridad están bien ... aquí ... ¿verdad?

En mi trabajo, las copias de seguridad tienen una prioridad sorprendentemente baja. La estrategia de copia de seguridad se implementó hace un tiempo, y desde entonces se supone que las copias de seguridad están bien. Si le preguntas a los administradores del sistema, te dirán que todo está respaldado.

Pero luego, cuando solicita una copia de seguridad ESPECÍFICA, la mitad del tiempo no están allí:

• El disco se llenó
• La cinta falló
• Parece que alguien deshabilitó el trabajo de respaldo
• La conexión de red tuvo tiempo de inactividad
• Pedimos ese disco hace años, pero las finanzas no han aprobado la orden de compra.
• Los archivos están corruptos
• El archivo contiene una base de datos incorrecta
• Solo copias de seguridad del registro de transacciones (inútil sin una completa)

Hace unas semanas, el desastre se acercó mucho cuando uno de los servidores perdió demasiados discos de incursión. Afortunadamente, un disco fue lo suficientemente amable como para copiar los datos, si lo intentó muchas veces.

Pero incluso después de ese desastre cercano, parece que no puedo convencer a los administradores de sistemas para que mejoren la situación. Así que me pregunto, ¿algún consejo para abrir los ojos de las personas? Me parece que estamos caminando por el borde de un acantilado.

Siempre tienes que arreglar estas cosas desde arriba.

¿La estrategia de respaldo actual está respaldada y entendida por la administración? Si no, es inútil.

La gerencia ejecutiva necesita conocer los problemas y los riesgos involucrados (¿perder datos financieros que necesita obtener legalmente para sobrevivir o datos de clientes que han tardado años en recopilarse?) Y sopesar eso al decidir sobre acciones o al decidir dejar que alguien (como tú) tome medidas.

Si no puede llegar a la administración, intente con los controladores comerciales u otras posiciones financieras donde la recuperación de datos y su integridad es de gran importancia para los informes de la compañía. Ellos a su vez pueden "iniciar la tormenta" si es necesario ...

¿Dónde empezar? Esto es un desastre esperando a suceder. Una función de trabajo principal de Sysadmins es garantizar que los datos estén respaldados y sean recuperables. Todo lo demás es secundario. No si es no pero es.

Aquí hay algunas cosas que puede hacer:

1. Rastree los KPI para las restauraciones. Debería ser posible producir un informe que muestre cuántas solicitudes de restauración han tenido éxito. Cualquier cosa inferior al 100% debe investigarse a fondo. La gerencia ama los informes y esta es una prueba contundente.

2. Debe haber procedimientos documentados para todas las operaciones de copia de seguridad y restauración, incluidos todos los sistemas y su estrategia de copia de seguridad, rotaciones de cinta, programaciones, rutas de escalado, restauraciones de prueba, etc. Solicite verlas.

3. Hable con el gerente de los administradores del sistema y exprese sus inquietudes. Vaya armado con pruebas de que las restauraciones no funcionan. Si no hay alegría ir más alto.

En serio, levanta un alboroto. Cosas como esta pueden destruir una empresa.

Proponer (como mínimo) pruebas anuales de recuperación de desastres. El trabajo requerido para ejecutar con éxito la prueba debe revelar las deficiencias.

Donde trabajo, tenemos un departamento de TI realmente bueno, todos los años se reúnen desde todas las oficinas de Europa y tienen un 'festival de restauración' en servidores alquilados en un centro de datos, simulando efectivamente lo que sucedería si el personal llegara a trabajar un día y encontrara el La oficina se había incendiado durante la noche.

Involucre al gran jefe, recuérdele que si ocurriera un desastre, se quedaría sin un bono ese año (¡o peor!) Y entonces tal vez sería prudente organizar un ejercicio similar de recuperación ante desastres. No debería tomar mucho tiempo o costar mucho: los administradores son enviados con sus cintas de copia de seguridad externas y se les dice que traigan un entorno de oficina idéntico a ellos.

Luego, siéntese y vea cómo mejora la TI: una vez que la gerencia se dé cuenta de que los datos de la compañía están peligrosamente cerca de perderse permanentemente, se dispararán chispas (de los cohetes que se colocarán estratégicamente en dichos administradores)

Es fácil culpar a los administradores, sin embargo, Oskar tiene razón: estas cosas se manejan desde la parte superior. Si la administración no gasta el dinero para hacer que las copias de seguridad sean una prioridad, entonces los administradores de sistemas generalmente no tienen suerte y hacen lo mejor que pueden con los recursos que tienen.

La clave, si usted es uno de esos administradores desafortunados, y he estado en este barco por algunos compromisos con los clientes, es que se asegure de que la gestión se informe, repetidamente y de manera confirmable en papel, que esto es un riesgo para el negocio

Mi estrategia es martillar constantemente los problemas. Si haces eso, a veces los problemas se solucionarán, pero es sobre todo para que quienquiera que informe no pueda esconderse detrás de la excusa "Nunca fui informado". Como consultor, generalmente puedo ir uno mejor. Puedo hacer que mis jefes informen a la alta gerencia más que puedo que hay una vulnerabilidad. Esto extiende la culpa, o al menos la enfoca a un nivel más alto que yo.

Al mismo tiempo, debe ser inventivo y trabajar duro para minimizar los riesgos con los recursos que el cliente pueda proporcionar.

Si bien en algunos casos los administradores pueden ser culpables, la administración siempre es responsable: ya sea por conocer el riesgo y no hacer lo suficiente para mitigarlo, o contratar a personas que no los alertan sobre estos riesgos.

Soy responsable de unos 200 servidores repartidos por el noroeste del Reino Unido, y esto obviamente es demasiado para verificarlo manualmente.

Configuro la copia de seguridad para que, al finalizar, ejecute un script (VBScript) que revise el registro de la copia de seguridad, determine si la copia de seguridad funcionó o no y escriba un registro en una base de datos central con el resultado de la copia de seguridad. Luego, en la oficina central, ejecuto un script que consulta esta base de datos y me presenta una lista de sitios donde la copia de seguridad informó un error o no hubo un informe del sitio.

El resultado final es que cuando me siento en mi escritorio tengo una lista de todos los sitios donde necesito verificar la copia de seguridad.

El punto de todo esto es que la suposición predeterminada es que la copia de seguridad falló, y se considera que la copia de seguridad funcionó solo si mi VBScript no detectó errores y escribió esta conclusión en mi base de datos. Esto asegura que las fallas de la copia de seguridad no pasen desapercibidas.

Algunos de los servidores usan Backup Exec, algunos NTBackup y algunos simplemente copian sus archivos a otro servidor a través de la red. No importa qué tipo de copia de seguridad hagan los servidores, ya que es fácil modificar mi VBScript para verificar si hay errores. Mi script es bastante básico, simplemente abre el informe de respaldo como un archivo de texto y greps para frases como "error al montar", "cinta llena", "error de CRC", etc. Estoy seguro de que un programador profesional haría Un trabajo más elegante. Sin embargo, todo es simple y robusto, y es proactivo en el sentido de que veo el informe de falla de la copia de seguridad si quiero o no y solo no notaría un error si conscientemente decidiera ignorar el informe.

JR

PS 99% de las fallas de respaldo se deben a que los usuarios olvidaron cambiar la cinta de respaldo. ¿No te encantan los lusers :-)

Una copia de seguridad que no se prueba no es una copia de seguridad.