Cómo realizar y restaurar backups de WordPress

Debe incluir las dos partes que componen todo sitio WordPress: los archivos y la base de datos. Los archivos abarcan el código de WordPress, el tema, los plugins y todo lo que se haya subido, como la carpeta de imágenes y documentos; sin ellos se pierden el diseño, las funcionalidades y las subidas. La base de datos contiene el contenido —entradas, páginas y comentarios—, los usuarios y toda la configuración; sin ella se pierde absolutamente todo lo que se escribió y configuró en el sitio. El error más común y más costoso es hacer un backup incompleto que copia solo una de las dos partes, porque al momento de restaurar deja el sitio a medias o directamente inutilizable: restaurar únicamente los archivos da un sitio con diseño pero sin contenido, y restaurar únicamente la base de datos da el contenido pero sin diseño ni funciones. Además, es fundamental que ambas partes se capturen en el mismo momento, para que al restaurarlas coincidan entre sí. Esta división en dos mitades es la misma que explica cómo funcionan las migraciones, y comprenderla es clave para respaldar bien.

Porque un backup que se guarda en el mismo servidor que aloja el sitio comparte el destino de ese servidor, y por lo tanto ofrece una protección falsa. Si el servidor falla por un problema de hardware, si se pierde por un error del proveedor, o si es comprometido por un ataque como un ransomware que cifra o borra todo lo accesible, el backup guardado ahí desaparece junto con el sitio que se suponía debía proteger, dejando a la persona sin ninguna vía de recuperación justo cuando más la necesita. Por eso una de las reglas más importantes de los backups es mantener al menos una copia fuera del sitio, en un almacenamiento externo e independiente, típicamente un servicio de nube separado del hosting. Así, aunque le pase cualquier cosa al servidor, la copia externa permanece intacta y disponible. Esto forma parte de la conocida regla tres dos uno, que recomienda mantener varias copias en distintos tipos de medio y al menos una fuera del sitio. Conviene además no depender exclusivamente del sistema de backups que ofrece el propio hosting, sino tener también una copia propia que uno controle.

Restaurar es el proceso inverso a hacer el backup: consiste en tomar la copia guardada y volver a colocar tanto los archivos como la base de datos en el sitio, dejándolo exactamente como estaba en el momento de esa copia. La forma más simple, cuando el sitio todavía carga —por ejemplo tras una actualización que rompió algo pero permite entrar al panel—, es usar el mismo plugin de backup que generó las copias, que suele permitir restaurar con unos pocos clics: se elige la copia deseada y se confirma. Si el sitio no carga en absoluto, la restauración se hace de forma más manual, subiendo los archivos de la copia por FTP e importando la base de datos desde el panel del hosting, de manera muy similar a una migración. En cualquier caso, después de restaurar conviene verificar el sitio revisando que el contenido, las imágenes y las funciones estén completos, para confirmar que la copia trajo todo. Restaurar es lo que convierte un problema potencialmente catastrófico —un sitio caído, hackeado o roto por una actualización— en un contratiempo de minutos, siempre que exista una copia buena de la cual partir.

Porque el único propósito de un backup es poder restaurarlo cuando hace falta, y el mero hecho de que la copia exista no garantiza que esa restauración vaya a funcionar. Una copia puede estar vacía porque el proceso falló silenciosamente, puede estar incompleta porque no capturó una de las dos partes del sitio, o puede estar corrupta y ser inutilizable, y lo grave es que ninguno de estos problemas se manifiesta mientras todo va bien: se descubren justo en el peor momento, cuando el sitio ya se cayó y se recurre al backup con urgencia. Por eso la regla de oro, que lamentablemente casi nadie cumple, es que un backup que nunca se probó restaurar no es realmente un backup sino una esperanza. La única manera de tener certeza de que una copia funciona es restaurarla de verdad, cada tanto, en un entorno de prueba separado, y comprobar que el sitio vuelve completo y operativo. Esta verificación periódica es lo que transforma una copia en una garantía real, y es exactamente la misma lección que rige la recuperación ante desastres de cualquier sistema informático.

La frecuencia adecuada depende de cuánto cambie el sitio, y la pregunta que la define es cuánto contenido podés permitirte perder. Un sitio que cambia mucho, como un blog que publica a diario o una tienda en línea que recibe pedidos y comentarios constantemente, necesita backups diarios, porque perder un día entero de datos sería grave: se perderían publicaciones, ventas o interacciones. Un sitio que casi no cambia, como una web institucional estática que se actualiza muy de vez en cuando, puede respaldarse semanalmente sin problema, ya que entre un backup y otro apenas se modifica nada. Además de la frecuencia, es muy recomendable conservar varias copias de distintas fechas y no solo la más reciente, porque a veces un problema, como una infección o una corrupción de datos, pasa inadvertido durante un tiempo y termina contaminando también el último backup; tener copias anteriores permite volver a un punto sano previo al problema. Configurar backups automáticos según la frecuencia adecuada, guardarlos fuera del hosting y conservar un historial de varias fechas es la combinación que ofrece una protección sólida.

Sí, un backup bien hecho es una de las mejores defensas frente a un sitio comprometido, siempre que cumpla ciertas condiciones. Si un atacante logra dañar, alterar o cifrar el sitio, contar con una copia limpia y anterior al incidente permite volver a un estado sano sin tener que pagar rescates ni reconstruir todo desde cero. Sin embargo, para que esa protección sea real hay que tener en cuenta varios puntos. Primero, la copia debe estar guardada fuera del hosting, porque muchos ataques buscan justamente eliminar o cifrar también los backups accesibles desde el servidor para forzar el pago o impedir la recuperación. Segundo, conviene conservar copias de varias fechas, porque a veces la intrusión ocurre y pasa desapercibida durante un tiempo, de modo que hace falta poder retroceder a un punto anterior al compromiso y no solo al último backup, que podría ya estar infectado. Y tercero, tras restaurar, es imprescindible cerrar la vía de entrada que permitió el ataque —actualizar todo, cambiar contraseñas, revisar plugins— porque de lo contrario el atacante volvería a entrar. Con estas precauciones, el backup convierte un hackeo de una catástrofe en un incidente recuperable.