Arranque en frío en lugar de copia de seguridad: reconstruir un sitio web en 30 minutos

Hace unos días la web de mi empresa estaba en blanco. Sin contenido, sin mensaje de error, sin acceso al panel de administración. Treinta minutos después volvía a funcionar, no desde una copia de seguridad sino desde una reconstrucción completa partiendo de cero. Este artículo describe ese arranque en frío paso a paso: qué se borra, en qué orden, qué se vuelve a levantar después y qué condiciones lo hacen posible. Al final llega la clasificación de por qué un arranque en frío no sustituye a una copia de seguridad, sino que hace algo distinto.

Contenido

• El sitio estaba en blanco
• Por qué buscar el fallo es la trampa
• Qué requiere un arranque en frío
• Por qué el diseño es la parte más molesta
• Paso 1: inventario de lo que solo vive en el servidor
• Paso 2: separar el dominio del espacio web
• Paso 3: borrar todos los archivos, de verdad todos
• Paso 4: eliminar la base de datos, no vaciarla
• Paso 5: instalar WordPress desde cero
• Paso 6: ejecutar el despliegue
• Paso 7: plugins, textos legales y banner de cookies
• Paso 8: la lista de aceptación
• Los 30 minutos en detalle
• Lo que el arranque en frío no recupera
• El resto manual: lo que el proveedor no ofrece
• Arranque en frío o copia de seguridad?
• Practicar el arranque en frío sin arriesgar el sitio en producción
• FAQ
• Conclusión
• Fuentes

El sitio estaba en blanco

Cargar la página de inicio devolvía una respuesta vacía. Sin diseño, sin texto, sin mensaje de error en el navegador, porque mostrar errores de PHP está desactivado con razón en un servidor productivo. El backend en /wp-admin se comportaba igual: página en blanco, sin formulario, sin manera de iniciar sesión.

El sitio había funcionado durante semanas sin queja alguna, y en esas semanas no había habido ningún despliegue, así que ninguna línea de código nueva entraba como causa posible. Lo que hubiera pasado, no lo había provocado un cambio mío.

La salida evidente era la copia de seguridad del proveedor. No se pudo convertir en un sitio que funcionara. Con eso quedó descartada la opción cómoda y sobre la mesa la pregunta de verdad: reparar o reconstruir?

Lo que está en juego es más de lo que suena al hablar de la web de una empresa. En ese sitio están el aviso legal y la política de privacidad, y ambos tienen que ser accesibles mientras la oferta esté en línea. Un sitio que no entrega nada es por tanto más que un problema de imagen.

Por qué buscar el fallo es la trampa

El reflejo que suena profesional es el diagnóstico. Desactivar plugins uno a uno, cambiar el tema por uno estándar, activar WP_DEBUG, subir el límite de memoria, repasar los registros del proveedor. Todo eso es correcto si la causa aparece en cuestión de minutos.

Es incorrecto cuando no aparece. Buscar un fallo no tiene límite superior. No entrega un resultado en un momento que puedas comprometer, y en una incidencia esa es la propiedad que lo decide todo. Una reconstrucción, en cambio, tiene una duración conocida. Quien conoce las dos cifras no necesita discutir: si la reconstrucción tarda media hora, la búsqueda no puede tragarse dos.

A eso se suma un argumento que pesa más. Una página en blanco sin causa visible puede ser una intrusión. En ese caso reparar es la respuesta equivocada, porque nadie sabe qué más hay en el sistema de archivos y en la base de datos. Borrar es entonces el único camino limpio.

El orden que se deriva de ahí es este: reconstruir primero, para que el sitio vuelva a estar en línea. Investigar la causa después, sin presión de tiempo y sobre una copia, si se quiere saber.

Qué requiere un arranque en frío

Un arranque en frío no es un truco de destreza. Es la consecuencia de una decisión tomada mucho antes. Solo funciona si el sitio no existe exclusivamente en el servidor.

