Respaldar distribuciones WSL: exportar/importar de la manera correcta

Qué estás respaldando realmente (y por qué importa)

Las distribuciones WSL no son carpetas mágicas con vibra de pingüino. Bajo el capó, son sistemas de archivos Linux que viven dentro de un disco virtual. Para WSL2, eso suele ser un archivo .vhdx ubicado dentro de tu perfil de Windows. WSL1 es distinto: almacena archivos más “directamente” en estructuras del sistema de archivos de Windows, y verás comportamientos de rendimiento y de backup muy diferentes.

Cuando la gente pierde un entorno WSL, rara vez es porque Linux hizo algo exótico. Es porque Windows hizo algo normal: un restablecimiento de perfil, un cambio de letra de unidad, una política de perfiles itinerantes, una cuarentena de antivirus, una limpieza de “storage sense” o un “solo reinstala y ya estará bien”.

Hay tres enfoques de respaldo que escucharás:

1. Exportar/importar WSL (tar): canónico y portable, pero debes saber qué captura y qué no.
2. Copiar el VHDX: rápido y completo (incluye caches y rarezas), pero más frágil entre versiones y más propenso a corromperse si lo copias mientras está montado y cambiando.
3. Respaldar desde dentro de Linux (rsync, etc.): bueno para datos específicos, no para una imagen completa de la distro a menos que lo hagas con mucha deliberación.

Mi guía con opinión: usa export/import como tu copia de seguridad por defecto para recuperación ante desastres, y opcionalmente guarda snapshots de VHDX como “restauración rápida” cuando controles el host y el momento. Export/import es la opción aburrida y compatible. Lo aburrido es bueno. Lo aburrido restaura a las 2 a.m.

Además: una copia de seguridad que no ha sido restaurada no es un respaldo. Es un archivo que te hace sentir mejor.

Hechos interesantes y breve historia (las partes que cambian decisiones)

• WSL1 y WSL2 son fundamentalmente diferentes: WSL1 traduce llamadas del sistema Linux; WSL2 ejecuta un kernel Linux real en una VM ligera. Por eso WSL2 es generalmente más compatible pero almacena datos en un VHDX.
• WSL2 usa un formato de disco virtual del mundo Hyper-V: VHDX soporta discos más grandes y características de resiliencia comparado con VHD antiguo. Eso es bueno para el crecimiento, y también un recordatorio: trátalo como un disco de VM.
• El rendimiento del sistema de archivos de WSL cambió la conversación de backup: los patrones tempranos de WSL1 a menudo dependían del acceso desde el lado Windows; WSL2 aceleró las operaciones del sistema de archivos dentro del disco virtual, pero el acceso desde Windows a \\wsl$ puede ser más lento y complicado de respaldar de forma consistente.
• La era de las “apps de la tienda” importa: las distribuciones WSL frecuentemente provienen de Microsoft Store, lo que significa que las actualizaciones y los flujos de reinstalación se parecen más al ciclo de vida de una app que a una instalación Linux tradicional. Genial hasta que la gestión de imágenes corporativa decide que sabe más.
• WSL ganó soporte para systemd más tarde: las suposiciones antiguas sobre servicios que no se ejecutan pueden ser incorrectas ahora. Si systemd está habilitado, puedes tener más estado en segundo plano que conviene silenciar antes de hacer un snapshot.
• Las opciones de formato de exportación evolucionaron: exportar en WSL tradicionalmente produce un archivo tar. Las herramientas más nuevas añadieron opciones que afectan si estás exportando un rootfs o algo más cercano a un snapshot completo. Conoce lo que soporta tu versión.
• La ubicación de almacenamiento por defecto se movió en la mente de la gente, no siempre en la realidad: los usuarios piensan “está en mi home de Linux”. Normalmente está en %LOCALAPPDATA% dentro de una carpeta de paquete. Eso es una sorpresa para backup y cumplimiento.
• El modelo de red de WSL cambió con el tiempo: NAT de WSL2 y modos reflejados afectan qué secretos/configs importan (proxies, bundles de certs, configuraciones SSH). Los respaldos que restauran pero no restauran las expectativas de red siguen fallando.

La opción sensata: export/import, no esperanza

Export/import es el mecanismo incorporado de migración de WSL. No es glamoroso. También es lo más probable que funcione después de formatear y reinstalar Windows, cambiar discos o pasar a un portátil nuevo.

