Copias de seguridad y restauración: estrategia práctica para un sitio WordPress sano

Qué debe incluir una copia de seguridad (y por qué)

Una copia de seguridad útil es la que permite volver a un estado funcional del sitio con el menor tiempo de caída y la menor pérdida de datos posible. En WordPress, eso implica respaldar tres piezas: base de datos, archivos y configuraciones relevantes. Si falta una de ellas, la restauración puede quedar incompleta (por ejemplo, el sitio “carga” pero sin contenido, o el contenido está pero faltan imágenes).

1) Base de datos (imprescindible)

La base de datos contiene el contenido y gran parte de la configuración: entradas, páginas, comentarios, usuarios, ajustes del sitio, menús, widgets, y en muchos casos datos de plugins (formularios, pedidos, reservas, etc.).

• Incluye: todas las tablas de WordPress (prefijo típico wp_) y tablas adicionales creadas por plugins.
• Formato habitual: exportación SQL (.sql) o archivo comprimido (.sql.gz).

2) Archivos (tema, plugins, subidas y “pegamento” del sitio)

Los archivos determinan cómo se ve y funciona el sitio, y guardan los medios (imágenes, PDFs, etc.). En la práctica, lo más importante suele estar en wp-content.

• wp-content/uploads: biblioteca de medios. Si no se respalda, faltarán imágenes y documentos.
• wp-content/themes: tema activo y temas instalados (especialmente si hay personalizaciones).
• wp-content/plugins: plugins instalados (al restaurar, evita desajustes de versiones).
• wp-content/mu-plugins (si existe): plugins obligatorios.
• wp-content/languages (opcional): traducciones.

Según el hosting, también puede ser relevante respaldar archivos fuera de wp-content si existen personalizaciones (por ejemplo, reglas específicas del servidor), pero en un enfoque sin código normalmente basta con lo anterior más los archivos de configuración.

3) Configuraciones relevantes

Hay configuraciones que conviene guardar aparte porque aceleran la recuperación o evitan errores.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• wp-config.php: credenciales de base de datos, claves/salts, prefijo de tablas, y ajustes específicos.
• .htaccess (en servidores Apache): reglas de enlaces permanentes y redirecciones.
• Configuración del servidor/hosting (si aplica): versión de PHP, límites de memoria, reglas de caché/CDN, tareas programadas (cron) del hosting.
• Claves externas (si el sitio integra servicios): por ejemplo, SMTP, pasarelas de pago, API keys. No siempre están en WordPress; documenta dónde están.

Tipos de backup y cuándo usar cada uno

Backup completo

Copia todo (base de datos + archivos). Es el más simple de entender y restaurar, pero suele ser más pesado y lento.

• Útil para: cambios importantes, migraciones, antes de rediseños, y como “punto de restauración” semanal.

Backup incremental

Guarda solo lo que cambió desde el último backup (completo o incremental). Reduce espacio y tiempo, pero depende de la cadena de copias para restaurar.

• Útil para: sitios con cambios frecuentes (tiendas, blogs activos) y para programaciones diarias/horarias.

Backup bajo demanda (manual)

Se ejecuta justo antes de una acción concreta: actualizar, instalar algo, cambiar ajustes críticos o importar contenido.

• Útil para: minimizar riesgo antes de cambios puntuales.

Frecuencias recomendadas según la actividad del sitio

La frecuencia ideal depende de cuánto contenido “doloroso” perderías si tuvieras que volver atrás. Piensa en términos de RPO (pérdida máxima aceptable de datos) y RTO (tiempo máximo aceptable de recuperación), aunque no uses esos términos en tu día a día.

Regla práctica: si dudas, empieza con base de datos diaria y archivos semanales, y añade backups bajo demanda antes de cambios.

Reglas de almacenamiento: dónde guardar, cuánto tiempo y cómo comprobar

1) Fuera del hosting (regla de oro)

No guardes la única copia en el mismo servidor donde vive tu web. Si el hosting falla, te hackean o se corrompe el disco, perderías sitio y copias a la vez.

• Destino recomendado: almacenamiento externo (por ejemplo, un bucket/drive en la nube) y/o un segundo proveedor.
• Ideal: 3-2-1 (3 copias, 2 medios distintos, 1 fuera del servidor). Si es demasiado, al menos 2 copias y 1 fuera del hosting.

2) Retención (cuántas copias conservar)

La retención evita que un problema pase desapercibido y sobrescriba tus copias “buenas” con copias ya dañadas o infectadas.

• Ejemplo simple: conservar 7 diarias + 4 semanales + 3 mensuales.
• Si el sitio cambia mucho: aumenta diarias (por ejemplo, 14) y añade alguna copia “inmutable” mensual.

3) Cifrado cuando sea posible

Las copias suelen contener datos sensibles (usuarios, emails, pedidos). Si el destino es externo, cifra en tránsito y, si puedes, en reposo.

• Activa conexiones seguras (HTTPS/SFTP) y cifrado del proveedor de almacenamiento.
• Protege el acceso a la cuenta donde guardas backups con contraseña robusta y 2FA.

4) Verificación: restauraciones de prueba

Un backup no probado es una esperanza, no un plan. Programa restauraciones de prueba en un entorno de staging o en una instalación temporal.

• Periodicidad recomendada: mensual en sitios críticos; trimestral en sitios con baja actividad.
• Qué comprobar: que el archivo se descarga, se descomprime, se importa la BD sin errores y el sitio funciona.

Procedimiento de restauración paso a paso (práctico)

Antes de restaurar, define el objetivo: ¿recuperar un sitio caído? ¿deshacer un cambio? ¿limpiar una corrupción? Eso determina si restauras solo base de datos, solo archivos o ambos.

