Guía para decidir mejor
Cómo restaurar WordPress desde una copia de seguridad
La mejor copia no sirve si sobreescribe pedidos nuevos. Verifica qué cubre y ensaya el retorno antes de cambiar producción.
Restaurar WordPress no consiste solo en pulsar «recuperar». Debes saber qué fecha cubre la copia, si incluye archivos y base de datos, y qué cambió después. En una tienda activa, sobreescribir la base de datos con una versión antigua puede eliminar pedidos, clientes o cambios de stock; decide primero qué necesitas recuperar.
Antes de una emergencia, ensaya en un entorno aislado que el respaldo se restaura. Si todas las versiones dependen del mismo servidor, valora una copia independiente.
Para establecer una rutina recuperable, consulta cómo hacer copias de una tienda preservando pedidos. Una prueba de restauración aislada permite detectar una copia incompleta antes de una emergencia.
Define el punto de recuperación
- Anota cuándo empezó el problema y cuál es la copia íntegra anterior. Comprueba que el archivo se puede abrir, que pertenece al sitio correcto y que incluye base de datos, wp-content, configuración y archivos necesarios. Una exportación de entradas no equivale a una copia completa.
- Haz una copia nueva del estado actual, aunque esté averiado. Conserva por separado pedidos, formularios, usuarios, medios y cambios recientes que no estén en la copia antigua.
- Decide si basta con revertir un plugin, tema o archivo. Restaurar solo el componente responsable suele reducir el riesgo de pérdida de datos frente a reemplazar toda la base.
Ensaya antes de sustituir producción
Restaura la copia en staging o en un entorno aislado con acceso restringido y correos/pagos reales desactivados. Verifica compatibilidad de PHP y base de datos, URL del sitio, SSL y rutas de medios. La documentación de WordPress distingue la copia de la base de datos de la copia de archivos; necesitas ambas si buscas recuperar el sitio completo. No publiques el archivo SQL ni credenciales en el directorio web.
Si la causa requiere restauración total en producción, fija una ventana de cambio y define cómo conciliar escrituras nuevas. Para WooCommerce, detén temporalmente nuevas compras solo con una comunicación clara, registra el último pedido confirmado, restaura, reconcilia pedidos y stock desde la fuente actual y prueba el pago en modo sandbox antes de reabrir. Nunca importes una base de datos vieja sobre pedidos recibidos después sin un procedimiento explícito de combinación. La checklist de migración de tienda explica ese riesgo con más detalle.
Verificación y vuelta atrás
Comprueba portada, URLs interiores, administración, imágenes, formularios y redirecciones. En tienda, compara recuentos y estados de pedidos antes y después, pasarela, impuestos, envío y notificaciones. Revisa logs durante un periodo razonable y conserva la copia del estado previo para poder volver atrás. Ejemplo: una actualización rompe una plantilla, pero pedidos siguen entrando; restaurar solo la versión anterior del tema en staging y luego en producción evita volver la base de datos a ayer.
Si el incidente empezó tras un traslado, consulta cómo verificar la migración. Antes de pedir ayuda a soporte, prepara fechas de copias, componentes incluidos y cambios ocurridos desde entonces, sin enviar contraseñas por un formulario abierto.
Para que esta respuesta no dependa de improvisar durante una caída, define responsables y prioridades en un plan de recuperación de la web.