Qué hace bien export/import

• Produce un archivo de la distro que puedes guardar en cualquier lado (disco externo, recurso de red, bóveda cifrada).
• Restaura en otra máquina Windows sin importar dónde vivía el VHDX original.
• Te permite importar a una ubicación específica (como D:\WSL\Ubuntu) para mantener SO y datos de desarrollo separados.

Qué no resuelve mágicamente export/import

• Higiene de secretos: si tu distro contiene claves/tokens, exportar significa exportar secretos. Decide si ese archivo estará cifrado en reposo.
• Consistencia de archivos abiertos: exportar mientras la distro escribe activamente puede capturar un estado que es “prácticamente correcto” hasta que no lo es.
• Rarezas entre versiones: importar un archivo de distro muy antiguo en un WSL mucho más nuevo puede requerir actualizar paquetes.

Regla práctica: antes de exportar, detén la distro o al menos termina WSL para que el sistema de archivos esté quieto. Verás este tema repetido porque es la diferencia entre “lo respaldé” y “respaldé un objetivo en movimiento”.

Broma #1: Respaldar un sistema en ejecución sin ponerlo en quietud es como fotografiar un colibrí con una papa—técnicamente posible, emocionalmente costoso.

Tareas prácticas (comandos, salidas y decisiones)

Estas son tareas reales de operador. Cada una incluye: el comando, una salida de ejemplo, lo que significa la salida y lo que decides después. ejecútalas en PowerShell o CMD cuando corresponda; la gestión de WSL es un plano de control del lado de Windows.

Tarea 1: Listar distros instaladas y ver qué está en ejecución

cr0x@server:~$ wsl --list --verbose
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2
  Debian                 Stopped         2
  docker-desktop         Stopped         2

Significado: Tienes tres distros. Ubuntu-22.04 está en ejecución, así que su disco está montado activamente y puede estar cambiando.

Decisión: Si vas a hacer un backup completo por export, planea detenerla primero (o acepta el riesgo para datos no críticos).

Tarea 2: Apagar WSL limpiamente (poner todo en quietud)

cr0x@server:~$ wsl --shutdown

Significado: La VM y las distros de WSL se terminan. No mostrar salida es normal.

Decisión: Procede con export o copia de VHDX con mucho menor riesgo de estado inconsistente.

Tarea 3: Exportar una distro a un archivo tar (backup portable)

cr0x@server:~$ wsl --export Ubuntu-22.04 E:\Backups\wsl\Ubuntu-22.04_2026-02-05.tar

Significado: Ahora tienes un archivo tar que se puede importar en otro lugar.

Decisión: Verifica inmediatamente el tamaño del archivo y el hash; no confíes solo en la existencia del archivo.

Tarea 4: Validar tamaño y marca temporal del backup (chequeo barato)

cr0x@server:~$ dir E:\Backups\wsl
 Volume in drive E is BACKUP
 Directory of E:\Backups\wsl

02/05/2026  09:16 AM    12,884,377,600 Ubuntu-22.04_2026-02-05.tar
               1 File(s) 12,884,377,600 bytes

Significado: La exportación produjo un tar de ~12.8 GB. Si tu distro es grande y el tar es diminuto, algo anda mal (o está casi vacío).

Decisión: Si el tamaño es sospechosamente pequeño, vuelve a exportar tras asegurar que el nombre de la distro es correcto y que WSL tuvo acceso al disco de destino.

Tarea 5: Hashear el tar para detectar corrupción (y habilitar deduplicación)

cr0x@server:~$ certutil -hashfile E:\Backups\wsl\Ubuntu-22.04_2026-02-05.tar SHA256
SHA256 hash of Ubuntu-22.04_2026-02-05.tar:
5f3b1e5fd10a39a3e2f0d7a4b5c2b9b44f0f6d6fdb0c9ad6b7f1c2d3e4f5a6b7
CertUtil: -hashfile command completed successfully.

Significado: Tienes una huella de integridad que puedes almacenar junto al backup.

Decisión: Si este archivo sale de la máquina (NAS/nube), guarda el hash por separado y vuelve a comprobarlo después de la transferencia.

Tarea 6: Confirmar que puedes leer el tar (integridad básica del archivo)

