Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando toca recuperar un entorno local, la duda casi siempre es la misma: ¿basta con importar un volcado de la base de datos o hay que devolver también la carpeta física de MySQL? Al hablar de XAMPP restaurar copia seguridad, la respuesta corta es que el dump gana en casi todos los escenarios reales de desarrollo, y la carpeta física solo se justifica cuando el servidor no arranca y necesitas un rescate de emergencia. Lo he comprobado en varias máquinas y el patrón se repite: quien confía solo en copiar mysql/data acaba con tablas corruptas más veces de las que espera.
La razón es sencilla. InnoDB mantiene ficheros de log y metadatos abiertos mientras el servicio corre. Copiar esos ficheros en caliente, con el proceso activo, produce instantáneas incoherentes. El volcado SQL, en cambio, se genera con mysqldump y produce una secuencia de sentencias que puedes revisar, versionar y restaurar sin depender del estado del motor.
Volcado SQL frente a copia de la carpeta mysql/data
Piensa en un caso típico. Tienes un proyecto con WordPress en local, tres plugins y una tabla de pedidos de pruebas. Un día XAMPP no levanta MySQL porque el log de InnoDB quedó inconsistente tras un apagón. Si tu copia de seguridad era la carpeta data, arrastras el mismo problema al restaurar: los ficheros vienen del mismo estado roto. Si tenías un dump generado antes del fallo, importas y sigues trabajando.
El dump también resuelve el traslado entre versiones. Pasar de MariaDB 10.4 a 10.6 en una instalación nueva de XAMPP es trivial con un archivo .sql. Copiar el directorio data entre versiones mayores suele fallar por cambios en el formato interno del diccionario de datos.
Cuándo sí conviene la copia física
Hay una excepción honesta: cuando el servidor está detenido y necesitas recuperar todo el conjunto de bases de datos de golpe, incluidos usuarios y privilegios. En ese escenario, con MySQL parado, copiar data completo es rápido y conserva el archivo mysql/user.MYD con las cuentas.
Esto no funciona para bases MyISAM dañadas ni para tablas que quedaron a medio escribir. Tampoco sirve si cambias de sistema operativo y rutas absolutas, algo frecuente al mover XAMPP de Windows a Linux.
Restaurar con phpMyAdmin sin dramas
El flujo que uso habitualmente pasa por phpMyAdmin. Creo la base de datos vacía con el mismo cotejamiento que el dump, subo el archivo y dejo que importe. Si el archivo supera el límite de subida de PHP, cosa que pasa con dumps de más de 100 MB, ajusto upload_max_filesize y post_max_size en php.ini o uso la consola.
Desde terminal es más limpio: mysql -u root -p nombre_bd < copia.sql. Con esto evitas timeouts y ves los errores reales en lugar de un mensaje genérico de phpMyAdmin.
Un detalle que casi nadie revisa
Antes de dar por buena una restauración de XAMPP, comprueba que el dump incluye las rutas de wp_options o las URLs absolutas del proyecto. Muchos dumps salen bien pero las rutas apuntan a localhost/proyecto y no al nuevo directorio. Es un fallo silencioso que aparece días después, cuando el cliente o tú abrís la web y las imágenes dan 404.
También conviene verificar el juego de caracteres. Un dump exportado en latin1 e importado en utf8mb4 genera acentos rotos que no se detectan hasta que revisas el contenido.
Veredicto
Para el trabajo diario, el dump SQL es la opción ganadora: portable, revisable, compatible entre versiones y sin riesgo de ficheros inconsistentes. La copia física de mysql/data queda como red de seguridad para rescates puntuales con el servicio parado. Si tienes que elegir una sola, elige el dump y automatízalo con una tarea programada que lo genere cada noche.
Ninguna de las dos opciones garantiza una recuperación perfecta si el origen ya estaba dañado. La copia de seguridad solo es útil si se prueba. Restaurar una vez al mes en un entorno limpio te dirá más que cualquier documentación.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