El contenido está versionado, es decir estructura de páginas, textos e imágenes como archivos en un repositorio y no solo como filas de una base de datos. La configuración está descrita en lugar de pulsada, es decir menús, página de inicio, estructura de enlaces permanentes y opciones del tema. La lista de plugins forma parte de esa descripción y no de mi memoria. Los textos legales también están versionados. Y existe un paso de despliegue repetible que produce el sitio completo a partir de esa descripción.

Con eso cambia el estatus de la instalación en marcha. Se puede tirar, porque se puede volver a crear en cualquier momento sin que nadie tenga que pensar.

El principio no es nuevo, es la versión para sitios web de la infraestructura inmutable: los servidores se sustituyen en lugar de cuidarse. Nuevo es, como mucho, lo poco que se aplica a sitios web. La mayoría de las webs corporativas son piezas únicas que fueron creciendo y cuyo origen ya nadie puede reconstruir, y por eso allí la copia de seguridad sigue siendo la única esperanza.

Por qué el diseño es la parte más molesta

Las páginas y las entradas se pueden exportar, WordPress trae una herramienta propia para eso. Lo que dificulta un arranque en frío es el aspecto, y el motivo es estructural: el diseño vive en la base de datos y no en archivos.

Los ajustes del tema están como un único valor serializado en la tabla de opciones, bajo un nombre que contiene el nombre del tema. Los menús son entradas de una taxonomía más registros propios que apuntan a IDs de páginas. La asignación de las zonas de widgets es otra opción. Y cuando entra en juego un maquetador visual, la maquetación completa de cada página está como un bloque serializado grande en los metadatos de esa página, con URLs absolutas e IDs numéricos dentro.

Tras una reinstalación el contenido ha vuelto y el aspecto está desnudo. Colores, tamaños de letra, espaciados, cabecera y pie, la asignación de la página de inicio y cada ajuste que alguna vez se movió en un control son valores por defecto. Reconstruir eso a mano no es cosa de diez minutos, sino de una tarde, y nunca queda idéntico, porque nadie recuerda el valor de cada control.

A eso se suma que los IDs son nuevos. Un WordPress recién instalado reparte números nuevos para páginas y medios. Si copias de vuelta sin más los datos de diseño de un maquetador, no obtienes un mensaje de error, sino imágenes desaparecidas y enlaces que apuntan a la página equivocada. En eso fracasan las migraciones ingenuas, en silencio y sin aviso.

O el diseño vive como código en el tema, es decir plantillas y CSS en un repositorio, y entonces simplemente está ahí tras el despliegue. O los ajustes de diseño se exportan como archivos y se vuelven a colocar en la importación, y entonces la importación tiene que reescribir los IDs antiguos a los recién asignados, normalmente mediante nombres únicos en lugar de números.

Con un diseño hecho con maquetador un arranque en frío es bastante más difícil, porque los datos del maquetador son el diseño. Quien va por ese camino debería saber que se ata a su copia de seguridad. Para nuestro propio sitio ese fue uno de los motivos para llevar el aspecto al tema como código, y esta incidencia fue la factura que se emitió por esa decisión.

Paso 1: inventario de lo que solo vive en el servidor

Antes del primer borrado va una pregunta que a nadie le gusta hacerse. Qué existe exclusivamente en este servidor y en ningún otro sitio? Todo lo que entre ahí desaparece tras el borrado, y la decisión al respecto se toma ahora, no después.

Los candidatos típicos son la carpeta de subidas con medios que nunca llegaron al repositorio, envíos del formulario de contacto, comentarios, estadísticas de acceso y textos que en algún momento se editaron directamente en el backend. Este último es el más peligroso, porque es invisible. Una redacción corregida en el backend se ve en línea igual que una versionada, pero se comporta al contrario durante un arranque en frío.

