Curso DBA Senior – C3 – Backups, recuperación y alta disponibilidad

---

¿Por qué este tema no puede tomarse a la ligera?

Porque no importa qué tan buena sea tu base de datos si no puedes restaurarla cuando lo necesites.
La mayoría de errores, caídas o pérdidas de datos se pueden prevenir… si tienes:

• Backups adecuados (no solo por defecto)
• Estrategias de recuperación realistas
• Opciones de alta disponibilidad bien configuradas

Este capítulo te lleva desde lo básico hasta escenarios críticos, con visión práctica y mentalidad de DBA senior.

Temas que abordaremos en este capítulo:

• 3.1 Modelos de recuperación y tipos de backup
  Qué guardar, cuándo y cómo. No todos los backups sirven para lo mismo.
• 3.2 Restauraciones avanzadas y escenarios reales
  Porque a veces solo necesitas recuperar una tabla, o un punto en el tiempo.
• 3.3 Alta disponibilidad: AlwaysOn, replicación y failover
  Soluciones para minimizar el tiempo de caída sin depender de backups.
• 3.4 Backups en Azure Blob Storage
  Cómo combinar seguridad, automatización y bajo costo en la nube.

Ejemplo para aterrizar la idea

Imagina que pierdes 2 horas de trabajo en una tabla crítica porque el backup más reciente era de anoche.
Ahora imagina que tu base cae y tarda 5 horas en volver porque no tenías un segundo nodo activo.
¿Qué impacto tendría eso en tu empresa? ¿En tu cliente? ¿En ti?

Consejos antes de entrar a los subtemas

• No todo backup es útil si no se ha probado recuperar
• Hacer backups automáticos sin entender el modelo de recuperación es peligroso
• Alta disponibilidad no reemplaza los backups, y viceversa

---

3.1 – Modelos de recuperación y tipos de backup

Tu estrategia de respaldo define tu capacidad de recuperación

¿Por qué no todos los backups son iguales?

Porque un backup mal hecho puede darte una falsa sensación de seguridad.
No se trata solo de tener copias, sino de saber qué tanto puedes recuperar, en cuánto tiempo y hasta qué punto en el pasado.

Aquí es donde entran en juego los modelos de recuperación y los distintos tipos de backup. Juntos definen tu estrategia de resiliencia.

Modelos de recuperación en SQL Server

Determinan cómo se comporta el log de transacciones y qué tanto puedes recuperar:

Modelo	¿Qué permite recuperar?	Ideal para…
Simple	Hasta el último backup completo	Sistemas no críticos, lectura intensiva
Full	Hasta cualquier punto en el tiempo (si tienes log backups)	Sistemas críticos, bases productivas
Bulk-Logged	Parecido al full, pero más eficiente en cargas masivas	ETL, cargas por lotes

Consulta el modelo de tu base:

SELECT name, recovery_model_desc
FROM sys.databases;

Cambia a modelo FULL (si tienes backups configurados):

ALTER DATABASE MiBase SET RECOVERY FULL;

Tipos de backup

1. Backup completo (Full Backup)

• Crea una copia íntegra de toda la base.
• Punto base para cualquier restauración.

BACKUP DATABASE MiBase TO DISK = 'C:\\Backups\\MiBase_FULL.bak';

2. Backup diferencial

• Solo guarda los cambios desde el último backup completo.
• Más rápido, pero necesita el backup full para restaurar.

BACKUP DATABASE MiBase TO DISK = 'C:\\Backups\\MiBase_DIFF.bak' WITH DIFFERENTIAL;

3. Backup del log de transacciones (Log Backup)

• Guarda los cambios registrados en el log desde el último log backup.
• Permite restaurar hasta un punto específico en el tiempo (solo en modelo FULL o BULK-LOGGED).

BACKUP LOG MiBase TO DISK = 'C:\\Backups\\MiBase_LOG.trn';

4. Copia de solo lectura o backups por archivo

• Útiles para restaurar bases distribuidas o leer sin afectar el entorno.
• También se puede usar backup en modo COPY_ONLY para no afectar la cadena de backups.

BACKUP DATABASE MiBase TO DISK = 'C:\\Backups\\MiBase_COPY.bak' WITH COPY_ONLY;

Frecuencia recomendada (según criticidad)

Tipo de Backup	Frecuencia sugerida
Full	Diario (mínimo)
Diferencial	Cada 4–6 horas
Log	Cada 15 min (o menos) en producción crítica