cr0x@server:~$ tar -tf E:\Backups\wsl\Ubuntu-22.04_2026-02-05.tar | head
./
./bin/
./bin/bash
./etc/
./etc/hosts
./etc/passwd
./home/
./home/cr0x/
./home/cr0x/.bashrc

Significado: El tar es legible y contiene rutas esperadas.

Decisión: Si tar -tf da error (EOF inesperado, errores de checksum), descarta el backup y exporta de nuevo—preferiblemente tras wsl --shutdown y a otro disco.

Tarea 7: Ver dónde vive realmente una distro (para saber qué mueves)

cr0x@server:~$ wsl -d Ubuntu-22.04 -- bash -lc 'df -h /'
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       1007G  146G  811G  16% /

Significado: Dentro de WSL2, esto parece un dispositivo de bloque. Eso no muestra la ruta de Windows, pero te dice el tamaño lógico y uso.

Decisión: Si el uso es enorme, espera que la exportación tome tiempo y produzca un tar grande. Considera limpiar caches antes del backup si el tiempo importa.

Tarea 8: Limpiar hogs de espacio obvios antes de exportar (opcional, pero efectivo)

cr0x@server:~$ wsl -d Ubuntu-22.04 -- bash -lc 'sudo du -xh --max-depth=1 /var | sort -h | tail'
8.5G	/var/lib
9.1G	/var/cache
11G	/var/log
28G	/var

Significado: /var/cache y logs son pesados; tal vez tienes paquetes viejos, capas de contenedores o un spammer de logs.

Decisión: Si esto es una estación de desarrollo y caches reproducibles no necesitan respaldarse, límpialos y exporta un tar más pequeño.

Tarea 9: Limpiar caches de apt y paquetes antiguos (no te pongas creativo)

cr0x@server:~$ wsl -d Ubuntu-22.04 -- bash -lc 'sudo apt-get clean && sudo apt-get autoremove -y'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-headers-5.15.0-... ...
After this operation, 1,024 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 245123 files and directories currently installed.)
Removing linux-headers-5.15.0-... ...
Processing triggers for man-db (2.10.2-1) ...

Significado: Espacio recuperado. Las exportaciones serán más pequeñas y rápidas.

Decisión: Si esta distro se usa para trabajo de kernel/módulos o toolchains fijados, no hagas autoremove a ciegas; respalda primero y luego poda. “Backup más pequeño” no vale “build roto”.

Tarea 10: Exportar después de limpiar (y verificar de nuevo)

cr0x@server:~$ wsl --shutdown
cr0x@server:~$ wsl --export Ubuntu-22.04 E:\Backups\wsl\Ubuntu-22.04_clean_2026-02-05.tar

Significado: Tienes un nuevo archivo. Espera que sea más pequeño si la limpieza ayudó.

Decisión: Conserva al menos un backup “sin limpiar” periódico si temes borrar algo que luego lamentes (como un artefacto local que nunca subiste).

Tarea 11: Importar a una ubicación específica (migración o restauración)

cr0x@server:~$ mkdir D:\WSL\Ubuntu-22.04
cr0x@server:~$ wsl --import Ubuntu-22.04-Restored D:\WSL\Ubuntu-22.04 E:\Backups\wsl\Ubuntu-22.04_clean_2026-02-05.tar

Significado: Se crea una nueva distro llamada Ubuntu-22.04-Restored en la ubicación elegida.

Decisión: Haz esto para probar restauraciones. No sobrescribas tu distro en uso hasta haber confirmado que la restaurada arranca y tiene tus datos.

Tarea 12: Verificar que la distro restaurada arranca y tiene los usuarios/archivos esperados

cr0x@server:~$ wsl -d Ubuntu-22.04-Restored -- bash -lc 'id && ls -la ~ | head'
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)
total 68
drwxr-x---  9 cr0x cr0x  4096 Feb  5 09:05 .
drwxr-xr-x  3 root root  4096 Jan 15 11:22 ..
-rw-------  1 cr0x cr0x  1520 Feb  1 10:14 .bash_history
-rw-r--r--  1 cr0x cr0x   220 Jan 15 11:22 .bash_logout
-rw-r--r--  1 cr0x cr0x  3771 Jan 15 11:22 .bashrc

Significado: El usuario por defecto y el contenido del home existen. Es una verificación básica de “está vivo”.

Decisión: A continuación, valida las cosas específicas que te importan: repositorios, claves SSH, dotfiles, toolchains de compilación y cualquier estado de servicio del que dependas.

