Siempre se dice que hacer copias de seguridad, copias de seguridad, copias de seguridad aún más y más. Lo que solemos decir con menos frecuencia es que hasta que los datos no se han restaurado con éxito una copia de seguridad es inútil.

Un ejemplo llamativo es el caso de Ma.gnolia , el sitio social donde es posible almacenar las páginas de la marca en Internet. El 30 de enero pasado, el sitio ha sufrido un accidente catastrófico de la base de datos MySQL 5, que conduce al sitio hace el corte. Este accidente fue debido a la corrupción de datos con el tiempo (no detectable, a priori, sin ningún tipo de comprobación de coherencia real), que también corrompe copias de seguridad. Un pasaje por los especialistas en recuperación de datos por desgracia, ha dado nada bien, lo que significa una pérdida total de cerca de 500 GB de datos de los usuarios y la muerte real del sitio en su versión actual. Afortunadamente, los sistemas de almacenamiento en caché en otros sitios web ( FriendFeed , RSS, etc) han permitido a algunos usuarios a recuperar algunos de sus datos.

Aquí está un podcast donde el responsable de Ma.gnolia explica un poco más detalle lo que sucedió:

Episodio Ciudadano Jardín 11: ¿A dónde Ma.gnolia? de Larry Halff en Vimeo .

La lección principal que debemos recordar para que un operador de copias de seguridad se prueba con regularidad aquí hasta el final de su proceso de recuperación de datos. También es útil, aunque técnicamente difícil o imposible de llevar a cabo auditorías de consistencia de los datos y guardar copias de seguridad.

En uno de nuestros servidores SQL que estaba utilizando un Adaptec 2810SA tarjeta controladora RAID con tres unidades de disco SATA en RAID 5. El servidor de repente ha desaparecido: inicio se quedó atascado en la inicialización de la tarjeta y, finalmente, mostrar un tiempo de espera.

Afortunadamente, tenía un 2820SA de Adaptec, y ya que estas tarjetas almacenar la configuración de RAID en los propios discos y memoria caché, no el cambio en el mapa era posible con una buena esperanza de no perder ningún dato. Así que me quité la tarjeta de 2810 señalando el orden de conexión de las tres unidades de disco duro, añadió el 2820 y vuelto a conectar las unidades en el mismo orden. En el arranque de la tarjeta se inicializa correctamente y muestra un mensaje indicando la presencia de un RAID 5 en el extranjero se debe aceptar que la configuración de su uso. RAID 5 se pondrá en modo de recuperación / Verificación y es inmediatamente utilizable.

El problema, sin embargo: la versión del mapa no es exactamente lo mismo, Windows 2003 R2 Enterprise lanzamiento rebootait. Por consiguiente, era necesario volver a instalar en modo de reparación y proporcionar un disquete con los controladores para la tarjeta controladora RAID nuevo. Una vez terminado, todos los datos y programas instalados y estuvo en funcionamiento el servidor podría volver a la producción.

El periodo total de tiempo de inactividad fue de tres horas, lo que para un servidor "noname" es bastante aceptable, sobre todo, sin pérdida de datos.

Tras la muerte repentina y simultánea de dos de los tres discos duros conectados en RAID 5 en mi servidor de SQL Server 2000 (gusta cómo esto es posible), tuve que reconstruir con urgencia un nuevo servidor. A modo de recordatorio se puede perder un disco duro en un RAID 5 sin perder los datos, se pierde todo lo que fuera ... Yo detalle aquí los pasos que seguí para restaurar completamente los datos.

Continuar leyendo "La restauración de SQL Server"