Cómo crear un plan de recuperación ante desastres para tu web WordPress

Nadie piensa en un plan de recuperación hasta el día en que abre su web y ve una pantalla en blanco o, peor todavía, una página de «Hacked by…». Ahí aparecen las preguntas que deberías haberte hecho antes: ¿dónde está la última copia funcional? ¿Quién tiene las contraseñas? ¿Cuánto se tarda en volver a estar en línea? Un plan de recuperación ante desastres es exactamente eso: las respuestas a esas preguntas, preparadas de antemano, para no tener que buscarlas bajo presión.

No hablamos de algo reservado a corporaciones con departamentos de informática enteros. Si tu web trae clientes, pedidos o simplemente representa a tu negocio, necesitas un plan así. La buena noticia es que cabe en una sola página.

Qué puede salir mal, en realidad

En casi dos décadas ocupándonos de webs WordPress, hemos visto repetirse los mismos cuatro escenarios, sea cual sea el tamaño del negocio. Los enumero sin dramatismo, porque cada uno tiene solución si estás preparado:

• Una web hackeada. Alguien te inyecta código, redirige a tus visitantes a otras páginas o roba los datos de tus clientes. Suele empezar por un plugin desactualizado.
• Una actualización fallida. Pulsas «Actualizar» en un plugin o un tema y, en lugar de una versión nueva, recibes un error fatal. La web se queda bloqueada justo cuando más la necesitabas.
• El servidor caído. El proveedor de alojamiento tiene una avería, un disco falla o la cuenta queda suspendida. No depende de ti, pero te afecta directamente.
• El error humano. Borras una página por equivocación, sobrescribes contenido, publicas un cambio directamente en producción. Le pasa incluso a gente con experiencia, en un día ajetreado.

¿Ves lo que tienen en común? Ninguno avisa antes. Precisamente por eso la preparación cuenta más que la reacción.

Cómo prepararte: las cuatro piezas del plan

Un buen plan no necesita decenas de herramientas. Necesita cuatro cosas bien colocadas.

1. Una copia externa y probada

Aquí es donde falla la mayoría. Tienen una copia, pero está en el mismo servidor que la web. Cuando el servidor cae o queda comprometido, la copia de seguridad desaparece junto con el original. Una copia de verdad vive en otro sitio: en la nube, en otro servidor, en algún lugar del que puedas recuperarla incluso si tu alojamiento actual deja de existir.

Y aún más importante: una copia que nunca has restaurado es solo una suposición. Hemos conocido clientes convencidos de estar cubiertos hasta que el archivo resultó estar corrupto o incompleto justo el día en que lo necesitaban. Por eso insistimos en que cada copia se pruebe, no solo se genere. Si quieres quitarte esa preocupación, nuestro servicio de copias de seguridad WordPress se ocupa de copias externas, automáticas y verificadas periódicamente.

2. Accesos documentados

En una crisis pierdes un tiempo precioso buscando contraseñas en correos antiguos. Anota en un sitio seguro (un gestor de contraseñas, no un archivo de texto en el escritorio) todo lo que necesitarías para reconstruir la web desde cero:

• los datos de acceso al alojamiento y al panel de control (cPanel, Plesk o equivalente);
• el usuario y la contraseña de administrador de WordPress;
• el acceso FTP/SFTP y a la base de datos;
• dónde está registrado el dominio y quién lo controla;
• los contactos de los proveedores, con los teléfonos de soporte.

Si mañana no estuvieras disponible, ¿podría otra persona del equipo iniciar la recuperación con lo que has anotado? Si la respuesta es «no», el plan tiene un agujero.

3. RTO y RPO, en lenguaje claro

Dos términos técnicos que suenan complicados pero significan cosas sencillas. Merece la pena entenderlos, porque determinan con qué frecuencia haces copias y qué alojamiento eliges.

RTO (Recovery Time Objective) responde a la pregunta «¿en cuánto tiempo tengo que volver a estar en línea?». Para una tienda online en plena temporada, una hora de caída puede suponer pérdidas serias, así que el RTO es corto. Para un blog personal, un día no es ninguna tragedia.

RPO (Recovery Point Objective) responde a «¿cuántos datos puedo permitirme perder?». Si haces copia una vez al día y el desastre llega por la tarde, puedes perder todos los pedidos del día. Si eso es inaceptable, necesitas copias más frecuentes. Una tienda activa quiere un RPO de unas pocas horas; una web corporativa que cambia poco se apaña con uno diario.

En resumen: el RTO es cuánto tardas en volver, el RPO es cuánto trabajo pierdes. Los fijas en función de lo que te cuesta realmente cada hora fuera de línea.

4. Pasos de restauración, escritos de antemano

En plena crisis, la memoria falla. Un plan útil tiene los pasos anotados con claridad, como una receta que sigues con calma: dónde entras, qué copia eliges, en qué orden restauras los archivos y la base de datos, cómo compruebas que todo funciona después. No hace falta que sea complicado, solo que exista negro sobre blanco.

Un escenario concreto

Veamos el plan en acción. Tienes una tienda online. El martes por la mañana, un cliente te llama molesto: entra en la web y le redirige a una página dudosa de productos farmacéuticos. Eres víctima de un hackeo que empezó por un plugin desactualizado.

Sin plan, entrarías en pánico: buscarías contraseñas, llamarías desesperado al alojamiento, intentarías borrar a mano código que no entiendes y, mientras tanto, perderías ventas y la confianza de tus clientes.

Con un plan bien hecho, las cosas van de otra manera. Abres el documento con los accesos y los pasos de restauración. Pones la web temporalmente en mantenimiento para que los visitantes dejen de estar expuestos. Eliges la última copia externa limpia, la anterior a la infección. La restauras siguiendo los pasos anotados, después cambias todas las contraseñas y actualizas el plugin culpable. En aproximadamente una hora vuelves a estar en línea, con pérdidas mínimas. La diferencia entre las dos versiones no es la suerte: es la preparación.

Cómo probar tu plan

Un plan que nunca has ensayado es una bonita teoría. Probarlo no significa esperar al desastre, sino simularlo en un entorno seguro:

• Restaura en un entorno de pruebas. Coge la última copia y reconstruye la web en un subdominio o en un servidor aparte. Si lo consigues ahí, lo conseguirás cuando cuente.
• Cronométralo. Anota cuánto tardaste realmente. Si es mucho más que tu RTO objetivo, algo hay que ajustar: o el alojamiento o el procedimiento.
• Comprueba la integridad. No basta con que la web arranque. ¿Están los pedidos? ¿Funcionan los formularios? ¿Cargan las imágenes?
• Repítelo periódicamente. Una web cambia con el tiempo. Repite la prueba al menos un par de veces al año para que el plan siga siendo válido.

Si sientes que es demasiado para llevarlo solo, no estás obligado a hacerlo todo por tu cuenta. Una auditoría gratuita de tu web te muestra exactamente cómo estás en copias, seguridad y puntos débiles, antes de que se conviertan en un problema caro.

La tranquilidad viene de la preparación

Un plan de recuperación no va de miedo, va de control. Cuando sabes que hay una copia limpia de la web a salvo en algún sitio, que los accesos están anotados y que sabes exactamente qué hacer, un incidente deja de ser una catástrofe y pasa a ser simplemente una hora menos agradable del día.

Empieza por el paso más importante: una copia externa y probada en la que puedas confiar. A partir de ahí, el resto del plan se construye solo. Y si quieres a alguien al lado que haya pasado por cientos de situaciones así desde 2005, aquí estamos. Escríbenos y asegurémonos de que, pase lo que pase, tu web tenga camino de vuelta.