Blog

Archivo: abril de 2012

Reparar una base de datos corrupta en Sql Server (Parte I)

Publicado en Sistemas TI en abril 25, 2012 10:28 am

Debido a múltiples circunstancias como cortes eléctricos inesperados, problemas de espacio en disco, fallos de hardware, que hayas borrado el archivo de log (.ldf), etc. Una bbdd puede corromperse, normalmente la mejor manera de solucionar esto es recurrir a la última copia de seguridad pero como puede ocurrir en estos casos no hay copia o la que tenemos disponible es ya algo vieja. En esos casos quizá aún podamos recuperar la información.

Una bbdd puede tener estos estados (LINK):

  • ONLINE: La base de datos está disponible para su acceso. El grupo de archivos principal está en línea, aunque la fase de deshacer de la recuperación puede no haberse completado.
  • OFFLINE: La base de datos no está disponible. Una base de datos pasa a estar sin conexión por la acción explícita del usuario y permanece sin conexión hasta que el usuario toma otra acción. Por ejemplo, la base de datos puede desconectarse para mover un archivo a un nuevo disco. La base de datos se vuelve a poner en línea una vez completado el traslado.
  • RESTORING: Uno o varios archivos del grupo de archivos principal se está restaurando, o uno o varios archivos secundarios se están restaurando sin conexión. La base de datos no está disponible.
  • RECOVERING: Se está recuperando la base de datos. El proceso de recuperación es un estado transitorio, la base de datos se pone automáticamente en línea si la recuperación tiene éxito. Si la recuperación no tiene éxito, la base de datos pasa a ser sospechosa. La base de datos no está disponible.
  • RECOVERY PENDING: SQL Server ha encontrado un error relacionado con un recurso durante la recuperación. La base de datos no está dañada pero pueden faltar archivos o bien limitaciones de recursos del sistema pueden estar impidiendo que se inicie. La base de datos no está disponible. Se necesita una acción adicional por parte del usuario para resolver el error y permitir que se complete el proceso de recuperación.
  • SUSPECT: Como mínimo un grupo de archivos principal es sospechoso y puede estar dañado. La base de datos no se puede recuperar durante el inicio de SQL Server. La base de datos no está disponible. Se requiere una acción adicional por parte del usuario para resolver el problema.
  • EMERGENCY: El usuario ha cambiado la base de datos y ha establecido el estado en EMERGENCY. La base de datos está en modo de usuario único y se puede reparar o restaurar. La base de datos está marcada como READ_ONLY, el registro está deshabilitado y el acceso está limitado a miembros de la función fija de servidor sysadmin. EMERGENCY se utiliza principalmente para solucionar problemas. Por ejemplo, una base de datos marcada como sospechosa se puede establecer en el estado EMERGENCY. Esto puede permitir al administrador del sistema acceso de sólo lectura a la base de datos. Sólo los miembros de la función fija de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.

Cuando se corrompe la tendremos seguramente en Online, Recovery pendingSuspect.

Puedes ver el estado de la BD utilizando esta consulta (sustituye blackslotdb por la bd a consultar):

SELECT state_desc FROM sys.databases WHERE name = ‘blackslotdb’;

Si la bd está en estado ONLINE, lo más fácil es intentar un checkdb con la opción REPAIR_ALLOW_DATA_LOSS.

DBCC CHECKDB (MAGIC, REPAIR_ALLOW_DATA_LOSS)WITH NO_INFOMSGS

Más info en http://technet.microsoft.com/es-es/library/ms188422.aspx

En la segunda parte de este post comentaremos como reparar si la bd se encuentra en alguno de los otros 2 modos o no se puede adjuntar.

Backup y otras medidas de seguridad para el alojamiento de contenido en servidores remotos

Publicado en General Novedades Nuestros servicios Sistemas TI en abril 4, 2012 9:20 am

El pasado 31 de marzo se celebró el Día Mundial del Backup

Con este día se pretende concienciar a los usuarios sobre la importancia de disponer copias de respaldo de sus datos.

Hemos querido publicar este post sobre backup y otras medidas de seguridad para el alojamiento de contenido en servidores remotos,  para rendir homenaje a este día.

BACKUP

Recomendaciones:

-    Antes de contratar servicios de alojamiento en una empresa de hosting, consulta si éstos incluyen backup
-    Si los datos que vas a alojar son especialmente sensibles,   infórmate sobre el grado de seguridad que debe cumplir su salvaguarda (deduplicación de backup, encriptación, lugar del datacenter, etc.) y contrástalo con tu proveedor.

Existen diferentes técnicas para realizar backups. Actualmente las empresas de hosting las suelen combinar. Más que ser técnicas excluyentes, son complementarias y dependiendo de los requisitos o necesidades de recuperación de datos  de los usuarios, unas veces se adaptan mejor los snapshots y otras veces, la recuperación de archivos.

•    Backup de la máquina o snapshot
•    Backup de archivos

DISCOS EN RAID

Esta medida de seguridad debe acompañarse siempre de un sistema de backup. No basta con disponer de dos (o más) discos duros en la máquina en los que se replica el contenido ya que si se produce un error y se borra contenido o se corrompe una base de datos, automáticamente el error se replicará en el disco que funciona a modo de espejo.  Contar con discos en RAID permite que, si existe un fallo en uno de ellos, el usuario pueda seguir trabajando con el otro disco disponible mientras se sustituye el afectado.

SERVIDORES DE DESARROLLO

En Blackslot estamos especialmente sensibilizados con el mundo del desarrollo, por ese motivo ofrecemos dos servicios que están íntimamente relacionados con el servicio de copias para programación:

1)    Clones de tu servidor

Si tienes tu servidor alojado en Blackslot,  podemos crear un clon de tu máquina, en cuestión de segundos,  de modo que obtengas una réplica exacta  sobre la que llevar a cabo labores de desarrollo y que, una vez testadas, puedan pasar directamente a producción.

2)    Servidores concebidos para el alojamiento de código (control de versiones)

Se trata de servidores con una aplicación para el control de versiones (GIT) . Si varios programadores están trabajando sobre un mismo código, podrán alojarlo de manera segura en nuestros servidores y, además, se guardará un registro de cada uno de los cambios que realice cada programador.

El control de versiones permite volver atrás y restablecer de manera rápida y sencilla el código anterior en caso de que resultara preciso.

Para más información: info@blackslot.com