En la práctica este paso lleva unos pocos minutos: descargar la carpeta de subidas por FTP, sacar un volcado de la base de datos y guardar la lista de plugins. El volcado vale la pena incluso si no se puede restaurar, porque es el material para el análisis posterior de la causa.

Paso 2: separar el dominio del espacio web

Este paso va antes del borrado, y el orden no es un detalle. Mientras el dominio apunte al directorio defectuoso, estás trabajando sobre el sistema accesible al público. Visitantes, rastreadores y monitorización ven entonces cada estado intermedio: la instalación medio vaciada, un listado de directorio desnudo y, en el peor caso, el asistente de instalación de WordPress.

Ese último caso es el grave, y es peor de lo que parece a primera vista. Un WordPress sin wp-config.php manda a cada visitante a la instalación, y esa instalación no pide nada más que una base de datos accesible. Un atacante indica la suya, el instalador escribe esas credenciales en el wp-config.php, y a partir de ahí bajo tu dominio corre un sitio que funciona sobre una base de datos ajena. Basta una sola petición. Wordfence describió la técnica en 2017 como ataque WPSetup, y sigue funcionando porque no aprovecha ninguna vulnerabilidad, sino el flujo previsto. Una ventana de mantenimiento de diez minutos basta para eso.

O sueltas la asignación del dominio en el panel de hosting y lo haces apuntar a una página estática de mantenimiento, o levantas la nueva instalación en paralelo en un segundo directorio y cambias el dominio solo al final. La segunda vía es la mejor, porque el tiempo de caída se reduce a un único clic.

Un cambio en la asignación del dominio puede provocar una reemisión del certificado, y eso lleva sus minutos. Y quien toque el DNS en lugar del directorio espera además el periodo de validez del registro antiguo. Por eso lo mejor es no tocar el registro DNS.

Paso 3: borrar todos los archivos, de verdad todos

En el directorio del documento después no queda nada.

wp-admin/
wp-includes/
wp-content/          completa, incluidas uploads, plugins, themes, mu-plugins
wp-config.php
wp-config-sample.php
index.php
xmlrpc.php
wp-*.php             todos los demás archivos con este patrón
.htaccess
.user.ini            y todos los demás archivos ocultos

El reflejo de conservar wp-content es comprensible y es exactamente el punto en el que un arranque en frío deja de serlo. Ahí no solo hay imágenes y plugins. Ahí también están los mu-plugins, que WordPress carga sin activación, drop-ins como object-cache.php y advanced-cache.php, que se enganchan al núcleo, directorios de caché generados y, en caso de intrusión, los archivos más interesantes de todos. Quien se lleva esa carpeta ha reinstalado conservando el estado antiguo.

Sin acceso SSH esto va por FTP o por el gestor de archivos del proveedor, y ambos son lentos con miles de archivos pequeños. Es más rápido borrar el directorio del documento entero y volver a crearlo, si el proveedor lo permite. Y el cliente FTP tiene que mostrar los archivos ocultos, porque si no el .htaccess antiguo se queda ahí y escribe reglas de reescritura para una instalación que ya no existe.

Paso 4: eliminar la base de datos, no vaciarla

Vaciar tablas se siente limpio y no lo es. Quedan atrás las estructuras de tablas de versiones antiguas de plugins, filas huérfanas en wp_options, opciones con autoload activado que se cargan en cada petición, transients caducados y valores serializados defectuosos con los que PHP falla en silencio. En caso de intrusión se suman entradas en wp_users y wp_usermeta que a primera vista parecen inofensivas.

Por eso la base de datos se descarta y se crea de nuevo, con usuario nuevo y contraseña nueva. El usuario nuevo importa, porque las credenciales antiguas pueden haber sido la causa.

DROP DATABASE base_datos_antigua;

CREATE DATABASE base_datos_nueva
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_520_ci;

CREATE USER 'usuario_nuevo'@'localhost' IDENTIFIED BY 'contrasena-recien-generada';
GRANT ALL PRIVILEGES ON base_datos_nueva.* TO 'usuario_nuevo'@'localhost';
FLUSH PRIVILEGES;

