Restaurar es la parte que nadie practica hasta que la necesita, y normalmente se necesita con prisa: el sitio caído, un cliente esperando, y una copia que nadie sabe si sirve. Esta guía explica qué restaurar según lo que se rompió, porque restaurar de más hace tanto daño como no restaurar.

Antes de tocar nada: identifica qué se rompió

Una restauración no se deshace. Estos son los tres escenarios que llegan a soporte y qué corresponde en cada uno:

• Rompiste el sitio actualizando o instalando algo (pantalla en blanco, error 500, el diseño desarmado). Se restauran sólo los archivos. La base de datos está sana y si la pisas, pierdes todo lo publicado desde la fecha de la copia.
• Se dañó o se borró contenido (entradas que desaparecieron, pedidos perdidos, una tabla corrupta). Se restaura sólo la base de datos. Los archivos están bien.
• El sitio está infectado o hay que moverlo entero. Ahí sí va la cuenta completa, y conviene que lo hagamos nosotros.

Si no sabes en cuál de los tres estás, escríbenos antes de restaurar. Deshacer una restauración mal hecha cuesta mucho más que hacer un diagnóstico de cinco minutos.

Restaurar sólo los archivos del sitio

1. Abre el Administrador de archivos y sube tu copia (el .zip o .tar.gz) a la carpeta del sitio.
2. Antes de extraer, renombra la carpeta actual. Si tu web está en public_html, no la borres: crea una carpeta public_html_viejo y mueve ahí lo que hay. Si la restauración sale mal, tienes a dónde volver.
3. Extrae la copia en su lugar.
4. Revisa que quedó la estructura correcta. El error más común es terminar con public_html/public_html/index.php porque el zip traía la carpeta dentro. Si te pasa, mueve el contenido un nivel hacia arriba.
5. Abre el sitio. Si carga, borra la carpeta vieja cuando estés seguro, no antes.

Restaurar sólo la base de datos

Hay dos caminos, y la diferencia entre ellos arruina más restauraciones de las que uno imagina.

Desde cPanel → Copias de seguridad. En la sección Restaurar una copia de seguridad de la base de datos MySQL subes tu archivo .sql o .sql.gz y listo. Este es el camino recomendado: no tiene límite práctico de tamaño.

Desde phpMyAdmin. Sirve, pero tiene un tope de subida de alrededor de 50 MB. Y el problema no es que falle con un error claro: muchas veces la importación se corta a la mitad y te deja una base parcialmente restaurada, que arranca, parece funcionar, y tres días después descubres que faltan tablas. Si tu .sql pesa más de 40 MB, usa el camino de cPanel.

Lo que hay que revisar después de restaurar

El sitio puede cargar y aun así estar mal configurado. Estas cuatro comprobaciones toman dos minutos y evitan la mayoría de los llamados de vuelta:

1. Las credenciales de la base. Si restauraste archivos de otro servidor o de otra cuenta, el wp-config.php trae el nombre de base, usuario y contraseña viejos. Tienen que coincidir con los de esta cuenta, o verás el clásico «Error al establecer una conexión con la base de datos».
2. Los enlaces permanentes. Entra a Ajustes → Enlaces permanentes y pulsa Guardar sin cambiar nada. Eso reescribe el .htaccess y arregla las páginas internas que dan 404.
3. El certificado y las direcciones. Si el sitio quedó apuntando a http://, revisa la dirección en Ajustes → Generales.
4. Una página interna, no sólo la portada. La portada suele cargar de caché aunque el resto esté roto.

Cuándo pedirnos que lo hagamos nosotros

Hay tres casos en los que no vale la pena que lo intentes solo, porque requieren acceso que tu cuenta no tiene:

• Restauración de la cuenta completa, incluyendo cuentas de correo y configuración.
• Sitio infectado. Restaurar una copia que ya venía infectada sólo reinstala el problema; hay que identificar primero desde cuándo está y elegir una copia anterior a eso.
• No tienes copia propia. El servidor genera copias, pero pedirlas y recuperarlas de ahí lo hacemos nosotros.

Para cualquiera de los tres, abre un ticket indicando el dominio, qué pasó y desde cuándo. Con la fecha aproximada del problema podemos elegir la copia correcta.