Implementando Backups en SQL Server paso a paso

Por 0 No tags Permalink

Backups, es aquello que hacemos muy de vez en cuando, nunca cuando las necesitábamos, y que cuando hay un desastre echamos en falta.

Es muy importante como hacer copias de seguridad de los datos, antes de tomar una decisión es entender cuán crítico es. Hay que entender qué tipo de copias de seguridad podemos y debemos hacer según el escenario de nuestra base de datos. Existen muchos factores, pero los más importantes en resumen pueden ser 4: Tamaño de la copia, criticidad de los datos, tiempo necesario en volver a estar operativo tras el restore y espacio en disco necesario. Existen 3 tipos de Backups.

Backup FULL:
Ideal para pequeñas bases de datos o poco críticas. Es fácil recuperarlas, ya que normalmente es un único fichero y no son necesarios ficheros logs. Como inconveniente necesita proporcionalmente bastante espacio en disco y el restore solo puede realizarse en el momento exacto a cuando se hizo el backup.

  • Soporta todos los modos de recovery de la base de datos.

Las desventajas que tiene el modo de recuperación FULL son:

  • El gran crecimiento de log en algunos momentos.
  • La necesidad de realizar backup de log y tener espacio adicional para este tipo de backups.
  • La necesidad de restaurar el backup full y los sucesivos backup de log en caso de una recuperación completa.

Backup FULL + Diferencial:
Ideal para grandes bases de datos o con poca densidad de transacciones donde cierta pérdida de datos es aceptable. Toma menos espacio en disco que la Full, no necesita ficheros logs y el restore es más preciso. A cambio se necesitan dos ficheros (datos y diferencial) para la restauración y solo se puede volver a aquel preciso instante de cuando realizamos la copia.

  • Soporta todos los modos de recovery de la base de datos.
  • No es incremental, esto significa que para restaurar necesitas un FULL y el ultimo DIFERENCIAL.

Backup FULL+ Diferencial + Log de Transacciones:
Ideal para bases de datos con alta densidad transaccional o donde no es aceptable ninguna pérdida de datos. La restauración es tan precisa como que se puede restaurar a cualquier instante dentro del período de la copia, aunque el tamaño de la copia es mayor y se necesitan ficheros logs.

  • Backup solo del transactionLog,.
  • Solo esta soportado en los modos de recovery FULL o BULK.
  • Es el mas

¿Qué modo de recuperación en SQL Server es más conveniente?
Como en casi todo, esta decisión entra en juego el tiempo de datos que estamos dispuesto a perder, el uso que se le va a dar a la base de datos, y el espacio disponible en disco.

SSMS Wizard

  • Simple de implementar
  • Muy poco personalizacion
  • Recomendado para DBA con poca experiencia.

Herramientas de Terceros

  • Hay muchos casos que no son customizables.
  • Dependencia de la herramienta para hacer restores.
  • Tener en cuenta que algunos casos puede generar problemas de performance en los MSSQL.

Scrips via Jobs

  • Esta es la preferida de los DBAs con experiencia
  • Nativo de MSSSQL sin la necesida de usar terceras partes
  • Muy personalizado donde podrás utilizar el potencial a todas las opciones de Backup.
  • Para esto recomiendo el uso de (OLA) https://ola.hallengren.com/
  • Correr Backup FULL no es buena idea.
  • Los Backups deben se guardados en un servidor externo.
  • Esta es una política de Backup usada por la mayoría de los DBAs
  • Para el TLog es recomendable hacerlos entre 5 y 15 minutos.

nos descargamos el archivo de (OLA) y lo ejecutamos-

Este script generar los siguientes JOBs

estos JOBs, ejecutan procedimientos almacenados

estos procedimientos son personalizables, la documentación la puedes encontrar en el siguiente link es muy simple de configurar.

Compara el precio para envíos nacionales e internacionales con hasta un 70% de ahorro.

No Comments Yet.

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *