¿Mejores prácticas para la verificación de respaldo?

Es una situación común, cuando el administrador crea un sistema de respaldo automático y lo olvida. Solo después de que un sistema falla los avisos del administrador, ese sistema de copia de seguridad se ha roto antes o las copias de seguridad no se pueden restaurar debido a alguna falla y no tiene una copia de seguridad actual para restaurar ... ¿Cuáles son las mejores prácticas para evitar tales situaciones?

Ejecute simulacros de incendio ... cada dos meses es una buena idea decir que el sistema XYZ está inactivo ... luego, en realidad, siga los pasos para volver a conectarlo a una nueva VM, etc. Mantiene las cosas honestas y lo ayuda a atrapar errores

modo de caja de jabón: ON

Diría que es tan simple que las copias de seguridad que no se prueban regularmente no valen nada.

En mi trabajo anterior, teníamos una política de que todos los sistemas (producción, prueba, monitoreo de desarrollo, etc.) deberían ser restaurados cada 6 meses.

Este también era el trabajo del administrador más joven para que la documentación estuviera actualizada. Junior se define por la cantidad de trabajo que él / ella tuvo en el sistema específico, en algún momento (muy a menudo en realidad) fue el "gerente del grupo" quien lo hizo

Teníamos un hardware especial dedicado a esto (una caja Intel y una caja IBM / AIX) que tenía especificaciones bajas para todo menos el espacio en disco, ya que no necesitábamos ejecutar nada real en el host restaurado.

Mucho trabajo las primeras rondas, pero nos llevó a simplificar el proceso de restauración, que es la parte importante de la copia de seguridad.

Como parece que se refiere al hecho de que el administrador no se da cuenta de que el trabajo de copia de seguridad "se rompe", y no tanto que una copia de seguridad que funciona no funcionó correctamente, sugeriría crear algún tipo de secuencias de comandos de monitoreo alrededor de las copias de seguridad.

Al crear una solución de respaldo local, haría algo como esto:

• Cree un script para hacer una copia de seguridad de sus datos.
• Realice la restauración de prueba para asegurarse de que el script funciona correctamente.
• En el script, o por algún otro medio, implemente una forma de rastrear el estado de las copias de seguridad (éxito, falla, ejecución, no ejecución).
• Tener ese estado de seguimiento monitoreado (correo electrónico, base de datos, algo)

Una vez hecho todo eso, deberías estar bien. Una cosa adicional para hacer sería realizar restauraciones de prueba regulares. Si tiene hardware adicional para donar a la causa que es.

Cuando trabajo, tenemos un sitio cálido, una vez al mes elegimos al azar un sistema o base de datos, vamos a nuestro sitio cálido y realizamos un ejercicio de restauración de prueba en metal desnudo para garantizar la capacidad de recuperar nuestros datos.

Honestamente, si sus datos son muy importantes para usted, le conviene invertir en algún software para administrar sus copias de seguridad. Hay cientos de productos disponibles para esto, desde los más baratos y simples, hasta la clase empresarial.

Si confía en un conjunto de secuencias de comandos escritas a mano que se ejecutan en el crontab para las copias de seguridad de sus empresas, tarde o temprano es probable que se queme.

Tenemos versiones de referencia del 60% de nuestros sistemas de 'Producción', los usamos para la prueba final de los cambios, restauramos las copias de seguridad de 'Producción' en estos sistemas: prueba la copia de seguridad y garantiza que ambos entornos estén en sintonía .

Un enfoque es ejecutar un trabajo de "recuperación" para ejecutarlo periódicamente, por ejemplo, uno que tome un archivo de texto específico de la copia de seguridad más reciente y le envíe por correo electrónico su contenido. Si es posible, esto debería, al menos a veces, hacerse con un cuadro diferente al que creó o realizó una copia de seguridad de los datos, solo para asegurarse de que funcionará si necesita hacerlo. La ventaja es que puede estar seguro de que sus mecanismos de cifrado / descifrado, compresión y almacenamiento están funcionando.

Esto es un poco más complicado para las copias de seguridad especializadas, como los servidores de correo electrónico y de bases de datos, aunque realizar algún tipo de recuperación a pequeña escala desde una pequeña base de datos o una copia de seguridad de buzón de correo de nivel de ladrillo y verificar el contenido es ciertamente posible, solo un poco más complicado.

Este enfoque tampoco debería reemplazar una restauración completa periódica para garantizar que pueda recuperar datos en caso de una emergencia; solo le permite tener un poco más de confianza en la integridad de su trabajo de copia de seguridad diario.

