En esta sesión explicaremos los modelos de copias y recuperación; hincapié en copias de FG, y archivos y cómo recuperarlos (combinar con volúmenes de sólo lectura); finalizar con intro a log shipping para DR en servidor remoto.
Presentación realizada en el SolidQ Summit por: Luis José Morán Cuenca
[slideshare id=62392555&doc=rel-300luismorancopiasdeseguridadyrecuperacindedesastres-160525154241=495&w=595]1. #SQSummit Copias de Seguridad y Recuperación de Desastres Luis José Morán Cuenca lmoran@solidq.com Data Platform Architect
2. EN CUMPLIMIENTO CON LA LEY 15/1999 DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL, PONEMOS EN TU CONOCIMIENTO QUE ESTE EVENTO VA A SER GRABADO · Dichas grabaciones serán utilizadas por SolidQ, bien para uso interno o bien para la creación de material de marketing con el fin de promocionar nuestra marca.
3. Copias de Seguridad y Recuperación ante Desastres • Introducción • FailOver Log Shipping • Estrategia de Recuperación y Backups • Backups / Restore • Dispositivos de Copia • Tipos Backup • Modos Recuperación • Tipos de Restores • Solución Alternativa a los Backups Parciales • Problemas Más Habituales en Backups • Problemas Más Habituales en Restauraciones
4. FailOver Log Shipping • Consiste en realizar backups del log y restaurarlos en otras instancias de la misma versión o superior • Pasos por cada BBDD que este en LS • Intentar hacer backup del log de transacciones de la instancia estropeada • Aplicar los logs de transacciones pendientes + el tail log • Recuperar la bbdd • Revisar los logins y migrar los que no existan • Revisar los jobs y migrar los que no existan • Cambiar las cadenas de conexión para que apunten al nuevo servidor o si se trabaja con alias DNS cambiar y el alias • Creación y activación de politicas de backup
5. La Suerte ….
6. Estrategia de Recuperación y Backups • Estrategia de Recuperación • El negocio debe definir el tiempo máximo en el que debe estar recuperado el sistema • Estrategia de Recuperación • Log Shipping • Replicación Transaccional • Mirroring • Cluster SQL Server • Grupos de Disponibilidad Always On
7. Dispositivos de Copia • Local • Debe ser específico para esta tarea • No debe contener o ser una partición de otro que contenga: • Ficheros de datos de SQL Server • Ficheros de log de SQL Server • Limitación el espacio • Ventaja • Velocidad de restore (no viaja por red) • Depende del tipo de disco Disco/s 7© 2016 SolidQ
8. Dispositivos de Copia • En otro equipo de la red • Puede ser un disco o varios, se puede llegar a evitar la limitación de espacio • No debe contener o ser una partición de otro que contenga: • Ficheros de datos de SQL Server • Ficheros de log de SQL Server • Problema potencial, los datos viajan por la red: • Puede llegar ralentizar la red con backups de bbdds muy grandes • Si se modifica por error un dato en el transporte puede que el backup no nos sirva • En el restore puede pasar lo mismo Disco/s 8© 2016 SolidQ
9. Dispositivos de Copia • Desventaja es un dispositivo lento tanto para el backup como para el restore • Ventaja podemos almacenar muchos datos • No tiene porque afectar a la red si esta bien configurado Cintas 9© 2016 SolidQ
10. Dispositivos de Copia • Espacio ilimitado • La velocidad de backup y restore depende de las comunicaciones • Puede configurarse georeplicaciones como una segunda medida de seguridad • Factor importante el tipo de información a almacenar tenemos que verificar si el proveedor cumple con nuestra legislación nacional en materia de protección de datos Azure 10© 2016 SolidQ
11. Tipos de Backup Sintaxis
12. Tipos de Backup Full Filegroups Files (Datos + Logs ) Recuperación Completa
13. Tipos de Backup Diferenciales Páginas (DCM) Diferencial Changed Map Desde último backup full Solo se necesita restaurar uno
14. Tipos de Backup • Ventaja • Disminuye el tiempo recuperación solo se restaura aquello dañado sin restaurar el resto • Puede servir como base para backups parciales • Desventaja • Añade complejidad administrativa mantener el rastro del conjunto de backups para poder restaurar • El conjunto de estos backups puede superar el tamaño de un backup full • Un error en una de las copias invalida la posibilidad de restauración Archivos o Filegroups
15. Tipos de Backup • Modo Recuperación Full • Las copias contienen info del log de transacciones • Se deben hacer copias del log de transacciones con independencia de las de files/filegroups • Modo Recuperación Simple • La copia debe contener a todos los files/filegroups para que estén coherentes a ese momento del tiempo ya que no incorpora info del log de transacciones • Adecuados para Filegroups de Solo Lectura Archivos o Filegroups
16. Tipos de Backup • Diseñados para todos los modos recuperación • Su uso suele ser en bbdds grandes con modelo recuperación simple con mas de un filegroup • Pueden ser diferenciales • Son el complemento de los backups de FG Parciales
17. Tipos de Backup • Útiles para filegroups de lectura / escritura • https://msdn.microsoft.com/es-es/library/ms191539(v=sql.120).aspx Parciales
18. Tipos de Backup • Recuperar el sistema, se escribe en disco • Aplica a modo recuperación Full y Bulk Logged • El backup del log sirve para limpiar el log • Se queda hueco • No tiene porque autocrecer más • No sirve si no hay parte inactiva Log De Transacciones
19. Modos de Recuperación • Se escriben todas las operaciones que se realizan en SQL Server pero se debe realizar backup del log de transacciones periódicamente para limpiar la parte inactiva (transacciones que han terminado bien con un commit o un rollback) • En caso de error se puede recuperar la base de datos en un momento determinado Modo de Recuperación Full 19© 2016 SolidQ
20. Tipos de Backup Backup del log Comportamiento en Modo de Recuperación Full T1 T2 LOG TRANSACCIONES T1 T2 BACKUP DEL LOG DE TRANSACCIONES
21. Modos de Recuperación • Optimizado para operaciones masivas, reduce el espacio de estas operaciones en el log de transacciones y mejora rendimiento del proceso • Se pueden realizar copias de seguridad para limpiar la parte inactiva pero no puede recuperar hasta un momento determinado • Contiene todas las entradas del log y las paginas de datos afectadas • El backup puede ser muy grande • Probarlo, hay casos donde no hay mejora rdto Modo de Recuperación Bulk Logged 21© 2016 SolidQ
22. Tipos de Backup Backup del log Comportamiento en Modo de Recuperación Bulk Logged LOG TRANSACCIONES T1 T2 PAG 3124 PAG 6678 T1 T2 BACKUP DEL LOG DE TRANSACCIONES PAG 6678PAG 3124
23. Modos de Recuperación • Se escriben todas las operaciones que se realizan en SQL Server como en el modelo completo pero no se permiten copias de seguridad ya que SQL Server automáticamente se limpia la parte inactiva del log de transacciones • Al limpiarse la parte inactiva no se puede recuperar hasta un momento dado ya que pueden faltar operaciones Modo de Recuperación Simple 23© 2016 SolidQ
24. Tipos de Backup Backup del log Comportamiento en Modo de Recuperación Simple LOG TRANSACCIONES T1 T2
25. Restores • Modo Recuperación Completa / Masiva / Simple • Problema no se puede trabajar con la bbdd aunque haya parte que no se ha estropeado Habitual
26. Restores • Derivado de los backup de FG o parciales • Objetivo restaurar uno o varios files sin necesidad de restaurar la bbdd entera • La base siempre es un full • Se puede hacer: • BBDD Offline • BBDD Online • Todos los fg online excepto el fg/file afectado • Solo Ediciones Enterprise • En el modelo simple solo FG de lectura Atípico
27. Restores Atípico Fg RW Full / Bulk Logged Aplicar Log Fg R Simple NO Aplicar Log
28. Solución Alternativa A Backups Parciales / FG • Mover los datos historicos (Filegroups Solo Lectura) a otra BBDD • Deframentar índices • Recalcular estadísticas • Poner la BBDD en Modo Solo Lectura hasta nueva carga • Hacer un único backup full • Dejar los Filegroups RW en la BBDD • Aplicar el modo Full si es posible • Backups Periódicos
29. Restores Página • Más rápido que restaurar un fichero • Detectado por CheckDb • Suspect Pages • Aplica a modo Full y Bulk Logged • Grupos de Archivos RW • Puede hacerse • Offline • Online • Enterprise • FG Online
30. Problemas Más Habituales en Backups 1. No se hace backup de las bbdd 2. No se hace backup del log de transacciones 1. Tamaño de log varias veces superior a los datos 3. Rotura de secuencia (Log shipping) 1. Cambio en modo recuperacion full a simple 4. Disco backups en mal estado (en origen o destino) 5. Backup corrupto (Si viaja por la red perdida paquetes) 6. Entropía, no coindicir Backups con periodos de gran actividad
31. Problemas Más Habituales en Restauraciones 1. Restauraciones lentas (migraciones) 2. Borrado backups y/o ficheros de SQL Server 3. Perder clave Backups encriptados 4. Romper secuencia copias 1. Poner los backups en otro lado 5. Ubicación copias –> AO (depende de la versión) 6. Desconocer los mecaniscos de backup y restauración –> Intentar restaurar una bbdd no querer restaurar un filegroup y quitar objetos
32. También puedes preguntar tus dudas con el hashtag #SQSummit en Twitter ADAPTIVE BI FRAMEWORK Te ayudaremos a mejorar la velocidad de desarrollo de tu plataforma de analítica de negocio basada en nuestra experiencia: •Diseña antes de construir •Automatización de procesos por ETL •Servicios de mentoring para ayudarte a conseguir mejores prácticas para la construcción de procesos específicos y plataformas de analítica de negocio •Muy fácil de mantener SOLIDQ FLEX SERVICES Con SolidQ Flex Services evitarás sustos, consiguiendo que tus sistemas sean estables. Desde una solución sencilla de monitorización, hasta un servicio de atención de incidencias 24/7, mantenimiento proactivo, resolución de problemas y línea de soporte. Todo con un coste fijo mensual… y tú dedica el tiempo a las cosas importantes.
2 comments
Exelente explicacion.
Muchisimas gracias, muy didactico y util.
Tengo una simple duda que parece medio tonta.
Domingo 01:00 AM —> Full Backup
Cada dia 02:00 AM –> Diferencial
Transaction Log—-> Cada 6 horas todos los dias a partir de las 2:00 AM
Si el desastre ocurre el miercoles a las 6 de la tarde, mi restauracion seria:
1-Full Backup
2-La diferencial del miercoles
3-Todos los Logs que tenga a partir del diferencial del miercoles hasta el momento del desastre ? ( incluido el tail log si se puede )
O sea, mi duda es si los logs a restaurar son a partir de la ultima diferencial que restaure.
Muchas gracias
Si, es correcto, así es. Full del domingo + ultimo diferencial + logs de transacciones y tail log hasta llegar al momento más próximo al error.
No obstante si haces backup full los domingos deduzco que es una bbdd grande, has pensado en poner alta disponibilidad (Cluster, Grupos de disponibilidad AO, Log Shipping) ?. Se tardará bastante en restaurar y encima como un archivo de backup esté mal podrás perder información. Gracias!