Tarea 13: Establecer la distro por defecto (cuando estés seguro)

cr0x@server:~$ wsl --set-default Ubuntu-22.04-Restored

Significado: Ejecutar wsl sin argumentos ahora lanzará la distro restaurada.

Decisión: Haz esto solo después de que la restauración haya demostrado ser fiable por un día de trabajo real.

Tarea 14: Comprobar la versión y estado de WSL (depuración de rarezas de export/import)

cr0x@server:~$ wsl --status
Default Distribution: Ubuntu-22.04-Restored
Default Version: 2
WSL version: 2.1.5.0
Kernel version: 5.15.146.1

Significado: Esto te dice en qué plataforma WSL estás. Desajustes de versión son una causa real de sorpresas al restaurar.

Decisión: Si estás restaurando desde una máquina muy antigua, considera actualizar WSL primero para que el comportamiento de importación coincida con tus expectativas.

Tarea 15: Exportar a una ruta de red (y decidir si vale la pena)

cr0x@server:~$ wsl --shutdown
cr0x@server:~$ wsl --export Ubuntu-22.04-Restored \\fileserver\backups\wsl\Ubuntu-22.04-Restored.tar

Significado: Escribe directamente a una ruta UNC. Esto puede ser conveniente, pero también más lento y propenso a fallos si la Wi‑Fi titubea.

Decisión: Para fiabilidad: exporta localmente, hashea y luego copia a red con una herramienta que reintente (y vuelve a hacer hash después de la copia).

Tarea 16: Copiar con semántica de verificación (transferencia robusta)

cr0x@server:~$ robocopy E:\Backups\wsl \\fileserver\backups\wsl Ubuntu-22.04_clean_2026-02-05.tar /Z /R:3 /W:5 /NFL /NDL
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------
  Started : Wednesday, February 5, 2026 9:30:12 AM
   Source : E:\Backups\wsl\
     Dest : \\fileserver\backups\wsl\

    Files : Ubuntu-22.04_clean_2026-02-05.tar

  Options : /NDL /NFL /Z /R:3 /W:5

------------------------------------------------------------------------------

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         0         1         0         0         0
   Files :         1         1         0         0         0         0
   Bytes :  10.2 g   10.2 g         0         0         0         0
   Times :   0:07:42   0:07:42                       0:00:00
   Speed :            22.5 MB/s
  Ended : Wednesday, February 5, 2026 9:37:54 AM

Significado: La copia tuvo éxito, muestra velocidad y comportamiento de reintentos. Si ves FAILED > 0, no tienes un backup en el servidor, tienes una historia.

Decisión: Haz hash del archivo en destino y compáralo con el hash fuente. Si difieren, recopia o investiga almacenamiento/red inestables.

Diseño de backup: cómo se ve “bueno” para WSL

Decide qué estás protegiendo

La mayoría de distros WSL contienen una mezcla de:

• Irreemplazable: claves, certificados, configuración local, commits no enviados, notebooks, scripts.
• Recreable: instalaciones de paquetes, toolchains de lenguajes, imágenes de contenedores, resultados de compilación.
• Activamente hostil: caches que inflan backups y aumentan tiempo de restauración sin beneficio.

Tu estrategia de backup debe reflejar eso. El objetivo no es preservar cada byte. El objetivo es preservar los bytes que extrañarás cuando la máquina esté en llamas y tu agenda no sea comprensiva.

Export/import vs copia de VHDX: elige deliberadamente

Export/import (tar) es tu jugada de portabilidad. Es lo que haces cuando esperas que el host cambie: nuevo portátil, reinstalación del OS, reimagen corporativa, mover entre discos, o cuando quieres una “reconstrucción” limpia que no arrastre tanto estado oculto.

Copia de VHDX es tu snapshot rápido de “levantar y mover”. Puede restaurarte al mismo estado exacto, pero es más sensible a la consistencia y a cómo lo copias.

Si insistes en copiar VHDX: apaga WSL primero. Si lo copias mientras WSL está ejecutándose, estás apostando tu entorno a la sincronización. La sincronización no es una estrategia.

Cifrado y control de acceso: tu tar es una bolsa de secretos

Los archivos tar exportados suelen incluir:

