Proceso de copia de seguridad/restauración de la base de datos

Question

El proceso de copia de seguridad y restauración de una gran base de datos o colección de bases de datos en el servidor sql es muy importante para la recuperación de desastres &. Sin embargo, no he encontrado una solución robusta que garantice que todo el proceso sea lo más eficiente posible, 100% confiable y fácil de mantener y configurable entre múltiples servidores.

Los planes de mantenimiento de Microsft no parecen ser suficientes. La mejor solución que he utilizado es una que he creado manualmente, que utiliza muchos trabajos con muchos pasos por base de datos que se ejecutan en el servidor de origen (copia de seguridad) y el servidor de destino (restauración). Los trabajos usan procedimientos almacenados para hacer la copia de seguridad, copiando & restaurando. Esto se ejecuta una vez al día (copia de seguridad/restauración completa) e intradía cada 5 minutos (envío de registro de transacciones).

Aunque mi proceso actual funciona e informa cualquier falla de trabajo por correo electrónico, sé que todo el proceso no es muy confiable y no puede ser mantenido/configurado fácilmente en todos nuestros servidores por un no DBA sin tener un conocimiento profundo de el proceso.

Me gustaría saber si otros tienen este mismo proceso de copia de seguridad/restauración y cómo otros superan este problema.

Answer 1

Estoy haciendo exactamente lo mismo y tengo varios problemas semi regularmente incluso con este proceso.

¿Cómo se maneja la separación entre copiar el archivo desde el servidor A al servidor B y la restauración de la copia de seguridad de transacciones en el servidor B.

De vez en cuando la copia de seguridad de transacción es más grande de lo normal y toma un tiempo más largo copiar. El trabajo de restauración recibe un error del sistema operativo que indica que el archivo está en uso.

Esto no es un gran problema ya que el archivo se aplica automáticamente la próxima vez; sin embargo, sería mejor tener una solución más elegante en general y una que solucione este problema específicamente.

Answer 2

He utilizado un paso similar para mantener las bases de datos de desarrollo/prueba/QA 'sin escalonar' todas las noches para que las usen los desarrolladores y el personal de control de calidad.

La documentación es la clave, si quiere eliminar lo que Scott Hanselman llama 'factor de bus' (es decir, el peligro de que un creador del sistema sea atropellado por un bus y todo empiece a chupar).

Dicho esto, para copias de seguridad de bases de datos normales y planes de recuperación de desastres, he encontrado que los planes de mantenimiento de SQL Server funcionan bastante bien. Siempre y cuando incluya: 1) Documentación decente 2) Pruebas de rutina.

que he descrito algunas de las maneras de ir haciendo que (para cualquier persona dibuja a esta pregunta en busca de un ejemplo de cómo ir sobre la creación de un plan de recuperación de desastres):
SQL Server Backup Best Practices (Free Tutorial/Video)

Answer 3

La parte clave de su pregunta es la capacidad de que la solución de respaldo sea administrada por un no DBA. Cualquier respuesta nativa de SQL Server, como las secuencias de comandos de copia de seguridad, no satisfará esa necesidad, ya que las secuencias de comandos de copia de seguridad requieren conocimiento de T-SQL.

Por eso, debe buscar soluciones de terceros como las mencionadas por Mitch Wheat. Trabajo para Quest (los creadores de LiteSpeed) así que por supuesto que soy parcial con eso, es fácil de mostrar a los que no son DBA. Antes de dejar mi última compañía, tuve una sesión de diez minutos para mostrar a los administradores de sistemas y desarrolladores cómo funcionaba la consola LiteSpeed, y eso fue todo. No han llamado desde entonces.

Otro enfoque es utilizar el mismo software de copia de seguridad que usa el resto de su tienda. TSM, Veritas, Backup Exec y Microsoft DPM tienen agentes de SQL Server que permiten que los administradores de Windows administren el proceso de copia de seguridad con distintos grados de facilidad de uso. Si realmente desea que un administrador no DBA lo administre, esta es probablemente la manera más fácil de hacerlo, aunque sacrifica mucho rendimiento que las herramientas de respaldo específicas de SQL le brindan.