En espacios web alquilados esto a menudo no se puede hacer así, porque DROP DATABASE y la creación de usuarios no se ofrecen en la interfaz web. En ese caso borras la base de datos en el panel del proveedor y creas una nueva. El resultado es el mismo, el camino es trabajo manual. El artículo vuelve más abajo sobre este punto.

La indicación del juego de caracteres no es un adorno. Si aquí te desvías del ajuste anterior, obtienes caracteres especiales corruptos al importar el contenido, y el daño no se ve en la página de inicio sino en textos antiguos que se abren pocas veces.

Paso 5: instalar WordPress desde cero

Ahora la versión actual de WordPress entra en el directorio vacío. Tres cosas se fijan a conciencia en lugar de heredarse.

La versión de PHP la eliges tú en lugar de aceptar el valor por defecto del proveedor. Un arranque en frío es el momento más barato para pasar a una versión actual, porque de todos modos todo llega nuevo y las incompatibilidades se muestran de inmediato en lugar de dentro de seis meses.

El wp-config.php se escribe de nuevo y no se recupera de la copia. Contiene los datos nuevos de la base de datos y claves de seguridad frescas. Las claves nuevas invalidan cada sesión existente y cada cookie de acceso puesta, y eso es justo lo que se busca. A eso se suman los ajustes que este proveedor necesita, por ejemplo un método fijo para el acceso al sistema de archivos, para que las instalaciones no pidan credenciales FTP.

Lo que más se pasa por alto es la visibilidad para los motores de búsqueda. Una instalación nueva se puede configurar para impedir la indexación, y ese ajuste sobrevive toda la reconstrucción sin que se note. Igual de importante es la estructura de enlaces permanentes. Si no está como antes, todas las subpáginas responden con 404 aunque el contenido esté completo.

Paso 6: ejecutar el despliegue

La parte que hace posibles los 30 minutos es la más corta. Un paso de despliegue devuelve tema, estructura de páginas, textos, imágenes, menús y ajustes, porque todo ello existe como descripción.

Qué tecnología hay detrás es secundario para este artículo. El paso es repetible, es decir produce el mismo resultado desde el mismo estado de partida, y es idempotente, una segunda ejecución ya no cambia nada. Eso suena académico y se paga durante una incidencia, porque entonces rara vez se sabe con seguridad qué ha corrido ya y qué no.

Una copia de seguridad produce un estado cuyo origen nadie conoce. Un despliegue produce un estado cuyo origen existe como descripción y por eso se puede comprobar.

Aun así hay un orden dentro de este paso, y no es arbitrario. Los medios van antes que el contenido, porque el contenido remite a IDs de medios. El contenido va antes que los menús, porque las entradas de menú apuntan a IDs de páginas. Los ajustes van al final. Si le das la vuelta al orden no obtienes un error, sino referencias silenciosas al vacío, y eso es lo peor de las dos variantes.

El aspecto viene incluido en este paso porque vive en el tema como código y no en la tabla de opciones. Esa es exactamente la diferencia entre 30 minutos y una tarde.

Paso 7: plugins, textos legales y banner de cookies

En este punto la lista de plugins no es un ejercicio de memoria. Está en la descripción, y se reconstruye en un orden determinado.

Primero la gestión del consentimiento, es decir el banner y las reglas sobre qué servicios quedan bloqueados antes de la aceptación. En Alemania el consentimiento para acceder a dispositivos finales está regulado en el artículo 25 de la TDDDG, y la ley lleva ese nombre desde el 13 de mayo de 2024, antes se llamaba TTDSG. Lo técnicamente necesario, como una cookie de sesión, queda exento; todo lo demás necesita una aceptación activa. Un banner que aparece después de poner las cookies no cumple su propósito.

