¿Tiene usted una copia de respaldo valida disponible? (Corrupción)
Por Luis Ramirez – Revisado por Ivanov Cepeda
Una parte considerable de los casos que recibimos en soporte están relacionados con corrupción de base de datos. Y la primera pregunta que hacemos usualmente es ¿Tiene usted una copia de respaldo valida disponible? Esto obedece a que, acorde con nuestros procedimientos y mejores prácticas en soporte, es el único recurso adecuado que garantiza que la base de datos quede en modo consistente.
Los servicios de Soporte de Microsoft, desafortunadmanete, no se especializan en la recuperación de datos, en caso de no tener una copia de respaldo, de requerirse asistencia, lo que nosotros en Soporte Premier podemos hacer es lo que se denomina un “Mejor Esfuerzo” (Best effort), y procederemos a revisar hasta cierto punto comercialmente razonable, el tipo de corrupción para ofrecer opciones, sin ser garantía la recuperación de datos, y donde al final pudiera ser que la única solución será restaurar de una copia de respaldo valida conocida.
Adicionalmente al checkdb, Microsoft no cuenta con herramientas adicionales para casos de corrupción de datos, si esta herramienta no resuelve el problema (suponiendo corrupción de los archivos de datos) la siguiente alternativa serán las compañías de terceros especialistas en recuperación de datos.
Lo mejor en estos casos es prevenir llegar a esta situación, para lo cual se recomienda:
- Revisar la política de “recuperación de desastres”. Periódicamente validando que los respaldos se estén llevando a cabo y los datos sean consistentes (ANTES Y DESPUES de un respaldo). Hemos visto muchos casos donde se está respaldando una base de datos corrupta desde hace tiempo o donde el archivo de respaldo que se quiere usar se corrompió, extravió, o no se llevó a cabo porque la tarea estaba fallando.
- Monitorear el estado del servidor por problemas de plataforma (disco, redes, memoria) y no esperar a que la corrupción aparezca. Se ha visto que la información se corrompió un tiempo atrás pero no es hasta que se accede a los datos que el error es reportado.
- Hay que tomar en cuenta que el 95% de los casos de corrupción son debido a problemas con la plataforma siendo la causa más común un controlador de terceros o un BUG de firmware, seguido por falla de hardware típicamente disco, controlador, CPU o módulo de memoria.
- Si se encuentra cualquier problema de corrupción, favor de involucrar a su proveedor de hardware inmediatamente para que revise la plataforma haciendo las pruebas pertinentes. En nuestra experiencia es común que las utilidades de diagnóstico del proveedor indiquen que no existen problemas y es hasta que se investiga a fondo que se confirma un problema de hardware.
- Revisar que el antivirus no estén analizando los archivos de las bases de datos
- Revisar que los archivos de las bases de datos no estén en unidades/carpetas comprimidas.
- Recordar que lo más importante en una base de datos es la misma información, ya que SQL Server puede ser reinstalado sin problema pero los datos (dependiendo su origen) es algo más complicado de obtener.
Por lo tanto, ¿Tiene una copia de respaldo valida disponible?
Mas Información:
Database Corruption Part 1 :: Introduction to Database Corruption in SQL Server
How to troubleshoot database consistency errors reported by DBCC CHECKB
https://support.microsoft.com/kb/2015748
When should you rebuild the transaction log?
https://blogs.msdn.com/sqlserverstorageengine/archive/2006/06/15/632398.aspx
How to troubleshoot Error 17204 and 17207 in SQL Server
https://support.microsoft.com/kb/2015754
SQLIOSim available for download
Choosing what SQLIO tests to Run and Automating the Tests