Si el servidor principal cae en este momento, saber exactamente cuántos datos se pierden y en cuánto tiempo se puede volver a operar marca la diferencia entre una empresa preparada y una en crisis. Construir una estrategia de backup sólida en SQL Server no se trata solo de copiar archivos, sino de garantizar que esa copia pueda restaurarse en tiempo y forma.
¿Qué son el RPO y el RTO en una estrategia de backup?
Antes de ejecutar cualquier comando, es fundamental entender dos métricas que definen toda la estrategia. El RPO o recovery point objective [0:55] responde a la pregunta: ¿cuántos datos máximos puedo perder? Si el RPO es de una hora, los backups deben hacerse al menos cada hora. Si el RPO es cero, se necesitan tecnologías como log shipping o always on.
Por otro lado, el RTO o recovery time objective [1:18] define cuánto tiempo máximo puede tardar el sistema en volver a funcionar. Un backup full de quinientos gigas puede tardar horas en restaurarse, y ese tiempo cuenta dentro del RTO. Para un caso como Tienda Latam, un RPO razonable es de quince minutos y un RTO de dos horas [1:40].
¿Cuáles son los tres tipos de backup en SQL Server?
SQL Server ofrece tres tipos de backup que trabajan en conjunto para cumplir con el RPO y el RTO definidos.
- Backup full: copia completa de la base de datos. Es el punto de partida de cualquier secuencia de restauración. Su frecuencia típica es semanal o diaria [1:53].
- Backup diferencial: contiene solo los cambios desde el último backup full. Es más pequeño y rápido, lo que acelera el restore. Se realiza generalmente una vez al día [2:14].
- Backup de log o transaction log: registra únicamente los cambios del log de transacciones desde el último backup de log. Es el más pequeño, el más frecuente y define el RPO real. Su frecuencia típica va de cada quince a sesenta minutos [2:36].
Para restaurar completamente, se necesita el full más el último diferencial más todos los logs posteriores al diferencial [2:55].
¿Cómo se ejecutan los comandos de backup?
El comando BACKUP DATABASE genera el backup full hacia una ruta en disco. Se recomienda usar WITH COMPRESSION para reducir el espacio, CHECKSUM para verificar integridad al escribir, y STATS = 10 para mostrar el progreso cada diez por ciento [3:22]. En SQL Server Express, la compresión no está soportada, por lo que debe omitirse [5:08].
Para el backup diferencial, se agrega WITH DIFFERENTIAL al comando, indicando que tome solo los cambios desde el último full [4:01]. Para el backup de log, se usa BACKUP LOG en lugar de BACKUP DATABASE [4:30].
Un detalle crítico: los backups de log solo funcionan cuando el recovery model de la base de datos está configurado como full o bulk logged. Si está en simple, hay que cambiarlo antes de ejecutar el backup de log [4:50].
sql -- Verificar recovery model SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'TiendaLatam';
-- Cambiar a full ALTER DATABASE TiendaLatam SET RECOVERY FULL;
¿Cómo se restaura una base de datos paso a paso?
El proceso de restore sigue cuatro pasos estrictos y ordenados.
¿Qué preparación se necesita antes de restaurar?
Primero, no se puede restaurar una base de datos desde ella misma, así que hay que cambiar el contexto a master [7:38]. Luego se verifica que la base exista y se cambia a modo single user para evitar conflictos con conexiones activas [8:02].
sql USE master; ALTER DATABASE TiendaLatam SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
¿En qué orden se restauran los backups?
El orden es fundamental y no puede alterarse:
- Restaurar el backup full con
WITH NORECOVERY, lo que indica que vienen más backups [6:50].
- Restaurar el backup diferencial, también con
NORECOVERY.
- Restaurar todos los logs en orden cronológico.
- Ejecutar
RESTORE DATABASE ... WITH RECOVERY para finalizar y poner la base en línea [7:15].
Después del recovery, se regresa la base a modo multi user y se verifica que esté en línea y accesible [8:55].
El gran mensaje es claro: una estrategia de backup no es simplemente hacer copias, es definir el RPO y el RTO, implementar la secuencia correcta de backup y restore, y probarlo regularmente. Comparte en los comentarios cómo te fue con este proceso de backup y restauración.
