Restaurar SQL: guía práctica para recuperar bases de datos en SQL Server y MySQL

Restaurar SQL es la operación crítica que permite recuperar una base de datos tras un fallo, borrado accidental o migración. Este texto ofrece pasos prácticos, comprobaciones y soluciones específicas para SQL Server y MySQL, con ejemplos aplicables en entornos de producción.

Problemas que requieren restaurar SQL

No siempre la restauración es la primera opción, pero suele ser necesaria en escenarios concretos:

• Borrado accidental de tablas o registros cuando el log de transacciones no permite rollback.
• Corrupción de archivos de datos por fallo de disco o errores de IO.
• Despliegues que rompen esquemas y se necesita volver a un punto anterior.
• Migraciones entre servidores donde la sincronización falla.
• Recuperación tras ataque, cifrado o eliminación maliciosa.

Cada caso exige una estrategia distinta: a veces basta con restaurar un esquema o tabla específica, otras veces hay que traer la base completa y aplicar logs hasta un punto en el tiempo.

Preparación: respaldos, comprobaciones y entorno

Antes de iniciar cualquier restauración, confirmar tres cosas básicas: existencia y validez del respaldo, integridad del entorno destino y permisos suficientes.

• Verificar backups: comprobar fecha, tipo (completo, diferencial, de logs) y caducidad. En SQL Server usar RESTORE VERIFYONLY para validar archivos .bak; en MySQL, probar importar a una instancia de test.
• Cadena de recuperación: asegurarse de tener todos los diferenciales y archivos de log necesarios para alcanzar el punto objetivo.
• Espacio y rutas: confirmar que el servidor destino tiene espacio en disco y rutas de archivos (mdf/ldf o datadir) disponibles.
• Permisos: la cuenta de servicio debe poder leer backups y escribir archivos; las cuentas de SQL deben mapear con logins si se restaura en otro servidor.
• Entorno de pruebas: siempre realizar una prueba de restauración en staging antes de la producción si el RTO lo permite.

Checklist mínimo antes de restaurar:

1. Backup válido y comprobado.
2. Listado de logs y diferenciales necesarios.
3. Plan de comunicación con los usuarios afectados.
4. Punto de recuperación objetivo (fecha/hora o LSN).
5. Confirmación de espacio y permisos.

Restauración paso a paso en SQL Server

SQL Server ofrece operaciones detalladas para restaurar completo, diferencial y log. Importante conocer el estado de recuperación: NORECOVERY para encadenar restauraciones y RECOVERY para finalizar y abrir la base.

Restauración completa

Paso típico para restaurar una base desde un .bak:

1. Colocar el archivo .bak en una ubicación accesible por SQL Server.
2. Ejecutar un comando como: RESTORE DATABASE NOMBRE FROM DISK = ‘C:backupsbd.bak’ WITH REPLACE, RECOVERY;
3. Si se requiere cambiar rutas físicas, obtener los nombres lógicos con RESTORE FILELISTONLY y especificar MOVE para cada archivo.

Si la intención es aplicar logs posteriores al backup completo, usar NORECOVERY en la restauración inicial y luego aplicar diferenciales/logs.

Diferenciales y restauración de logs

Flujo común para recuperación punto en el tiempo:

1. Restaurar backup completo con NORECOVERY.
2. Aplicar backup diferencial más reciente (si existe) con NORECOVERY.
3. Restaurar backups de log en orden hasta el punto deseado. El último restore debe usar RECOVERY o STOPAT para punto en el tiempo.

Comando ejemplo para aplicar un log y recuperar hasta una hora: RESTORE LOG NOMBRE FROM DISK=’C:backupsbd.trn’ WITH STOPAT=’2026-08-01T14:23:00′, RECOVERY;

Precauciones: la restauración de logs requiere que el modelo de recuperación sea Full o Bulk-Logged; en modelo Simple no habrá logs completos.

Restauración paso a paso en MySQL/MariaDB