• ~/.ssh
• ~/.gnupg
• credenciales de la nube y tokens de CLI
• ~/.kube/config y certificados de clúster
• secretos de aplicaciones en archivos .env que olvidaste que tenías

Eso significa que el destino del backup importa. Si es una unidad compartida, tu modelo de amenazas acaba de cambiar. Si es un SSD externo personal, encripta. Si es almacenamiento corporativo, asegura permisos correctos y auditoría.

Retención: guarda menos backups, pero confiables

Para estaciones de trabajo de desarrolladores, un patrón práctico de retención:

• Export diario por 7 días
• Export semanal por 4–8 semanas
• Export mensual por 6–12 meses (si cumplimiento o investigación de largo plazo importa)

Más que eso tiende a pudrirse porque nadie verifica restauraciones. Guarda menos, verifícalos y duerme mejor.

Una cita que importa

La esperanza no es una estrategia. — idea parafraseada repetida en círculos de confiabilidad/operaciones (atribuida ampliamente, no a una fuente exacta).

Broma #2: Si tu plan de backup es “recordaré exportar antes de reinstalar”, enhorabuena—has inventado un recordatorio de calendario que te odia.

Guía rápida de diagnóstico (encuentra el cuello de botella rápido)

Las exportaciones a veces tardan una eternidad, las importaciones a veces “se cuelgan” y las copias a veces van lentas. No adivines. Haz triage.

Primero: ¿WSL sigue en ejecución o está atascado?

cr0x@server:~$ wsl --list --verbose
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2

Si está Running: Exportar puede funcionar, pero estás exportando un sistema en vivo. Apaga primero a menos que intentes hacer un backup en caliente.

Decisión: Si es seguro, ejecuta wsl --shutdown y reintenta. Si no puedes, al menos detén servicios ruidosos en la distro (bases de datos, gestores de paquetes, bucles de compilación).

Segundo: ¿el almacenamiento de destino es lento o inestable?

cr0x@server:~$ robocopy E:\Backups\wsl E:\Backups\wsl_test dummy.bin /L
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------
ERROR : No Source Directory Specified.

Significado: Intentaste una copia sin sentido (a propósito) y Robocopy se quejó de inmediato. Eso es bueno: la herramienta responde. Ahora haz una prueba real de copia local con un archivo grande si sospechas problemas de disco.

Decisión: Si las copias al mismo disco son lentas, el cuello de botella es el almacenamiento local. Si solo las copias de red son lentas, es red o limitación del servidor.

Tercero: ¿la creación del tar está limitada por CPU (compresión) o por I/O (escrituras)?

El --export de WSL típicamente escribe un tar sin que elijas compresión. El costo pesado es leer muchos archivos pequeños y metadatos, y escribir un archivo grande y secuencial. Eso suele ser bound por I/O, pero el antivirus y protección endpoints pueden hacerlo parecer CPU-bound por los hooks.

Decisión: Si sospechas interferencia de protección endpoint, prueba exportar a un directorio excluido de escaneo en tiempo real (según la política). Si no puedes excluirlo, exporta a un disco local rápido primero y luego mueve.

Cuarto: ¿la distro es enorme por capas de contenedores o artefactos de compilación?

cr0x@server:~$ wsl -d Ubuntu-22.04 -- bash -lc 'sudo du -xh --max-depth=1 / | sort -h | tail'
4.2G	/usr
8.9G	/home
29G	/var
146G	/

Significado: Un /var masivo suele ser almacenamiento de contenedores (/var/lib/docker) o caches de paquetes.

Decisión: Decide si quieres respaldar ese estado. Si dependes de él para iteración rápida local, consérvalo. Si solo son capas cacheadas, límpialas antes de exportar y acepta reconstrucción más lenta luego.

Quinto: ¿la importación falla por permisos o rutas?

Importar a ubicaciones protegidas (como dentro de C:\Program Files) suele fallar o comportarse raro por ACLs.

Decisión: Importa en una ruta escribible por el usuario en una unidad de datos que controles (como D:\WSL\...), y mantenla consistente entre máquinas.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: El archivo de export existe pero la restauración no tiene tu usuario/home

Causa raíz: Exportaste el nombre de distro equivocado (o exportaste una distro base “limpia” que nunca usaste). Esto pasa mucho cuando la gente tiene Ubuntu más “Ubuntu Preview” más una distro de prueba.