Buenas prácticas de backup

• Almacena copias fuera del servidor principal
• Verifica el estado y éxito de los backups automáticamente
• Prueba restauraciones periódicamente
• Documenta: ubicación, horarios, retención

Desafío práctico guiado

Objetivo: entender cómo se encadenan los backups y cómo configurarlos correctamente

1. Verifica el modelo de recuperación:

SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'MiBase';

2. Si estás en SIMPLE y quieres permitir restauración por log, cambia a FULL:

ALTER DATABASE MiBase SET RECOVERY FULL;

3. Haz un backup completo:

BACKUP DATABASE MiBase TO DISK = 'C:\\Backups\\MiBase_FULL.bak';

4. Modifica algunos datos, y luego haz un backup diferencial:

BACKUP DATABASE MiBase TO DISK = 'C:\\Backups\\MiBase_DIFF.bak' WITH DIFFERENTIAL;

5. Vuelve a modificar y haz un backup de log:

BACKUP LOG MiBase TO DISK = 'C:\\Backups\\MiBase_LOG.trn';

6. Imagina que debes restaurar: necesitas el FULL + el último DIF + todos los LOGs posteriores.

¿Qué deberías haber notado?

• Un backup full no es suficiente si ocurre una pérdida a mitad del día
• Tener una estrategia combinada (full + diferencial + logs) da control y velocidad
• Cambiar de modelo sin plan de backups puede invalidar tus log backups

Pregunta para reflexión o conversación

¿Con qué frecuencia haces backups? ¿Has probado recuperar? ¿Estás usando el modelo adecuado para tus necesidades reales?

---

3.2 – Restauraciones avanzadas y escenarios reales

No se trata de restaurar todo, se trata de restaurar bien y rápido lo que importa

¿Por qué restaurar es más complejo de lo que parece?

Porque en la vida real no siempre necesitas restaurar toda la base. A veces necesitas:

• Solo una tabla que alguien borró accidentalmente
• Volver al estado exacto de hace una hora
• Levantar una copia de una base productiva sin afectar a los usuarios
• Recuperar datos en otro servidor tras un desastre

Y si no practicas, te enteras del problema cuando ya es tarde.

Escenario 1: Restauración completa (clásica)

Tienes un backup full, uno diferencial y varios logs. Debes recuperar hasta el último momento posible.

Pasos:

-- Restaurar backup completo en modo NORECOVERY (espera más archivos)
RESTORE DATABASE MiBase
FROM DISK = 'C:\\Backups\\MiBase_FULL.bak'
WITH NORECOVERY;

-- Restaurar diferencial
RESTORE DATABASE MiBase
FROM DISK = 'C:\\Backups\\MiBase_DIFF.bak'
WITH NORECOVERY;

-- Restaurar logs (uno por uno si hay varios)
RESTORE LOG MiBase
FROM DISK = 'C:\\Backups\\MiBase_LOG.trn'
WITH NORECOVERY;

-- Último log con recuperación
RESTORE LOG MiBase
FROM DISK = 'C:\\Backups\\MiBase_LOG2.trn'
WITH RECOVERY;

Escenario 2: Restauración hasta un punto específico en el tiempo

Un usuario borró datos hace 10 minutos. Quieres volver justo antes.

Solo posible si estás en modelo FULL y tienes logs.

RESTORE DATABASE MiBase
FROM DISK = 'C:\\Backups\\MiBase_FULL.bak'
WITH NORECOVERY;

RESTORE LOG MiBase
FROM DISK = 'C:\\Backups\\MiBase_LOG.trn'
WITH STOPAT = '2025-04-23 13:42:00', RECOVERY;

STOPAT te permite viajar en el tiempo. Literalmente.

Escenario 3: Restaurar en otro nombre (para pruebas o recuperación parcial)

Quieres restaurar la base con otro nombre para revisar datos sin afectar producción.

RESTORE DATABASE MiBase_Copia
FROM DISK = 'C:\\Backups\\MiBase_FULL.bak'
WITH MOVE 'MiBase_Data' TO 'C:\\Temp\\MiBase_Copia.mdf',
     MOVE 'MiBase_Log' TO 'C:\\Temp\\MiBase_Copia.ldf',
     RECOVERY;

Escenario 4: Restaurar solo una tabla

SQL Server no permite restaurar solo una tabla directamente, pero puedes:

