Cómo restaurar una copia de seguridad de un sitio web de forma segura
Publicado el 30 de abril de 2026
Una restauración de sitio web suele comenzar en el peor momento posible: después de una actualización fallida de un plugin, una cuenta de administrador comprometida, una implementación rota o un error en la base de datos que salió en producción antes de que nadie lo notara. Cuando eso sucede, saber cómo restaurar una copia de seguridad del sitio web importa más que tener una copia de seguridad en primer lugar. El trabajo real es volver a poner tu sitio en línea sin arrastrar viejos problemas, datos perdidos o más tiempo de inactividad.
Si eres responsable de un sitio de negocios, una tienda en línea, un panel SaaS o un entorno de cliente, la restauración más segura rara vez es la más rápida. Depende de lo que falló, cuándo comenzó el problema y si necesitas restaurar todo el sitio o solo una parte.
Antes de restaurar la copia de seguridad del sitio web, detente y evalúa
La primera decisión es el alcance. No todos los incidentes requieren una reversión completa. Si un solo plugin rompió tu página de inicio pero los pedidos recientes todavía se registran en la base de datos, restaurar todo desde anoche podría arreglar el diseño mientras borra un día completo de transacciones. Ese no es un buen intercambio.
Comienza identificando qué cambió y cuándo. Verifica implementaciones recientes, actualizaciones de CMS, instalaciones de plugins, ediciones de temas, trabajos cron, importaciones de bases de datos e inicios de sesión de administradores. Si tu panel de hosting o pila de monitoreo muestra picos de errores, servicios fallidos o cambios en archivos, usa ese momento para acotar el punto de restauración limpio.
También querrás confirmar qué tipo de copia de seguridad tienes. Algunas copias de seguridad incluyen archivos y bases de datos en un solo archivo. Otras las almacenan por separado. Algunos proveedores ofrecen instantáneas a nivel de servidor, mientras que las copias de seguridad a nivel de aplicación solo capturan el sitio web en sí. Una instantánea completa del servidor puede ser útil, pero también puede revertir correos electrónicos, configuraciones, registros y aplicaciones no relacionadas en la misma máquina.
Es por eso que los operadores experimentados hacen primero una pregunta simple: ¿qué se necesita recuperar exactamente?
Cómo restaurar una copia de seguridad del sitio web sin empeorarlo
La ruta más segura es preservar el estado actual antes de tocar nada. Incluso si el sitio está roto, haz una copia de seguridad fresca o una instantánea del entorno dañado. Eso te da una opción de respaldo si el punto de restauración está incompleto, corrupto o es más antiguo de lo esperado.
A continuación, pon el sitio en modo de mantenimiento si es posible. Para sitios de comercio electrónico o membresía, esto ayuda a prevenir nuevas escrituras durante el proceso de restauración. Si no puedes usar el modo de mantenimiento, al menos bloquea los cambios de administrador y pausa los trabajos programados que podrían reintroducir datos incorrectos.
Luego verifica la integridad de tu copia de seguridad. Una copia de seguridad solo es útil si realmente se puede abrir y restaurar. Verifica el tamaño del archivo, la marca de tiempo, los componentes incluidos y si la copia de seguridad se completó con éxito. Si tienes varios puntos de restauración, compáralos. La copia de seguridad más reciente no siempre es la más segura, especialmente si el malware o los datos corruptos ya se habían propagado antes de que se creara.
Restaura archivos y base de datos en el orden correcto
La mayoría de los sitios web dependen de dos capas principales: archivos y base de datos. Los archivos incluyen el núcleo de tu CMS, plugins, temas, medios y archivos de configuración. La base de datos almacena publicaciones, usuarios, configuraciones, pedidos, envíos de formularios y datos de la aplicación. Si estas dos capas están desincronizadas, el sitio puede volver a funcionar a medias, lo que puede ser más difícil de diagnosticar que una interrupción completa.
Restauración de archivos del sitio web
Si tu problema está claramente relacionado con archivos, como medios eliminados, archivos de tema rotos o una implementación de código fallida, puede que solo necesites restaurar la raíz web o un directorio específico. Usa tu panel de control, administrador de copias de seguridad, SFTP o acceso a la línea de comandos para extraer la copia de seguridad en la ubicación correcta.
Ten cuidado con el comportamiento de sobrescritura. Una sobrescritura ciega puede eliminar activos recién cargados o cambios personalizados realizados después del punto de copia de seguridad. En algunos casos, restaurar un solo directorio como wp-content o una carpeta de temas es suficiente. En otros, especialmente después de un malware, un reemplazo limpio de todos los archivos de la aplicación es la opción más segura.
Verifica los permisos y la propiedad después de la restauración. Una razón común por la que los sitios restaurados fallan no es por contenido faltante, sino por permisos de archivo incorrectos, propiedad de usuario incorrecta o un archivo de configuración que ya no coincide con el entorno del servidor.
Restauración de la base de datos
Si la falla implica contenido faltante, datos de pago rotos, problemas de inicio de sesión, configuraciones de plugins o lógica de la aplicación, la base de datos suele ser parte del problema. Exporta la base de datos dañada actual antes de reemplazarla. Luego, importa la copia de seguridad seleccionada usando phpMyAdmin, Adminer, herramientas de línea de comandos o tu panel de hosting.
Este paso merece precaución. Restaurar una base de datos antigua en una tienda o sistema de reservas en vivo puede borrar pedidos, mensajes, tickets o registros de clientes recientes. Si el sitio permaneció parcialmente funcional después del incidente, considera una recuperación parcial en lugar de una importación completa. Por ejemplo, puedes restaurar solo ciertas tablas, o fusionar contenido manualmente si tu equipo tiene la capacidad técnica.
Los usuarios avanzados a menudo restauran la base de datos en un entorno de staging primero. Eso te da espacio para inspeccionar datos, probar el comportamiento de la aplicación y comparar registros antes de tocar producción.
Usa staging si el sitio es importante para los ingresos
Una restauración directa a producción es tentadora cuando la presión es alta. Pero si tu sitio web genera ventas, leads, suscripciones o soporte al cliente, probar primero suele valer la pena los pocos minutos extra.
Una restauración en staging te permite confirmar que la copia de seguridad está limpia, el sitio arranca correctamente, la base de datos se conecta y las funciones clave siguen funcionando. Puedes probar el inicio de sesión, el proceso de pago, los formularios, las integraciones de API, las rutas de imágenes, el comportamiento SSL y el acceso de administrador sin exponer a los visitantes a un sitio medio restaurado.
Esto es especialmente útil después de incidentes de seguridad. Si hubo malware presente, restaurar una copia de seguridad infectada simplemente reinicia el temporizador hasta que el sitio vuelva a fallar. En staging, puedes inspeccionar archivos sospechosos, plugins desactualizados, usuarios administradores inyectados y valores de configuración modificados antes de promocionar algo de vuelta a producción.
Para agencias y equipos que gestionan varios sitios web, staging también crea un registro de auditoría claro. Sabes qué se restauró, desde cuándo y qué se validó antes del lanzamiento.
No olvides el DNS, la caché y las dependencias externas
Una restauración de sitio web no siempre es solo una restauración de sitio web. A veces los archivos y la base de datos están bien, pero el sitio todavía parece roto porque se está sirviendo caché antigua, el DNS apunta al servidor incorrecto o una CDN está manteniendo contenido obsoleto.
Después de la restauración, limpia la caché de la aplicación, la caché del servidor, la caché de objetos y la caché de la CDN. Si tu sitio usa Redis, Varnish o caché de páginas en el panel de control, vacía también esas capas. Luego, verifica los registros DNS, los certificados SSL y cualquier configuración de proxy inverso si el entorno cambió.
También deberías revisar las dependencias externas. Las pasarelas de pago, los proveedores de SMTP, las claves API, los servidores de licencias y las integraciones de almacenamiento pueden fallar después de una restauración si las credenciales fueron rotadas o si la configuración restaurada apunta a un punto final obsoleto.
Esta es una razón por la que el soporte de infraestructuras gestionadas importa. Cuando la restauración afecta a más que el sitio web en sí, quieres a alguien supervisando todo el stack, no solo la carpeta public_html.
Qué revisar después de restaurar una copia de seguridad del sitio web
Una vez completada la restauración, prueba el sitio como un operador, no solo como un visitante. Abre la página de inicio, pero también prueba las partes menos visibles donde suelen ocultarse los fallos.
Verifica el inicio de sesión de administrador, los formularios de contacto, el flujo de pago, la búsqueda, las cuentas de usuario, la carga de medios, las redirecciones, los trabajos cron, SSL y la entrega de correos electrónicos. Revisa los registros de errores y los registros del servidor web en busca de advertencias que no aparecieron en el navegador. Si tu sitio tiene monitoreo, confirma que los tiempos de respuesta, el uso del disco, el estado de la base de datos y el estado del servicio han vuelto a la normalidad.
Para WordPress y plataformas CMS similares, verifica las versiones de plugins y las actualizaciones automáticas. Para aplicaciones personalizadas, confirma las variables de entorno, los workers de cola y los trabajos en segundo plano. Si la restauración involucró a todo el servidor, inspecciona las reglas del firewall, el comportamiento de inicio de servicios, el almacenamiento montado y los trabajos de copia de seguridad programados para no resolver una interrupción creando otra.
Si los clientes o los equipos internos pudieron haberse visto afectados, comunícate claramente. Diles qué se restauró, si es posible que falten datos recientes y qué medidas se están tomando para prevenir la repetición del problema.
El mejor plan de restauración comienza antes de la interrupción
La forma más fácil de restaurar con calma es construir tu estrategia de copias de seguridad en torno a la recuperación, no solo a la retención. Eso significa tener copias de seguridad en intervalos útiles, mantener varios puntos de restauración, separar los archivos de las bases de datos cuando sea práctico y probar las restauraciones antes de que una emergencia fuerce el problema.
También significa elegir un hosting que no te deje solo cuando algo falla a las 2:00 a.m. Una buena herramienta de copia de seguridad ayuda, pero el soporte humano sigue siendo importante cuando necesitas decidir entre una reversión de archivos, una importación parcial de base de datos, una restauración de instantánea o una reconstrucción limpia. En kodu.cloud, esa capa operativa es parte del valor porque el tiempo de inactividad rara vez llega con documentación clara.
Si recuerdas una cosa, que sea esta: restaura la pieza limpia más pequeña que solucione el problema, pruébala adecuadamente y conserva el estado dañado hasta que estés seguro de que la recuperación está completa.
Andrés Saar, Ingeniero de Atención al Cliente