Solución: Lista distros con wsl --list --verbose. Verifica dentro de cada distro cuál contiene tus datos en home (ls -la /home). Exporta la correcta.

2) Síntoma: La exportación falla con acceso denegado o escribe un tar de 0 bytes

Causa raíz: Permisos de la ruta destino, antivirus bloqueando, o el disco externo está formateado con un sistema/política que niega archivos grandes.

Solución: Exporta a una carpeta local bajo tu perfil (ej., C:\Users\...\Backups), verifica tamaño y luego muévelo con Robocopy. Además asegura que el destino soporte archivos grandes y no sea de solo lectura.

3) Síntoma: La exportación tarda horas y la máquina está lenta

Causa raíz: Gran número de archivos pequeños (node_modules, árboles de build), escaneo endpoint, o almacenamiento destino lento.

Solución: Podar directorios recreables antes de exportar, o mantener un backup “solo datos” para proyectos mientras usas export con menor frecuencia. Si la política lo permite, exporta a una ubicación excluida de escaneo y luego copia.

4) Síntoma: La importación tiene éxito, pero al lanzar la distro falla o te deja como root

Causa raíz: Usuario por defecto no configurado para la distro importada, o desajuste de metadatos de usuarios tras la restauración.

Solución: Lanza y configura tu usuario explícitamente. Si es necesario, ajusta la configuración de WSL para esa distro y asegúrate de que el usuario exista. Valida con id y getent passwd.

5) Síntoma: Copia de VHDX “restaura”, pero luego aparecen errores de sistema de archivos

Causa raíz: Copiaste el VHDX mientras WSL estaba en ejecución, capturando un estado de disco inconsistente.

Solución: Detén WSL (wsl --shutdown) antes de copiar. Prefiere export/import para recuperación ante desastres. Si ya tienes la copia mala, intenta reparar el sistema de archivos dentro de WSL (puede o no ayudar), y recurre a export tar si está disponible.

6) Síntoma: No encuentras los archivos de la distro tras un cambio de perfil de Windows

Causa raíz: Las distros WSL a menudo viven bajo los directorios de app data del perfil de usuario. Un perfil nuevo significa una ubicación nueva, y la anterior puede quedar huérfana.

Solución: Usa export/import de ahora en adelante. Si debes recuperar, localiza el directorio del perfil antiguo y sus datos de paquete WSL, y exporta desde esa instalación si es posible.

7) Síntoma: El backup es enorme incluso después de limpiar

Causa raíz: Datos de contenedores, caches de toolchains, o artefactos grandes en /home (imágenes de VM, conjuntos de datos, outputs de compilación).

Solución: Identifica los mayores consumidores con du. Decide qué es reconstruible. Si necesitas datasets, respáldalos por separado de la exportación WSL y móntalos en WSL desde Windows para un mejor manejo del ciclo de vida.

Tres mini-historias corporativas del mundo de “funciona en mi máquina”

Mini-historia 1: El incidente causado por una suposición errónea

El equipo tenía un documento de incorporación estándar: instala WSL, clona repos, corre builds. Un nuevo empleado lo siguió, ajustó algunos dotfiles y fue productivo rápido. Semanas después, su portátil recibió una reimagen corporativa rutinaria porque otra herramienta necesitaba una base de Windows más limpia. Nadie se preocupó—todo lo importante estaba “en Git”.

Excepto que no. El desarrollador había generado claves SSH, guardado un par de certificados CA internos en la distro y tenía una configuración local para un entorno de staging que nunca debió existir fuera del portátil, pero existía en WSL porque “parecía Linux”.

Tras la reimagen, WSL volvió vacío. Los repos fueron fáciles. Las claves no. Las solicitudes de acceso entraron en colas. Las compilaciones se bloquearon. On-call recibió pings porque una pipeline de CI empezó a fallar: alguien había usado temporalmente la máquina dev como firmador ad-hoc para un artefacto de prueba. Ahora la identidad de esa máquina había desaparecido.

La suposición errónea no fue “Git tiene todo”. Fue “WSL es efímero”. La solución fue aburrida: exportaciones programadas de WSL a un lugar corporativo cifrado, más una lista corta de lo que nunca debe vivir solo dentro de una distro. La nota del postmortem fue aún más aburrida: “trata los entornos dev como sistemas con estado”. Esa frase debería imprimirse en una pegatina y pegarse en cada portátil.

Mini-historia 2: La optimización que salió mal

