La mayoría de las webs WordPress tienen algún tipo de copia de seguridad. El proveedor de hosting hace una, un plugin hace otra y puede que alguien haya descargado una copia en algún momento.
La pregunta incómoda no es si existe un backup. Es si ese backup puede realmente recuperar la web cuando algo sale mal.
Las copias de seguridad fallan más a menudo de lo que se piensa. Un archivo puede estar incompleto, puede faltar la base de datos, la carpeta de medios puede haberse excluido para ahorrar espacio o la única copia puede estar en el mismo servidor que acaba de fallar. Normalmente nadie se da cuenta hasta el día en que se necesita el backup.
La buena noticia es que es fácil de evitar. Una prueba de restauración, hecha con calma y de forma periódica, le dice si sus copias funcionan mientras todavía hay tiempo para corregirlas.
Esta guía explica qué es una prueba de restauración, con qué frecuencia hacerla según el tipo de web que tenga, qué comprobar y quién debe encargarse de ello.
¿Por qué un backup solo sirve si se puede restaurar?
Una copia de seguridad es una promesa: si la web se rompe, es hackeada o se borra, puede volver a un estado correcto conocido.
Esa promesa depende de que se cumplan varias condiciones a la vez:
- el backup incluye todos los archivos que necesita la web
- el backup incluye la base de datos, donde están las páginas, los ajustes, los usuarios y los pedidos
- el backup es lo bastante reciente como para ser útil
- el backup se guarda en un lugar accesible aunque el servidor no esté disponible
- alguien sabe cómo restaurarlo y tiene los accesos necesarios para hacerlo
Si falta cualquiera de ellas, el backup puede parecer correcto en un panel y, aun así, no servir.
Entre los problemas habituales que aparecen en las pruebas de restauración están:
- archivos comprimidos que dejaron de generarse hace semanas sin que nadie lo notara
- backups que contienen archivos pero no la base de datos, o al revés
- archivos de medios excluidos porque el backup era demasiado grande
- backups cifrados con una contraseña que nadie recuerda
- copias guardadas solo en la misma cuenta de hosting que la web
- procedimientos de restauración que solo entendía el desarrollador original
Nada de esto es raro. Simplemente es invisible hasta que alguien intenta restaurar.
¿Qué es una prueba de restauración?
Una prueba de restauración consiste en tomar un backup, restaurarlo de verdad en un lugar seguro y comprobar que la web restaurada funciona.
No es lo mismo que:
- ver una marca verde en un plugin de copias de seguridad
- comprobar que existe un archivo de backup
- leer el tamaño del backup en el panel del hosting
Son señales útiles, pero no demuestran que el backup pueda reconstruir la web.
Una prueba de restauración correcta suele hacerse en:
- una copia de staging proporcionada por la empresa de hosting
- un dominio o subdominio de pruebas independiente
- una copia local en el ordenador de un desarrollador
Nunca debe hacerse sobrescribiendo la web en producción. La idea es probar el backup sin poner en riesgo la web real.
¿Con qué frecuencia debe probar sus copias de seguridad?
No hay una única respuesta correcta. La frecuencia adecuada depende de cuánto cambia la web y de cuánto le costaría a la empresa perder los datos recientes.
Como punto de partida, tenga en cuenta lo siguiente.
Webs corporativas o informativas
Las webs que cambian unas pocas veces al mes, sin pedidos ni cuentas de usuario, normalmente pueden probarse con menos frecuencia. Una prueba de restauración cada pocos meses, y después de cualquier cambio importante como un rediseño, una migración o un cambio de hosting, es una base razonable.
Webs con formularios, reservas o áreas de socios
Si la web recoge consultas, reservas, registros o datos de socios, la base de datos cambia más a menudo. Probar con más regularidad, por ejemplo cada uno o dos meses, ayuda a confirmar que se guardan los datos recientes.
Tiendas WooCommerce y webs con mucha actividad
Las tiendas online cambian constantemente: pedidos, clientes, existencias y pagos. En este caso, una prueba de restauración mensual es un mínimo sensato, y muchas empresas prefieren comprobarlo más a menudo. También conviene verificar que la propia frecuencia de los backups se ajusta al volumen de pedidos. La guía sobre si una tienda WooCommerce necesita copias de seguridad en tiempo real trata esa cuestión con más detalle.
Después de cualquier cambio importante
Sea cual sea el tipo de web, haga una prueba de restauración después de:
- cambiar de proveedor de hosting
- cambiar de plugin o servicio de copias de seguridad
- una actualización importante de WordPress, del tema o de los plugins
- un incidente de seguridad
- añadir una gran cantidad de contenido o archivos de medios nuevos
Son los momentos en los que es más probable que la configuración de los backups cambie sin que nadie se dé cuenta.
¿Qué debe comprobar después de restaurar?
Una web restaurada que carga la página de inicio es un buen comienzo, pero no basta. Compruebe las partes que importan para su negocio.
Archivos y código
- el tema activo carga con el diseño correcto
- los plugins están presentes y activos
- las funcionalidades personalizadas siguen funcionando
- no hay errores por archivos que faltan
La base de datos
- las páginas, las entradas y los menús están presentes
- los ajustes parecen correctos, como el nombre del sitio y el idioma
- las cuentas de usuario existen y puede iniciar sesión con una cuenta de prueba
- aparece el contenido reciente, no solo el antiguo
Medios
- las imágenes se muestran en las páginas y en la biblioteca de medios
- los archivos descargables, como los PDF, están presentes
- las imágenes subidas recientemente están incluidas
La falta de imágenes es una de las señales más comunes de que la carpeta wp-content/uploads no se incluyó en el backup.
Pedidos y envíos de formularios recientes
Si la web recibe pedidos o recoge envíos de formularios:
- compruebe el pedido más reciente en la copia restaurada
- compare su fecha con el momento en que se hizo el backup
- compruebe que las cuentas de cliente y las suscripciones están presentes
- compruebe que se incluyen los envíos de formularios guardados, si su plugin de formularios los almacena
Así sabrá exactamente cuántos datos se habrían perdido si este backup se hubiera restaurado en la web en producción.
¿Dónde deben guardarse las copias de seguridad?
Un backup guardado en el mismo servidor que la web protege frente a algunos problemas, como una mala actualización. No protege frente a otros, como:
- la suspensión o el compromiso de la cuenta de hosting
- un fallo del servidor
- una pérdida de datos por parte del proveedor de hosting
- un atacante que borra tanto la web como sus backups
Por eso, al menos una copia debe guardarse fuera del servidor, es decir, en una ubicación separada gestionada de forma independiente de la cuenta de hosting. Puede ser un servicio de copias de seguridad específico o un almacenamiento en la nube que la propia web no pueda borrar.
Al hacer las pruebas, conviene restaurar desde la copia externa al menos algunas veces. Es la copia que necesitará en el peor de los casos.
¿Cuánto tiempo deben conservarse los backups?
La retención indica hasta qué fecha atrás llegan sus copias de seguridad.
Conservar solo los últimos días puede ser un problema. Algunos fallos se detectan tarde:
- malware presente desde hace semanas
- contenido borrado por error que solo se echa en falta más tarde
- un plugin que ha ido corrompiendo los datos poco a poco
Un enfoque habitual es conservar backups recientes frecuentes, como copias diarias durante unas semanas, y menos copias antiguas, como copias semanales o mensuales durante más tiempo. La retención adecuada depende de su negocio, del almacenamiento y de las obligaciones legales relativas a los datos de clientes.
Recuerde que los backups contienen datos personales si la web almacena datos de clientes. Las copias antiguas deben protegerse y eliminarse cuando ya no se necesiten, de acuerdo con sus obligaciones de privacidad.
¿Quién es responsable de probar los backups?
A menudo esta es la verdadera laguna. El proveedor de hosting da por hecho que el desarrollador prueba los backups. El desarrollador da por hecho que lo hace el proveedor de hosting. El propietario de la empresa da por hecho que alguien lo está haciendo.
Ayuda dejar por escrito con claridad:
- qué sistemas crean backups y con qué frecuencia
- dónde se guarda cada copia
- quién comprueba que se están creando los backups
- quién hace las pruebas de restauración y con qué frecuencia
- quién tiene los accesos necesarios para restaurar en una emergencia
- dónde se guardan las instrucciones de restauración
Los backups del hosting son útiles, pero muchos proveedores de hosting los describen como una comodidad más que como una garantía. Lea las condiciones de su hosting para entender qué cubren realmente.
Si nadie es claramente responsable, las pruebas de restauración tienden a no hacerse.
¿Cuáles son los errores más comunes?
- Fiarse del panel. Una notificación de backup correcto no significa que el backup se pueda restaurar.
- Probar en la web en producción. Restaurar sobre producción "para ver si funciona" puede sobrescribir pedidos y contenidos reales.
- Conservar una sola copia. Una sola copia en un solo lugar es un punto único de fallo.
- Olvidar la base de datos o la carpeta uploads. Un backup solo de los archivos, o solo de la base de datos, no es una web completa.
- No comprobar nunca la fecha del backup. Si los backups se detuvieron sin avisar, la última copia puede tener semanas.
- Ningún procedimiento escrito. Bajo presión, nadie quiere tener que reconstruir desde cero el proceso de restauración.
¿Cómo es una buena configuración?
Un sistema de copias de seguridad sano suele tener:
- backups automáticos con una frecuencia acorde a lo que cambia la web
- al menos una copia fuera del servidor
- una retención lo bastante larga para recuperarse de problemas detectados tarde
- pruebas de restauración periódicas en una copia de staging o local
- una breve nota escrita de cada prueba: fecha, backup utilizado, qué se comprobó, qué faltaba
- una persona o un proveedor concreto responsable de todo lo anterior
No tiene por qué ser complicado. Tiene que hacerse con constancia.
Cómo puede ayudarle D4Hub
D4Hub puede ayudarle a convertir los backups de una suposición en algo que ha verificado de verdad.
Según su web, D4Hub puede ayudarle a:
- revisar qué backups existen y dónde se guardan
- comprobar si se incluyen los archivos, la base de datos y los medios
- configurar una copia de seguridad fuera del servidor
- hacer una prueba de restauración en una copia de staging o local
- documentar un procedimiento de restauración que su equipo pueda seguir
- proponer una frecuencia y una retención de backups adecuadas para su web
- incluir las comprobaciones de los backups en el mantenimiento continuado mediante los planes de soporte de D4Hub
Puede solicitar ayuda en cualquier momento, tanto si quiere una revisión puntual como pruebas periódicas dentro del mantenimiento.
Abrir un ticket de soportePara usuarios con experiencia técnica: cómo hacer una prueba de restauración
Estos pasos son para usuarios que se manejan con paneles de hosting, SFTP y WP-CLI. Trabaje solo en una copia de staging o local, nunca en la web en producción. Si no está seguro de a qué instalación está conectado, deténgase y compruébelo antes de ejecutar cualquier comando.
Comprobar qué contiene el backup
Antes de restaurar nada, mire dentro del archivo de backup y confirme que incluye la carpeta uploads y un archivo de base de datos.
Para un archivo .zip:
unzip -l backup.zip | grep "wp-content/uploads" | head
unzip -l backup.zip | grep "\.sql"Para un archivo .tar.gz:
tar -tzf backup.tar.gz | grep "wp-content/uploads" | head
tar -tzf backup.tar.gz | grep "\.sql"Si no aparecen la carpeta uploads o el archivo SQL, el backup está incompleto. Algunos plugins de copias de seguridad guardan la base de datos y los archivos en archivos comprimidos separados, así que revise todos los archivos del mismo conjunto de backup.
También puede comprobar que el volcado de la base de datos contiene tablas:
grep -c "CREATE TABLE" database.sqlUn resultado de cero, o un número muy bajo, indica que el volcado está vacío o es parcial.
Restaurar en una copia de staging o local
Use la herramienta de staging de su proveedor de hosting, la función de restauración de su plugin de backups apuntando a un sitio de pruebas o un entorno de desarrollo local.
En un sitio de pruebas con WP-CLI disponible, un volcado de base de datos puede importarse así. Primero haga una copia de la base de datos actual del sitio de pruebas, por si necesita volver atrás:
wp db export test-site-before-import.sql
wp db import database.sqlwp db import sustituye el contenido de la base de datos a la que está conectado. Ejecútelo solo en el sitio de pruebas. Revise antes wp-config.php o ejecute wp option get siteurl para confirmar en qué web está trabajando.
Si el backup procede de otro dominio, el sitio restaurado puede intentar cargar las URL de producción. Solo en el sitio de pruebas, previsualice antes el cambio:
wp search-replace "https://www.example.com" "https://staging.example.com" --dry-runQuite --dry-run solo después de revisar el resultado.
Evitar que el sitio de pruebas se comporte como el de producción
Una copia restaurada de una web en producción puede enviar emails, ejecutar tareas programadas o conectarse a servicios de pago. Antes de probar:
- en Settings > Reading (Ajustes > Lectura), marque "Discourage search engines from indexing this site" (Disuadir a los motores de búsqueda de indexar este sitio)
- desactive o redirija el correo saliente con un plugin de bloqueo de emails o con la opción de su herramienta de staging, si existe
- ponga las pasarelas de pago en modo de prueba o sandbox, o desactívelas
- proteja el sitio de pruebas con contraseña si su hosting lo permite
En el sitio de pruebas, la opción de disuadir a los motores de búsqueda también puede activarse con:
wp option update blog_public 0Una lista sencilla para la restauración
Anote las respuestas cada vez que haga una prueba:
- ¿Qué backup ha utilizado y cuándo se creó?
- ¿Dónde estaba guardado: en el servidor o fuera de él?
- ¿La restauración ha terminado sin errores?
- ¿La página de inicio carga con el diseño correcto?
- ¿Puede iniciar sesión en el escritorio con una cuenta de prueba?
- ¿Están presentes las páginas, los menús y las entradas recientes?
- ¿Las imágenes y las descargas se muestran correctamente?
- ¿Cuál es el pedido o envío de formulario más reciente y qué fecha tiene?
- ¿Funcionan las funciones clave, como los formularios, la búsqueda y el checkout en modo de prueba?
- ¿Qué faltaba o estaba mal, y quién lo va a corregir?
Cuando termine, elimine la copia de prueba o manténgala protegida. Contiene los mismos datos que su web en producción.
Preguntas frecuentes
¿Basta con el backup de mi proveedor de hosting?
Puede ser una buena primera capa, pero conviene comprobar qué incluye, cuánto tiempo se conserva, si puede restaurarlo usted mismo y si se guarda separado de su cuenta de hosting. Muchas empresas mantienen además una copia independiente fuera del servidor.
¿Puedo probar un backup sin un sitio de staging?
Sí. Puede servir una copia local en un ordenador o un subdominio temporal. Lo importante es que la prueba se haga lejos de la web en producción y que no envíe emails ni procese pagos.
¿Cuánto tarda una prueba de restauración?
Depende del tamaño de la web, de la herramienta de backup y del entorno de hosting. Una web pequeña puede restaurarse rápido, mientras que una tienda grande con muchas imágenes puede llevar más tiempo. La primera prueba suele ser la que más tarda, porque también está definiendo el procedimiento.
¿Y si la prueba de restauración falla?
Es información útil, y mucho mejor descubrirla ahora que durante una emergencia. Anote qué ha fallado, corrija la configuración de los backups y vuelva a probar. Una prueba fallida suele apuntar a una carpeta que falta, una base de datos excluida o un problema de almacenamiento.
¿Debo probar todos y cada uno de los backups?
Normalmente no. Las comprobaciones automáticas de que se están creando los backups, combinadas con pruebas de restauración completas periódicas de un backup de muestra, ofrecen un buen equilibrio. Pruebe con más frecuencia después de cambios en el hosting, en los plugins o en el propio sistema de copias de seguridad.
¿Los backups deben cumplir las normas de privacidad?
Si su web almacena datos personales, como datos de clientes o envíos de formularios, sus backups también contienen esos datos. Deben estar protegidos, el acceso debe estar limitado y las copias antiguas deben eliminarse según sus políticas de retención y privacidad.