Recuperación de tu web
Copia de seguridad de WordPress: ¿puedes restaurar tu sitio?
Comprueba tu backup de WordPress con un ensayo aislado, una ficha de recuperación y preguntas sobre lo que incluye tu proveedor.
El panel dice que la copia se ha completado. Bien. Ahora viene la pregunta incómoda: ¿alguien podría usarla para recuperar la web?
Una notificación confirma que la tarea informó de un resultado correcto. Un ensayo demuestra si archivos, acceso, instrucciones y personas consiguen devolver un sitio funcional. La diferencia suele aparecer cuando menos tiempo tienes.
Esta prueba de WordPress se hace en un entorno local o de staging aislado. Restaurar una tienda en producción puede sobrescribir pedidos y cambios posteriores al backup. La web activa nunca debe ser el lugar de ensayo.
Decide qué necesita recuperar el negocio
¿Cuánto trabajo reciente podrías perder y cuánto tiempo podrías estar sin web? Escribe respuestas concretas.
Ejemplo ficticio: una consultoría actualiza sus servicios dos veces al mes y guarda consultas en otro CRM. Recuperar la web de ayer puede servir si el CRM tiene protección propia. Para una tienda que recibe pedidos toda la tarde, la base de ayer podría omitir compras pagadas.
La frecuencia depende de cambios significativos, no del número de páginas. Identifica pedidos, contenidos, miembros, formularios, imágenes y datos externos a WordPress. Puede hacer falta un servicio adicional para cumplir esos objetivos.
Comprueba el contenido de la copia
WordPress explica que un backup completo necesita archivos y base de datos. Tener una parte no demuestra que dispongas de la otra.
| Elemento | Por qué importa | Qué comprobar |
|---|---|---|
| Base de datos | Contenidos, ajustes y registros | Fecha e importación de prueba correcta |
| Archivos y medios | Imágenes, temas, plugins y código | Carpetas esperadas en la copia restaurada |
| Configuración | Conexión de la aplicación con sus servicios | Instrucciones verificadas por el responsable técnico |
| Servicios externos | Correo, CRM, pagos o reservas pueden estar fuera | Acceso y recuperación independientes |
| Copias anteriores | Puedes detectar el problema días después | Fechas realmente disponibles |
Pregunta si la copia es completa o depende de una cadena incremental. Necesitas la herramienta y todas las piezas. Conserva las instrucciones junto al inventario, no solo en el correo de un antiguo colaborador.
Comprueba ubicación y acceso. Si perder la cuenta de hosting implica perder todos los backups, valora una copia independiente debidamente protegida.
Prepara un entorno aislado
Utiliza staging del proveedor o un entorno preparado por un técnico competente. Antes de importar datos, decide quién tendrá acceso y cómo se protegerán y eliminarán.
Exige autenticación: excluir una página de buscadores no protege datos privados. Desactiva correos a clientes, notificaciones, acciones de pago y webhooks de producción antes de ejecutar la copia. Usa integraciones de prueba cuando existan.
Una tienda clonada puede conservar tareas programadas. Dos webs enviando el mismo recordatorio es una forma peculiar de anunciar que tu backup funciona. Si no sabes aislar esas acciones, pide ayuda antes de continuar; un entorno local sin conectividad externa puede ser preferible.
Restaura y toma notas
1. Elige el punto de recuperación
Registra fecha, hora, zona horaria y componentes. Archivos y base deben corresponder a un estado compatible. Anota qué actividad posterior faltará.
2. Confirma el destino
Lee el nombre y la URL con quien restaura. Confirma que sea el entorno de ensayo. Si la herramienta no distingue claramente staging y producción, resuelve la duda antes de tocar nada.
3. Sigue el método documentado
Usa las instrucciones del proveedor o producto concreto. Algunos restauran un paquete; otros separan archivos y base de datos. WordPress ofrece orientación sobre copias y restauración de bases de datos.
Si cambia la URL del entorno, pide al técnico una sustitución compatible con datos serializados. Un reemplazo indiscriminado dentro del volcado puede corromper configuraciones.
4. Verifica las tareas del negocio
La portada es solo el comienzo:
- Abre páginas de productos o servicios e inspecciona sus imágenes.
- Accede con una cuenta de prueba autorizada.
- Comprueba el contenido que debía existir en la fecha del backup.
- Envía un formulario a un destino controlado.
- Realiza una compra de prueba en sandbox y verifica su registro.
- Confirma que tareas programadas y acciones externas sigan aisladas.
Describe fallos concretos: “el formulario se envía pero no llega al buzón de pruebas” permite actuar. “Casi todo funciona” no ayuda demasiado.
5. Mide la recuperación completa
Cuenta localizar credenciales, pedir acceso, descargar, restaurar y verificar. Un botón de diez minutos no evita dos horas buscando al titular de la cuenta.
Registra responsable, entorno, copia utilizada, componentes ausentes y próximas acciones. Corrige fallos y repite las comprobaciones afectadas antes de confiar en el proceso.
Una ficha que puedes copiar
| Campo | Respuesta |
|---|---|
| Web y responsable técnico | Nombre y contacto |
| Backup elegido | Fecha, hora, zona y componentes |
| Destino aislado | Staging o entorno local |
| Inicio y final | Incluye preparación y comprobación |
| Tareas verificadas | Páginas, acceso, formularios y pago sandbox |
| Datos posteriores ausentes | Cambios después de la copia |
| Problemas y acciones | Responsable y plazo |
| Próximo ensayo | Fecha o cambio que lo desencadene |
Guarda la ficha donde puedan encontrarla los compañeros autorizados. Las contraseñas deben estar en un gestor apropiado, no en esta hoja.
Qué cambia en un incidente real
Investiga qué falló y conserva datos y registros actuales cuando sea seguro. Ante una intrusión, restaurar sin corregir la entrada puede devolver el mismo problema.
En una tienda, concilia pedidos y registros del proveedor de pagos antes de sobrescribir. Recuperar la web no revierte pagos ni recrea transacciones posteriores automáticamente. El responsable técnico y el negocio deben acordar la secuencia.
Define también quién comunica con clientes, verifica la recuperación y autoriza reanudar la actividad. Es mejor acordarlo antes de la caída.
Cuándo repetirlo
Repite tras una migración, un cambio importante del backup o nuevas funciones. La frecuencia depende de la actividad y de las consecuencias de perder datos. Un ensayo trimestral puede ser un punto de partida para una web modesta, no una garantía universal.
Elimina copias de ensayo innecesarias según tus procedimientos y conserva las protegidas que necesites. Nuestra comparativa de hosting ayuda a preguntar antes de comprar. Combina el ensayo con la lista de migración y añade costes separados al presupuesto de renovación.
Preguntas sobre backups de WordPress
¿Basta el backup incluido por el proveedor?
Puede bastar si alcance, frecuencia, retención, acceso y restauración cumplen tus objetivos. Demuéstralo con el ensayo y revisa qué sucede si pierdes la cuenta.
¿Puedo practicar en la web activa?
Usa una copia aislada. Restaurar producción requiere un plan, backups adecuados y una persona cualificada por el riesgo de perder datos.
¿Incluye también el correo?
No lo presupongas. Los buzones pueden estar en otro servicio o excluidos. Comprueba su recuperación por separado.