Al realizar la restauración de prueba, no me siento cómodo en el punto "esto se ve bien, los archivos se restauran, parece que no falta ningún archivo, incluso los tamaños coinciden", o en el punto "esto se ve bien, comencé mi aplicación. .. no se bloquea, muestra algunos datos decentes ".

Quiero restaurar el servidor / clúster desde cero, y luego usarlo realmente para la producción . No por un minuto, no por una hora, sino permanentemente . Si afirma que su restauración fue exitosa, entonces no hay absolutamente ninguna razón para no comenzar una producción. Este no es un sistema "sucio", que debería ser olvidado. Este es el sistema que enfrentará después de un desastre real. Entonces, si pasa la etapa "se ve bien", vive con ella. Respaldarlo la noche siguiente. Olvídate del original. Probablemente va a descubrir algunos problemas técnicos que utilizan este enfoque, y se le forzada a fijar todos ellos . La próxima restauración del mismo sistema tiene una posibilidad decente de ser 100% exitosa.

Esto incluye su software y servidor de respaldo. Sí, también necesitas restaurarlos.

¿No tiene presupuesto para comprar hardware dedicado para restaurar?

• Señale que absolutamente necesita un presupuesto. En cada ocasión, recuerde a los tomadores de decisiones que todavía no se ha realizado una prueba de restauración válida. (Y sí, reúna la evidencia para cubrir su trasero. Mundo duro).
• En la mayoría de las organizaciones, ocasionalmente existe una necesidad comercial de migrar un sistema a otro hardware, así que aproveche la oportunidad. Elija siempre el método "restaurar desde copia de seguridad" para la migración, pretendiendo que acaba de perder el hardware original. Sí, significa más tiempo de inactividad, lo siento. Al menos tendrá la confianza de que su copia de seguridad es útil.
• ¿No hay migración? Tal vez pueda pedir prestado algo de hardware durante dos semanas y realizar dos pruebas de restauración (restaurar al hardware prestado, esperar más de una semana, restaurar del prestado al original, vivir con él). Por lo general, si hay un nuevo hardware comprado para algún sistema nuevo y organiza las cosas correctamente, puede pedirlo prestado fácilmente al ofrecer probarlo exhaustivamente durante dos semanas. Si el nuevo hardware no es 100% idéntico al anterior, su prueba será aún mejor. ¿Cómo sabe si obtiene un hardware idéntico en caso de desastre real?
• ¿Algún sistema nuevo está siendo implementado por usted en este momento? ¿Puedes probar la restauración ahora mismo? No use hardware adicional, simplemente sobrescriba el nuevo sistema ya que tiene nuevos conocimientos sobre cómo volver a implementarlo rápidamente. Esto funciona si aún no tiene datos significativos. Nuevamente, vaya a producción en la versión restaurada, no en la versión recién reinstalada.

1. Simulacros de incendio.
2. Una política para probar todas las copias de seguridad cada 6 meses es una muy buena idea
3. Cuando se trata de pruebas, debe mirar cada aplicación o sistema de su copia de seguridad. Idealmente, lo que constituye una copia de seguridad "exitosa" o "recuperable" debe figurar en la Descripción del servicio o SOP (documentación operativa) para su copia de seguridad, junto con otros detalles como el tiempo de retención, bladibla.

Probablemente encontrará que algunos tipos de copias de seguridad pueden ser fácilmente restaurados y probados por scripts (como bases de datos) mientras que otros necesitan alguna entrada manual (restauración de Active Directory). Automatice todo lo que pueda de esto, asegúrese de que exista algún tipo de informe y asegúrese de que "alguien" realice las pruebas manuales a intervalos regulares también. Un entorno aislado (copia reducida de prod) facilitará la realización de pruebas de restauración.

Si bien no probamos las copias de seguridad, tenemos el componente centralizado de verificación e informes de copias de seguridad en el sistema que desarrollamos BackupRadar.com. Siéntase libre de verificarlo para ver si ayuda con ese componente. Adjunta una copia de los correos electrónicos de éxito / error a la política de respaldo y también adjuntará capturas de pantalla si su software de respaldo también puede enviarlos.

Gracias patricio

Asegúrese de que la actividad de copia de seguridad esté registrada, luego escriba algo (en perl, por supuesto) que analice los registros en busca de fallas, elimínelo y envíelo como un correo electrónico diario.