En entornos MySQL hay dos enfoques principales: backups lógicos con mysqldump y backups físicos o incrementales con herramientas como Percona XtraBackup. Para recuperación punto en el tiempo se usan los binlogs.

Backups con mysqldump

Para restaurar un volcado SQL generado por mysqldump:

1. Crear la base vacía si no existe: CREATE DATABASE nombre;
2. Ejecutar: mysql -u root -p nombre < backup.sql

Limitaciones: los dumps son fáciles de transportar pero pueden ser lentos en bases grandes y no permiten aplicar binlogs directamente.

Binlogs y recuperación punto en el tiempo

Si el servidor tiene activado el binlog, se puede avanzar desde un backup lógico o físico hasta un punto exacto con mysqlbinlog:

1. Restaurar el último respaldo base (dump o físico).
2. Reproducir binlogs desde la posición necesaria: mysqlbinlog binlog.00000X | mysql -u root -p
3. Para reproducir hasta una fecha usar –stop-datetime en mysqlbinlog.

En implementaciones con XtraBackup se usan los pasos de prepare y luego se copian los datos al datadir.

Errores comunes al restaurar SQL y cómo solucionarlos

Algunas fallas recurrentes y sus mitigaciones:

• Error de espacio: liberar espacio o redirigir archivos con MOVE. Si no es posible, restaurar en un servidor con más capacidad.
• Incompatibilidad de versiones: evitar restaurar desde una versión más reciente a una anterior; en su lugar, exportar datos con formatos compatibles.
• Archivos con nombres existentes: usar WITH MOVE (SQL Server) o restaurar en una base temporal y renombrar.
• Usuarios huérfanos: en SQL Server mapear logins con ALTER LOGIN … WITH SID o recrear logins y ajustar permisos; para MySQL verificar usuarios en mysql.user.
• Corrupción detectada tras restaurar: no poner en producción; validar integridad con herramientas específicas y, si es necesario, restaurar a un punto anterior.

Mini-caso: un backup restaurado mostraba tablas corruptas por diferencias en collation. Solución: restaurar en un servidor con la misma collation y/o exportar datos en texto y reimportar ajustando la codificación.

Caso práctico: recuperar una base tras borrado accidental

Contexto: eliminación por script de producción a las 09:12. Backups diarios completos a las 02:00 y logs de transacción continuos.

1. Identificar el último backup completo: 02:00 y los logs necesarios desde esa hora.
2. Restaurar backup completo en servidor de recuperación con NORECOVERY.
3. Aplicar logs de transacción en orden hasta STOPAT = ‘2026-08-23T09:10:00’ para evitar el borrado accidental.
4. Finalizar con RECOVERY, validar consistencia y comparar filas con registros de auditoría.
5. Mapear usuarios y probar la aplicación en un entorno de preproducción antes de switch al servidor restaurado.

Resultado y lecciones: la restauración devolvió la base en 18 minutos con pérdida mínima de datos. Lecciones: habilitar backups más frecuentes o snapshots y probar procedimientos de restauración periódicamente.

Recomendaciones operativas y cierre

Para reducir RTO y RPO al restaurar SQL, conviene aplicar estas prácticas:

• Automatizar backups con retención y rotación claras; incluir backups completos, diferenciales e incrementales según la carga.
• Probar restauraciones trimestralmente y documentar pasos con tiempos estimados.
• Monitorear espacio en disco y salud de respaldos (alertas si un backup falla o no se verifica).
• Separar backups fuera del host primario (almacenamiento remoto o S3) y cifrarlos en tránsito y reposo.
• Definir runbooks por tipo de incidente: borrado, corrupción, migración o pérdida total de servidor.

Restaurar SQL no es solo ejecutar comandos: requiere planificación, comprobaciones y pruebas previas. Implementar políticas claras de backup, practicar la restauración y mantener auditoría de cambios reduce el riesgo operativo y acelera la recuperación cuando se necesita actuar.

Restaurar SQL debe formar parte de la estrategia operativa habitual: con respaldos validados, planes de recuperación ensayados y controles de acceso, la restauración se convierte en un proceso fiable y predecible.