Una copia de seguridad permite recuperar datos, pero restaurarla directamente sobre la base activa puede eliminar cambios legítimos realizados después de la fecha de la copia. Cuando el problema afecta a un registro o a un conjunto acotado, el objetivo suele ser recuperar la información perdida y conservar el resto del estado actual. Eso exige tratar la recuperación como una operación de comparación y reconciliación, no como un simple reemplazo.
La estrategia adecuada depende del motor de base de datos, del esquema, de la disponibilidad de registros de auditoría y del alcance del daño. En una aplicación PHP, conviene separar la lógica de recuperación de la aplicación en producción, documentar las decisiones y probar las validaciones antes de escribir datos. Si no se puede determinar qué cambios son seguros, detenerse y preparar una conciliación manual suele ser menos arriesgado que automatizar una sobrescritura.
Definir qué significa recuperar los datos
Una restauración completa reemplaza una base, un esquema o un conjunto amplio de datos por el contenido de un punto de recuperación. Una recuperación selectiva, en cambio, intenta restablecer filas concretas o valores determinados sin modificar los demás datos activos. Antes de elegir, describe el resultado esperado con precisión: qué entidad falta o quedó alterada, qué campos deben recuperarse y qué cambios posteriores deben conservarse.
Delimita el alcance usando identificadores estables, como la clave primaria, y no sólo valores que podrían haber cambiado, como el nombre o el correo. Aclara también si el incidente afecta a registros relacionados: por ejemplo, un pedido puede depender de líneas, pagos, direcciones y eventos de estado. Recuperar sólo la fila principal puede dejar una entidad incoherente; recuperar todo el grupo puede incluir cambios válidos que no deben revertirse.
- Registra el síntoma, el intervalo temporal aproximado y quién informó del problema.
- Identifica las tablas, claves primarias, claves externas y restricciones relevantes.
- Define qué campos deben volver a un valor anterior y cuáles deben permanecer como están.
- Establece quién aprobará la operación y qué comprobaciones permitirán darla por concluida.
Elegir un punto de recuperación y reconstruir el contexto
Selecciona un punto de recuperación que permita reconstruir el estado requerido, no necesariamente una copia anterior al daño. Según el incidente, puede ser preciso comparar varias copias, registros de transacciones y datos de auditoría para identificar qué información debe recuperarse y qué contexto posterior conviene conservar. La recuperación a un punto en el tiempo puede producir una base temporal útil para extraer datos, pero no implica que sea seguro trasladar su contenido completo a producción.
Confirma la fecha y zona horaria, la cobertura de la copia, el esquema con el que se creó y el resultado de las comprobaciones de integridad disponibles. Una copia no verificada no debe considerarse una fuente fiable por defecto. Comprueba asimismo si los identificadores pueden haberse reutilizado o si existen procesos que escriben en las tablas afectadas durante la investigación.
Restaura la copia en una instancia aislada, con acceso restringido y sin conexiones de escritura hacia producción. La aplicación no debería apuntar accidentalmente a esa instancia ni ejecutar trabajos programados sobre ella. Si los datos contienen información personal o sensible, limita el acceso y aplica las medidas de protección previstas para esos datos. El entorno aislado permite comparar estados sin añadir riesgo a la base activa.
Comparar sin asumir que la copia es la verdad actual
Compara las filas candidatas de la copia con las filas actuales usando sus claves estables. Para cada una, distingue entre tres situaciones: el registro ya no existe, existe pero tiene campos modificados, o no presenta diferencias relevantes. Si hay marcas de actualización, historial de eventos o auditoría, úsalos para entender cuándo y por qué cambió. Una marca temporal por sí sola no demuestra qué usuario realizó el cambio ni si éste debe conservarse.
La recuperación selectiva exige una precaución esencial: no copiar automáticamente una fila antigua completa cuando algunos de sus campos hayan evolucionado de forma válida. La comparación puede mostrar, por ejemplo, que un registro perdió un campo descriptivo, mientras que su estado, propietario o relación con otra entidad cambió después. Recuperar sólo el campo perdido puede ser más seguro que reemplazar la fila entera, siempre que las reglas de negocio lo permitan.
Revisa también conflictos de unicidad, claves externas, columnas obligatorias, valores por defecto y reglas aplicadas por la aplicación. En sistemas con borrado lógico, comprueba si el registro está marcado como eliminado en lugar de ausente. Las tablas que participan en una misma operación de negocio pueden requerir una reconciliación conjunta para evitar saldos, estados o referencias inconsistentes.
Aplicar una operación acotada y verificable
Prepara un plan con el conjunto exacto de claves y columnas que se van a modificar. Antes de ejecutarlo, conserva una copia del estado actual de esas filas o un mecanismo equivalente de reversión. Ensaya el plan sobre una copia reciente de la base activa y compara el resultado con el esperado. El ensayo debe incluir las restricciones y dependencias reales, no sólo una importación de filas aisladas.
Cuando el motor y la operación lo permitan, ejecuta los cambios en una transacción. Una transacción no sustituye la revisión: algunas acciones de restauración o importación pueden tener comportamientos específicos del motor, y procesos externos pueden actualizar datos de forma concurrente. Usa condiciones que detecten cambios inesperados entre la comparación y la escritura. Si la fila ya no coincide con el estado revisado, detén la operación y vuelve a analizarla, en vez de sobrescribirla silenciosamente.
En una aplicación PHP, una tarea controlada o un comando de mantenimiento puede validar entradas, limitar las claves afectadas y registrar resultados. Evita construir instrucciones SQL concatenando valores. Usa consultas parametrizadas y el mecanismo transaccional del acceso a datos empleado por la aplicación. Mantén la operación fuera de rutas públicas y no expongas credenciales o copias en registros de texto.
Antes de confirmar los cambios, verifica el número de filas afectadas, las restricciones y las relaciones relevantes. Después, comprueba los valores recuperados y el comportamiento de la aplicación en las operaciones de negocio relacionadas. Si una validación falla antes de confirmar una transacción, revierte la transacción. Si ya se confirmó o existen efectos no reversibles, no improvises una nueva escritura: activa el plan de reversión o recuperación aprobado antes de ejecutar, siguiendo el procedimiento probado para restaurar el estado aceptado y comprobarlo. Si el plan no permite recuperar un estado coherente, detén nuevas modificaciones, conserva evidencias y escala la decisión a las personas responsables.
Registrar la decisión y elegir cuándo no automatizar
Deja constancia del incidente, el punto de recuperación usado, las claves examinadas, los campos restaurados y los cambios posteriores preservados. Registra quién revisó y aprobó la operación, cuándo se ejecutó, qué validaciones se realizaron y cuál fue el resultado. No incluyas datos sensibles innecesarios en el registro. Esta trazabilidad permite explicar la decisión y facilita una investigación posterior.
Opta por reconciliación manual si faltan claves fiables, hay conflictos entre operaciones de negocio, no se puede distinguir el cambio accidental de uno legítimo o la recuperación afecta a relaciones cuyo significado depende del contexto. La restauración completa puede ser apropiada ante una corrupción extensa, pero requiere valorar su impacto, interrupción, pérdida de cambios posteriores y procedimiento de recuperación. No debe elegirse sólo porque sea más sencilla de ejecutar.
- Recuperación selectiva: el daño está bien delimitado, las claves son fiables y las diferencias pueden verificarse.
- Reconciliación manual: hay cambios concurrentes o reglas de negocio que requieren criterio humano.
- Restauración completa: el daño es amplio y existe un plan aprobado para gestionar la indisponibilidad y los cambios que se perderían.
Lista de comprobación antes de cerrar la recuperación
- Preparación: ¿están identificados el alcance, las claves, las dependencias y el resultado esperado? ¿Se ha elegido y verificado un punto de recuperación adecuado?
- Entorno y aprobación: ¿se ha restaurado la copia en aislamiento, limitado el acceso y ensayado el procedimiento? ¿Las personas responsables han aprobado la operación y el plan de reversión o recuperación?
- Ejecución: ¿se conserva el estado actual de las filas afectadas, se limita la escritura a las claves y campos previstos y se detectan cambios concurrentes?
- Verificación: ¿se revisaron filas afectadas, restricciones, referencias y comportamiento de negocio? Si falla una comprobación, ¿se detuvieron nuevas escrituras y se activó el procedimiento aprobado?
- Trazabilidad: ¿quedaron registrados la decisión, la ejecución, las validaciones, los cambios preservados y el resultado, sin incluir datos sensibles innecesarios?
Si no puedes responder afirmativamente a los puntos pertinentes, aplaza la escritura en producción. La decisión entre recuperación selectiva, conciliación manual y restauración completa debe basarse en el alcance del daño, la fiabilidad de las evidencias, el impacto operativo y la posibilidad real de recuperar un estado coherente.