Decidir qué restaurar: base de datos, archivos o ambos

• Restaurar solo base de datos cuando: se borró contenido, se rompieron ajustes, falló una importación, se dañaron tablas, o un plugin guardó datos incorrectos. Mantienes archivos actuales (tema/plugins) si están bien.
• Restaurar solo archivos cuando: faltan imágenes/medios, se dañó el tema, se borraron plugins, o hay archivos corruptos. Mantienes la BD actual si el contenido reciente es importante.
• Restaurar ambos (completo) cuando: el sitio está comprometido o inestable, hay desajustes graves, o no puedes aislar el problema. Es lo más “limpio”, pero puede perder contenido reciente si la BD es antigua.

Paso 0: preparar la restauración (minimizar riesgos)

• Poner el sitio en modo mantenimiento (si es posible) para evitar pedidos/comentarios durante la restauración.
• Hacer un backup “de emergencia” del estado actual, aunque esté roto. Puede servir para rescatar contenido reciente.
• Identificar la copia correcta: fecha/hora, tipo (completa/incremental), y qué incluye (BD/archivos).
• Reunir credenciales: acceso al panel del hosting, gestor de archivos/SFTP y acceso a la base de datos (phpMyAdmin o similar).

Paso 1: restaurar la base de datos (si aplica)

Este flujo es genérico y funciona con la mayoría de hostings que ofrecen phpMyAdmin o herramientas equivalentes.

• 1) Accede al gestor de base de datos del hosting.
• 2) Exporta la base de datos actual (backup de emergencia).
• 3) Vacía tablas existentes o elimina la BD y crea una nueva (según el panel). Si no estás seguro, vaciar tablas suele ser menos destructivo a nivel de permisos.
• 4) Importa el archivo .sql del backup (o descomprime .sql.gz y luego importa).
• 5) Verifica que el prefijo de tablas coincide con el del sitio (por ejemplo, wp_ u otro).
• 6) Si cambiaste el nombre de la BD/usuario/contraseña, actualiza wp-config.php con los nuevos valores.

Paso 2: restaurar archivos (si aplica)

• 1) Accede por gestor de archivos del hosting o SFTP.
• 2) Renombra la carpeta actual como respaldo (por ejemplo, public_html_old) si el hosting lo permite y hay espacio; si no, al menos renombra wp-content a wp-content_old.
• 3) Sube y descomprime el backup de archivos en la ruta correcta.
• 4) Asegúrate de que existen: wp-content/uploads, wp-content/themes, wp-content/plugins y el archivo wp-config.php correcto.
• 5) Comprueba permisos de archivos/carpetas si el hosting lo requiere (un error típico es que WordPress no pueda escribir en uploads).

Paso 3: acciones posteriores para que el sitio “encaje”

• Enlaces permanentes: entra al panel de WordPress y guarda de nuevo la configuración de enlaces permanentes para regenerar reglas. Si no puedes entrar, revisa .htaccess.
• Cachés: vacía caché del plugin de caché (si existe), del servidor y del CDN.
• Comprobar URLs: si la restauración viene de otro entorno, revisa que la URL del sitio sea correcta (ajustes de WordPress). Evita cambios manuales sin saber lo que haces; si hay mezcla de URLs, puede requerir reemplazo en BD.

Paso 4: validación tras restaurar (checklist)

Valida con una lista corta pero efectiva, como si fueras un usuario real:

• Front-end: carga la home, una página interna y una entrada; revisa estilos y que no falten imágenes.
• Login: accede a /wp-admin con un usuario válido; prueba cerrar sesión y volver a entrar.
• Formularios: envía un formulario de contacto o lead y confirma recepción (email o registro en el plugin).
• Enlaces permanentes: abre varias URLs; si hay 404, re-guardar enlaces permanentes y revisar .htaccess.
• Funcionalidad crítica: si hay tienda, prueba añadir al carrito y finalizar un pedido de prueba (sin cobro real si es posible).
• Errores: revisa si hay mensajes visibles o páginas en blanco; si el hosting ofrece logs, consulta errores recientes.

Cómo minimizar la pérdida de contenido reciente

La pérdida de contenido suele venir de restaurar una base de datos antigua. Para reducirla:

• Prioriza backups de base de datos más frecuentes en sitios con pedidos, formularios o publicaciones constantes.
• Antes de restaurar, captura datos recientes: exporta pedidos/leads si el plugin lo permite, o exporta la BD actual como “rescate”.
• Restauración selectiva (cuando sea viable): si el problema está en archivos, restaura solo archivos para conservar la BD actual.
• Congela cambios durante la ventana de restauración: modo mantenimiento y aviso interno para que el equipo no publique ni edite.
• Revisar integraciones: si los formularios envían a un CRM o email marketing, parte de los datos puede estar fuera de WordPress; verifica allí para recuperar lo que falte.

Errores comunes que arruinan una estrategia de backups

• No probar las copias: descubrir que el backup está corrupto cuando ya lo necesitas.
• Guardar backups en el mismo servidor: un incidente en el hosting se lleva todo.
• No incluir la base de datos: restauras “la web” pero el contenido y ajustes no vuelven.
• Retención insuficiente: solo guardas 1–2 copias y si el problema lleva días, ya no tienes una copia sana.
• Backups sin cifrado ni control de acceso: expones datos sensibles en almacenamiento externo.
• No documentar el procedimiento: en una urgencia, se pierde tiempo buscando credenciales y pasos.
• Restaurar sin backup de emergencia del estado actual: pierdes la oportunidad de rescatar contenido reciente.