Después los textos legales. El aviso legal y la política de privacidad pertenecen al arranque en frío y no a un añadido por la noche. En Alemania la obligación de aviso legal está desde el 14 de mayo de 2024 en el artículo 5 de la DDG, en el lugar donde antes estaba el artículo 5 de la TMG. Si los textos vienen de un despacho de abogados o de un servicio, hay que reconstruir ese vínculo. El texto en sí pertenece al repositorio, porque si no desaparece tras el borrado igual que todo lo demás de la base de datos.

Después llegan el formulario de contacto y el envío de correo. El envío por una cuenta SMTP hay que volver a configurarlo, incluidas credenciales y dirección del remitente. La experiencia dice que este es el punto que se olvida en el primer arranque en frío, porque no se puede mirar. No ves nada, simplemente no llega ningún correo.

A propósito no está todo aquello de lo que querías deshacerte de todos modos. Un arranque en frío es el momento más barato para acortar una lista de plugins, porque no hay que desinstalar nada. Simplemente no se vuelve a instalar.

El motivo por el que este orden tiene que estar terminado antes de cambiar el dominio está en el paso 2: el sitio no debe ser accesible al público sin aviso legal y sin banner de consentimiento, ni siquiera durante diez minutos.

Paso 8: la lista de aceptación

El sitio no está listo cuando la página de inicio se ve como antes. Está listo cuando se ha recorrido una lista. Mirarlo es justo la manera de pasar por alto las cosas que no se pueden ver.

la página de inicio responde con 200
tres subpáginas responden con 200
una URL inventada responde con 404, no con 200
aviso legal y política de privacidad accesibles y enlazados en el pie
el banner de consentimiento aparece en una ventana privada
rechazar no pone cookies opcionales
el formulario de contacto envía un correo, y llega
todas las imágenes cargan por https, sin aviso de contenido mixto
certificado válido, también para la variante www
sin directiva noindex en el código fuente
sitemap accesible
las redirecciones de las URLs antiguas funcionan
acceso de administrador con las credenciales nuevas

Dos de esos puntos se comprueban en segundos y son aun así los que más se pasan por alto:

curl -s -o /dev/null -w "%{http_code}n" https://tu-dominio.com/
curl -s https://tu-dominio.com/ | grep -i "noindex"

La segunda línea no debe imprimir nada. Si imprime algo, el sitio está en línea e invisible para los motores de búsqueda, y ese estado se nota si no cuando las visitas se hunden.

Los 30 minutos en detalle

El tiempo no está donde se espera. Desglosada, la ejecución quedó aproximadamente así:

La partida más lenta es el borrado por FTP, no la reconstrucción. El despliegue en sí es la parte más corta de todo el proceso, y ese es el verdadero sentido del ejercicio.

En esta tabla falta una fila que en la mayoría de los sitios sería la mayor: el diseño. Si no estuviera descrito como código en el tema sino pulsado en la base de datos, aquí tendría que haber una partida de varias horas, y los 30 minutos serían otra cifra.

Lo que no está en esta cuenta es el análisis de la causa. Ese vino después, sobre una copia, sin presión de tiempo y sin que dependiera de ello un sitio accesible al público.

Lo que el arranque en frío no recupera

Todo lo que vivía exclusivamente en la base de datos ha desaparecido. Envíos de formularios, comentarios, estadísticas de acceso y cada texto que en algún momento se editó directamente en el backend. Un arranque en frío devuelve lo que está descrito, y solo eso.

De ahí se deriva una regla de trabajo más difícil de sostener que la parte técnica. Quien mantiene su sitio como código tiene que hacer los cambios también ahí. Cada corrección que ocurre solo en el backend hace que el estado en producción se aleje de la descripción, y el siguiente arranque en frío la tira en silencio. El método es por tanto solo tan bueno como la disciplina con la que se usa.

Justo en este punto las copias de seguridad siguen siendo imprescindibles. Son la respuesta a los datos que no se pueden reproducir, y casi todos los sitios tienen algunos.