Otra organización intentó acelerar backups copiando directamente archivos VHDX. Su razonamiento tenía sentido en papel: copiar un único archivo grande es más rápido que archivar millones de archivos pequeños. Montaron un script que copiaba el VHDX de la distro a un recurso de red cada noche.

Funcionó hasta que no. Algunos ingenieros empezaron a ejecutar cargas de contenedores en WSL2. Muchas escrituras. Mucha rotación. El trabajo de copia de VHDX a veces se solapaba con actividad intensa en disco. Nadie lo notó porque “el archivo se copió con éxito”. Copia exitosa no es lo mismo que snapshot consistente.

Semanas después, un desarrollador necesitó restaurar una distro tras una falla de disco. Insertaron el VHDX copiado y arrancaron. Se lanzó, luego empezó a dar errores de sistema de archivos bajo carga. La restauración fue peor que una reconstrucción limpia porque fallaba de maneras sutiles: problemas aleatorios en toolchains, archivos faltantes que deberían existir, base de paquetes corrupta. Depurar consumió días.

Hicieron rollback al VHDX de la noche anterior. Misma historia. Finalmente encontraron un tar export que alguien había tomado manualmente para una migración. Ese restauró correctamente.

La “optimización” falló porque optimizaron la métrica equivocada: velocidad de backup, no corrección de restauración. Mantuvieron copias de VHDX por conveniencia después, pero solo cuando WSL estaba apagado y como una capa secundaria. Export/import se convirtió en la fuente de la verdad para DR.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma consciente de seguridad tenía una regla simple para desarrolladores con WSL: export semanal, prueba de restauración mensual. No por paranoia. Porque ya les había pasado y no disfrutaban repetirlo.

Proporcionaron un script pequeño: listar distros, apagar WSL, exportar cada una con sello de fecha, hashearla y luego copiarla a una share protegida. El script también mantenía un pequeño manifiesto con hashes. La prueba de restauración era intencionalmente manual: importar el tar como un nombre nuevo de distro, arrancarlo, verificar unas rutas y comandos conocidos, y luego borrar la distro de prueba.

Un día, una actualización de Windows colisionó con un problema de driver de almacenamiento en un subconjunto de portátiles. Algunas máquinas dev volvieron con distros WSL que no arrancaban. No fue global, pero sí suficiente para causar interrupciones reales.

Los equipos con la práctica aburrida volvieron a la normalidad la misma mañana. Importaron el tar de la semana pasada, perdieron como mucho unos días de estado local y siguieron. Los demás abrieron tickets, esperaron y aprendieron por las malas que “me encargaré de los backups después” es solo una forma de reservar dolor con antelación.

Listas de verificación / plan paso a paso

Checklist A: Configuración única para una rutina de backup WSL confiable

1. Inventario de distros: identifica cuáles importan (dev, ciencia de datos, herramientas de ops).
2. Elige destinos de backup: disco local rápido para staging; externo cifrado o share protegido para retención.
3. Decide retención: diario/semanal/mensual, según cuánto estado local exista.
4. Decide política de secretos: si las exportaciones incluyen secretos, exige cifrado y ACLs restringidas.
5. Crea el hábito de prueba de restauración: importar mensualmente con un nombre nuevo y verificar flujos clave.

Checklist B: Pasos semanales “haz el backup” (grado operador)

1. Lista distros: wsl --list --verbose
2. Detén WSL: wsl --shutdown
3. Exporta cada distro crítica a staging local (disco rápido)
4. Hashea cada tar (SHA-256) y guarda el texto del hash por separado
5. Copia al destino a largo plazo usando una herramienta con reintentos
6. Vuelve a hashear en destino y compara
7. Opcional: importa un tar como distro de prueba y ejecuta una verificación básica

Checklist C: Restaurar tras catástrofe (reimagen, portátil nuevo, pérdida de disco)

1. Instala/actualiza la plataforma WSL (coincide con versión moderna)
2. Crea una ubicación de importación en una unidad de datos estable (ej., D:\WSL\...)
3. Importa el tar con un nombre nuevo de distro primero (no sobrescribas a ciegas)
4. Arranca, verifica usuario/home, verifica SSH, verifica repos
5. Cambia la distro por defecto una vez que estés seguro
6. Solo entonces elimina registros de distros rotas/antiguas