• Restaurar la base entera en otro nombre
• Extraer la tabla desde allí (con INSERT INTO ... SELECT FROM)
• O exportarla/importarla desde archivo

Tips técnicos para restauraciones limpias

• Usa WITH NORECOVERY hasta el último archivo para mantener la base en estado de restauración.
• Renombra rutas si estás restaurando en otro servidor.
• Verifica integridad con:

RESTORE VERIFYONLY FROM DISK = '...';

• Si tienes errores, revisa logs con:

SELECT * FROM msdb.dbo.restorehistory;

Desafío práctico guiado

Objetivo: restaurar una base hasta un punto en el tiempo en un nombre diferente

1. Asegúrate de tener un backup full y al menos un log
2. Restaura con cambio de nombre y carpeta:

RESTORE DATABASE MiBase_Restaurada
FROM DISK = 'C:\\Backups\\MiBase_FULL.bak'
WITH MOVE 'MiBase_Data' TO 'C:\\Temp\\MiBase_Restaurada.mdf',
     MOVE 'MiBase_Log' TO 'C:\\Temp\\MiBase_Restaurada.ldf',
     NORECOVERY;

3. Restaura un log con STOPAT:

RESTORE LOG MiBase_Restaurada
FROM DISK = 'C:\\Backups\\MiBase_LOG.trn'
WITH STOPAT = '2025-04-23 14:10:00', RECOVERY;

4. Consulta los datos en la base restaurada.

¿Qué deberías haber notado?

• Las restauraciones avanzadas requieren orden y precisión
• No es solo tener backups: es saber qué restaurar y hasta qué punto
• Practicar esto te convierte en un DBA confiable en momentos críticos

Pregunta para reflexión o conversación

¿Has practicado restaurar una base en otro nombre o hasta un punto específico? ¿Sabes cuánto tiempo te tomaría hacerlo en tu entorno real?

---

3.3 – Alta disponibilidad: AlwaysOn, replicación y failover

Porque en producción, el tiempo de inactividad no es una opción

¿Qué es alta disponibilidad en bases de datos?

Es la capacidad de un sistema para seguir funcionando incluso si un componente falla.
No reemplaza los backups, pero evita que el servicio se detenga ante fallas comunes: caídas de red, apagones, mantenimiento, etc.

¿Por qué usar alta disponibilidad si ya hago backups?

Porque los backups:

• No son instantáneos
• Implican tiempo de restauración
• No garantizan continuidad inmediata

Alta disponibilidad = minimizar o eliminar el tiempo de caída.

Principales soluciones de alta disponibilidad en SQL Server

1. AlwaysOn Availability Groups (AGs)

• Permite tener réplicas sincronizadas de una base en múltiples nodos.
• Se puede hacer failover automático o manual.
• Las réplicas pueden usarse para solo lectura (reportes, consultas).

Requiere:

• SQL Server Enterprise
• Configuración de clúster de Windows
• Mismo modelo de recuperación (FULL)

2. Database Mirroring (obsoleto, pero usado aún)

• Replica una base en otro servidor.
• Puede hacer failover automático (modo High Safety).
• Solo una réplica, no escalable.

Fue reemplazada por AlwaysOn, pero aún se encuentra en entornos heredados.

3. Log Shipping

• Copia los backups de log a otro servidor y los restaura de forma automática y programada.
• Tiene retraso (no es instantáneo), pero es simple y efectivo.
• Útil para recuperación en desastres a bajo costo.

4. Replicación

• Sincroniza datos específicos entre servidores (no es una copia exacta de toda la base).
• Ideal para entornos distribuidos o lectura intensiva.
• Tiene varios tipos: snapshot, transactional y merge.

Comparación rápida entre opciones

Solución	Recuperación automática	Costo	Uso recomendado
AlwaysOn AG	Sí	Alto	Producción crítica, mínima caída
Log Shipping	No (manual)	Bajo	DR (Disaster Recovery), bajo costo
Mirroring	Sí (limitado)	Medio	Sistemas antiguos
Replicación	No (depende del diseño)	Medio	Lecturas separadas, movilidad de datos

¿Qué se necesita para configurar AlwaysOn AG?

• SQL Server Enterprise
• Clúster de disponibilidad de Windows
• Configuración de endpoints y certificados
• Bases en modelo de recuperación FULL
• Configurar listeners, réplicas y sincronización

Desafío práctico conceptual

Objetivo: elegir la solución adecuada para distintos escenarios