El resto manual: lo que el proveedor no ofrece

La parte honesta de esta historia es el proveedor. El hosting clásico no ofrece ninguna interfaz para lo que aquí se necesitaba: soltar la asignación de un dominio, vaciar un directorio, descartar y crear una base de datos, fijar la versión de PHP, reemitir un certificado. Son clics en una interfaz web, en un orden propio, y son el motivo de que 30 minutos no se conviertan en tres.

En una infraestructura de nube de verdad esta parte también estaría descrita en lugar de pulsada. Entonces no solo el sitio sería reproducible, sino también el entorno en el que corre, y el arranque en frío sería un procedimiento en lugar de trabajo manual. Esa es la continuación más interesante de esta historia, y lleva al mismo lugar en el que de todos modos trabajamos con Vela Atlas: entornos que surgen de una descripción y por eso son repetibles.

En esta incidencia el sitio web era reproducible, su entorno no. La diferencia costó unos diez minutos de clics, y esos diez minutos son la única parte del proceso que no se puede practicar, porque cada vez es igual de aburrida e igual de propensa a errores.

Arranque en frío o copia de seguridad?

La pregunta está mal planteada, porque cada una gira un mando distinto. Dos cifras de la recuperación ante desastres lo hacen tangible.

El tiempo de recuperación, habitualmente llamado RTO, describe cuánto tarda en volver a funcionar la operación. La pérdida de datos máxima tolerada, el RPO, describe cuántos datos pueden perderse en el proceso. Un arranque en frío baja el tiempo de recuperación, porque funciona con independencia de que una copia sea utilizable. No cambia nada en la pérdida de datos. Las copias de seguridad bajan la pérdida de datos y no dicen nada sobre la duración.

Quien quiere las dos cosas necesita las dos. El complemento práctico es la regla conocida de mantener varias copias en soportes distintos y una de ellas fuera de casa. Y la frase que exige la misma prueba a ambos lados: una copia que nunca se ha restaurado es una suposición. Un arranque en frío que nunca se ha practicado también lo es.

Practicar el arranque en frío sin arriesgar el sitio en producción

Esto se puede practicar sin riesgo, o en un subdominio con su propia base de datos o en un contenedor local. El procedimiento es el mismo que en el caso real: borrar todo, ejecutar el despliegue, recorrer la lista, medir el tiempo.

El valor no está en el tiempo sino en lo que salta a la vista. Siempre hay un ajuste que existía solo en la cabeza de alguien y en ninguna descripción. En mi caso fue el envío de correo. Tras la primera ejecución estaba en la descripción, y en la incidencia real ya no fue un tema.

Una ejecución por trimestre basta. Cuesta media hora y sustituye al debate sobre si las copias funcionarán.

FAQ

No sería buscar el fallo el camino más profesional? Es el camino más profesional cuando la causa se encuentra rápido. Sin presupuesto de tiempo es un cheque en blanco, porque un diagnóstico no garantiza resultado en un momento fijo y una reconstrucción de duración conocida sí. La causa se puede aclarar después sobre una copia, con calma.

No basta con conservar wp-content y reinstalar solo el núcleo? Para una reparación rápida sí, para un arranque en frío no. En wp-content hay mu-plugins que se cargan sin activación, drop-ins como object-cache.php, directorios de caché generados y, en caso de intrusión, los archivos realmente interesantes. Conservar la carpeta significa llevarse el estado antiguo.

Por qué en WordPress el diseño es más difícil de recuperar que el contenido? Porque vive en la base de datos y no en archivos. Los ajustes del tema están como valor serializado en la tabla de opciones, los menús como entradas de taxonomía con referencias a IDs de páginas, y con un maquetador visual la maquetación de cada página está en sus metadatos. Tras una reinstalación los IDs son nuevos, y por eso copiarlo de vuelta sin más falla en silencio. Solo se vuelve fiable cuando el aspecto vive como código en el tema.