Checklist D: Plan opcional de “separación de datos” (mi configuración preferida)

Si tu distro WSL contiene datasets grandes o repos gigantes, considera separar:

• Mantén la distro pequeña: herramientas, configuraciones, estado mínimo.
• Almacena proyectos en el sistema de archivos de Windows en una ubicación controlada, montada en WSL (aplican compromisos).
• Respalda proyectos con tu herramienta normal de backup de estación de trabajo, independiente de exportaciones WSL.

Esto reduce el radio de impacto cuando WSL falla. También hace exportaciones más pequeñas y restauraciones más rápidas. No es gratis—el rendimiento entre sistemas de archivos y permisos puede ser incómodo—pero suele ser la compensación correcta en entornos corporativos.

Preguntas frecuentes

1) ¿Debo respaldar usando wsl --export o copiando el VHDX?

Por defecto usa wsl --export para portabilidad en recuperación ante desastres. Usa copias de VHDX solo cuando puedas apagar WSL de forma fiable primero y quieras restauraciones rápidas de “estado exacto”.

2) ¿Necesito ejecutar wsl --shutdown antes de exportar?

Deberías, a menos que aceptes riesgo. Exportar una distro en ejecución puede capturar estado inconsistente. Los sistemas tranquilos suelen sobrevivir; los ocupados eventualmente te castigarán.

3) ¿Dónde están almacenados mis archivos de distro WSL en Windows?

Normalmente bajo el app data local de tu perfil de usuario, dentro de un directorio de paquete para distros instaladas desde la tienda. Si importas a una ubicación personalizada, el VHDX vivirá donde se lo indiques. Por eso importar a D:\WSL\... es una buena idea.

4) ¿Puedo restaurar un export tar en otra máquina Windows?

Sí. Ese es el objetivo. Importa el tar con un nombre nuevo de distro y ubicación, luego valida que arranque y que tus datos estén allí.

5) ¿Por qué mi archivo tar de export es enorme?

Porque tu distro es enorme. Culpables comunes: /var/lib/docker, caches de lenguajes, artefactos de compilación y logs. Identifica con du, luego decide si conservar o podar contenido reconstruible.

6) Mi import funcionó, pero mi usuario por defecto es incorrecto. ¿Cómo lo arreglo?

Confirma que el usuario existe en la distro, luego configura tu usuario preferido por defecto para esa distro (el método depende del lanzador/config). Como chequeo rápido, arranca y ejecuta id; si eres root inesperadamente, corrige antes de trabajar en serio.

7) ¿Puedo automatizar backups de WSL?

Sí. Programa una tarea de Windows que ejecute: lista distros, apaga WSL, exporta a un path de staging, hashea y luego copia con reintentos. La automatización es buena. La automatización sin verificación es solo decepción más rápida.

8) ¿Cómo sé que mi backup es realmente restaurable?

Importalo con un nombre nuevo y pruébalo. Al menos: arranca, verifica tu directorio home, verifica un repos, verifica SSH. Ese es tu ejercicio de restauración.

9) ¿Debo comprimir más el tar (zip, 7z)?

A veces. La compresión puede ahorrar espacio pero cuesta CPU y tiempo, y añade otra capa que puede fallar. Si el almacenamiento es barato, manténlo simple. Si el almacenamiento está limitado, comprime y sé disciplinado con hashes y pruebas de restauración.

10) ¿Y si solo respaldo /home?

Es una estrategia válida si puedes reconstruir el resto rápida y consistentemente (dotfiles, paquetes, toolchains vía scripts). Es más rápido y pequeño. El riesgo es olvidar “esa cosa rara” que vivía en /etc o /usr/local.

Conclusión: siguientes pasos que puedes hacer hoy

Haz tres cosas y estarás por delante de la mayoría de equipos:

1. Ejecuta una exportación limpia hoy: apaga WSL, exporta tu distro principal, hashea y guarda el hash por separado.
2. Demuestra que puedes restaurar: importa el tar con un nombre nuevo y verifica tu directorio home y flujos de trabajo clave.
3. Hazlo rutinario: programa exportaciones semanales y una prueba de restauración mensual. Mantén el proceso aburrido, repetible y documentado.

WSL es lo suficientemente fiable como para adormecerte y hacerte olvidar que tiene estado. Tu trabajo es recordar—antes de que Windows “amablemente” lo recuerde por ti.