Escenario 1:
Tienes una base crítica que no puede caer ni un minuto. ¿Qué usarías?

Escenario 2:
Tienes una sede secundaria que solo necesita una copia diaria para consulta. ¿Qué implementarías?

Escenario 3:
Tu cliente quiere distribuir datos a móviles sin conexión. ¿Qué tipo de replicación usarías?

Escribe tus respuestas. Evaluarlas te entrena para pensar como arquitecto de soluciones.

¿Qué deberías haber notado?

• No existe “la mejor solución”, sino la adecuada para cada contexto
• Alta disponibilidad no reemplaza los backups: se complementan
• Un buen DBA sabe cuándo invertir en velocidad de recuperación y cuándo en prevención

Pregunta para reflexión o conversación

¿Tienes claro cuánto tiempo puede estar inactiva tu base antes de que haya pérdidas graves? ¿Tu entorno está listo para responder?

---

3.4 – Backups en Azure Blob Storage

Automatiza, protege y ahorra espacio con respaldos en la nube

¿Por qué usar Azure Blob Storage para tus backups?

Porque los respaldos en disco local:

• Ocupan espacio en servidores de producción
• Son vulnerables a fallos físicos, ransomware o errores humanos
• Se complican cuando necesitas llevarlos fuera del sitio o a otro entorno

Azure Blob Storage te permite:

• Almacenar backups fuera del entorno físico
• Acceder desde cualquier parte
• Automatizar y monitorear
• Integrar con políticas de retención y recuperación más modernas

¿Qué es Azure Blob Storage?

Es un servicio de almacenamiento de objetos en la nube de Microsoft, ideal para:

• Archivos de respaldo (.bak, .trn)
• Archivos de log
• Scripts de configuración
• Documentación técnica u operativa

Ventajas principales del backup en Azure

Ventaja	¿Por qué importa?
Escalable	No te preocupas por el tamaño: crece según necesidad
Seguro	Soporte para cifrado, autenticación y control de acceso
Redundante	Replicado automáticamente (incluso entre regiones)
Automatizable	Compatible con scripts, agentes y tareas de mantenimiento
Económico	Pagas solo por el espacio usado (y puedes usar tier de bajo costo)

Requisitos previos

1. Una cuenta de Azure activa
2. Un contenedor de almacenamiento creado en Azure Blob
3. Una credencial creada en SQL Server para acceder al Blob

Configuración paso a paso en SQL Server

1. Crear el contenedor en Azure

• En el portal de Azure, crea una cuenta de almacenamiento
• Dentro de ella, crea un contenedor (tipo: Blob container)
• Obtén la cadena de conexión o la clave de acceso

2. Crear la credencial en SQL Server

CREATE CREDENTIAL [https://tubucket.blob.core.windows.net/backups]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'tu_sas_token'; -- O usa acceso con Storage Key

3. Hacer un backup directamente al Blob

BACKUP DATABASE MiBase
TO URL = 'https://tubucket.blob.core.windows.net/backups/MiBase_FULL.bak'
WITH CREDENTIAL = 'https://tubucket.blob.core.windows.net/backups',
COMPRESSION, STATS = 10;

Automatización recomendada

• Usa SQL Server Agent para crear un job de backups diarios al Blob
• Programa tareas para limpiar backups antiguos según política
• Monitorea con alertas o integraciones vía Azure Monitor

Desafío práctico guiado

Objetivo: realizar un backup desde SQL Server hacia Azure Blob Storage

1. Crea una cuenta de almacenamiento en Azure y un contenedor llamado backups
2. Genera un SAS token (Shared Access Signature) desde el portal
3. En SQL Server:
   • Crea la credencial
   • Ejecuta el backup con TO URL
   • Verifica que el archivo aparece en el portal de Azure

¿Qué deberías haber notado?

• No necesitas mover manualmente los archivos fuera del servidor
• El backup en Blob es seguro, escalable y automatizable
• Es una solución profesional y moderna para entornos productivos

Pregunta para reflexión o conversación

¿Dónde guardas hoy tus backups? ¿Qué tan rápido podrías recuperarlos si el servidor físico se pierde mañana?

---

¿Te gustó lo que encontraste aquí?

Si este contenido te fue útil o te inspiró, considera apoyar esta iniciativa.
Aquí sigo, creando recursos que aporten claridad, estructura y propósito en tu camino.

♥️ Hey sí, ¡quiero apoyar esto!

---

---

---

---