Hay que borrar de verdad la base de datos, o basta con vaciar las tablas? Se descarta. Vaciar deja atrás estructuras de tablas de versiones antiguas de plugins, opciones huérfanas con autoload activado, valores serializados defectuosos y posibles cuentas de usuario ajenas. Nombre de base de datos nuevo, usuario nuevo, contraseña nueva.

Por qué hay que quitar el dominio antes de borrar? Porque un WordPress sin wp-config.php manda a cada visitante a la instalación y solo pide una base de datos accesible. Un atacante indica la suya y a partir de ahí opera el sitio bajo tu dominio. Wordfence lo describe como ataque WPSetup. Basta una ventana de mantenimiento corta.

Qué pasa con las cuentas de correo, los registros DNS y el certificado? Las cuentas de correo y los registros DNS no dependen del espacio web en el proveedor y se mantienen mientras no los toques. Justo por eso el registro DNS queda intacto y el cambio ocurre a través de la asignación del directorio. El certificado puede necesitar una reemisión, y eso hay que preverlo.

Sustituye un arranque en frío a las copias de seguridad? No. Sustituye la dependencia de que una copia funcione en el momento decisivo. Para datos que no se pueden reproducir, como envíos de formularios o pedidos, las copias siguen siendo la única respuesta.

Qué significan RTO y RPO aquí concretamente? El tiempo de recuperación (RTO) es la duración hasta que la operación vuelve a funcionar, la pérdida de datos máxima tolerada (RPO) es la cantidad de datos que puede perderse en el proceso. El arranque en frío mejora la primera cifra, las copias mejoran la segunda. Son dos mandos, no una elección entre uno y otro.

Funciona esto también con un creador de webs? Solo de forma limitada. Un creador de webs mantiene contenido y configuración en su propio sistema, y lo que no se puede exportar y volver a importar tampoco se puede reconstruir. El arranque en frío exige que el sitio esté descrito por completo fuera de su entorno de ejecución.

Tiene que seguir siendo accesible el aviso legal durante el mantenimiento? El camino seguro es hacer que el dominio apunte durante la reconstrucción a una página estática de mantenimiento que contenga el aviso legal y la política de privacidad. Con eso la pregunta se resuelve, y el esfuerzo es un único archivo HTML.

Conclusión

La recuperación no es la pregunta de si existe una copia de seguridad, sino de si es posible un arranque en frío. Quien mantiene contenido, configuración, lista de plugins y textos legales como descripción cambia una esperanza por un procedimiento: la instalación en marcha se vuelve sustituible, y una incidencia pasa a ser media hora de trabajo con final conocido en lugar de una búsqueda de final abierto.

El siguiente paso es pequeño. Coge tu propio sitio y escribe qué existe solo en el servidor y en ningún repositorio. Esa lista es la diferencia entre un arranque en frío y una reconstrucción de memoria.

Fuentes

• Documentación de WordPress sobre reinstalación, wp-config.php y claves de seguridad, wordpress.org
• Wordfence, The WPSetup Attack, sobre la toma de control de instalaciones nuevas a través de la página de instalación, wordfence.com
• Artículo 5 de la Digitale-Dienste-Gesetz (DDG), desde el 14 de mayo de 2024 en el lugar del artículo 5 de la TMG
• Artículo 25 de la Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), desde el 13 de mayo de 2024 el nombre de la antigua TTDSG
• Reglamento (UE) 2016/679 (Reglamento General de Protección de Datos), artículo 32 sobre seguridad del tratamiento
• Compendio IT-Grundschutz del BSI, módulo CON.3 sobre concepto de copias de seguridad, bsi.bund.de

Todos los ejemplos proceden de la incidencia real y están escritos desde cero. Este artículo es un informe de experiencia práctica y no asesoramiento jurídico. Para tu caso concreto, consulta a un abogado.