Sauvegarder les distributions WSL : export/import de la bonne manière

Ce que vous sauvegardez réellement (et pourquoi c’est important)

Les distributions WSL ne sont pas des dossiers magiques avec une ambiance manchot mignonne. Sous le capot, ce sont des systèmes de fichiers Linux vivant à l’intérieur d’un disque virtuel. Pour WSL2, il s’agit typiquement d’un fichier .vhdx situé sous votre profil Windows. WSL1 est différent : il stocke les fichiers plus « directement » dans les structures du système de fichiers Windows, et vous verrez des comportements de performance et de sauvegarde très différents.

Quand les gens perdent un environnement WSL, ce n’est rarement parce que Linux a fait quelque chose d’exotique. C’est parce que Windows a fait quelque chose de normal : réinitialisation du profil, changement de lettre de lecteur, politique de profil itinérant, quarantaine par antivirus, nettoyage « Storage Sense », ou une réinstallation « ça ira mieux ».

Il y a trois approches de sauvegarde dont vous entendrez parler :

1. Export/import WSL (tar) : canonique et portable, mais il faut savoir ce que cela capture et ce que cela ne capture pas.
2. Copier le VHDX : rapide et complet (inclut caches et bizarreries), mais plus fragile entre versions et plus susceptible d’être corrompu si vous le copiez pendant qu’il est monté et en cours de modification.
3. Sauvegarde depuis l’intérieur de Linux (rsync, etc.) : bonne pour des données ciblées, pas pour une image complète de distro sauf si vous êtes très délibéré.

Mon conseil partial : utilisez export/import comme sauvegarde « reprise après sinistre » par défaut, et conservez éventuellement des instantanés VHDX comme « restauration rapide » quand vous contrôlez l’hôte et le timing. Export/import est la voie ennuyeuse et compatible. L’ennui est bon. L’ennui restaure à 2h du matin.

Autre point : une sauvegarde qui n’a pas été restaurée n’est pas une sauvegarde. C’est un fichier qui vous rassure.

Faits intéressants et brève histoire (les éléments qui influencent les décisions)

• WSL1 et WSL2 sont fondamentalement différents : WSL1 traduit les appels système Linux ; WSL2 exécute un vrai noyau Linux dans une VM légère. Voilà pourquoi WSL2 est généralement plus compatible mais stocke les données dans un VHDX.
• WSL2 utilise un format de disque virtuel issu de l’univers Hyper‑V : VHDX prend en charge des disques plus grands et des fonctions de résilience par rapport à l’ancien VHD. C’est bon pour la croissance, et c’est aussi un rappel : traitez‑le comme un disque de VM.
• La performance du système de fichiers de WSL a changé la conversation sur les sauvegardes : les premiers modèles WSL1 s’appuyaient souvent sur l’accès côté Windows ; WSL2 a rendu les opérations de fichiers Linux plus rapides à l’intérieur du disque virtuel, mais l’accès Windows côté \\wsl$ peut être plus lent et plus délicat à sauvegarder de façon cohérente.
• L’ère des « apps du Store » compte : les distributions WSL proviennent fréquemment du Microsoft Store, ce qui signifie que les mises à jour et les flux de réinstallation ressemblent plus au cycle de vie d’une application qu’à une « installation Linux traditionnelle ». Super jusqu’à ce que la gestion d’image d’entreprise décide qu’elle sait mieux.
• WSL a ajouté le support de systemd plus tard : les anciennes hypothèses de sauvegarde/restauration concernant des services non lancés peuvent être fausses maintenant. Si systemd est activé, vous pouvez avoir plus d’état en arrière‑plan que vous voudrez calmer avant de prendre un instantané.
• Les choix de format d’export ont évolué : l’export WSL produit traditionnellement une archive tar. Les outils WSL plus récents ont ajouté des options qui affectent si vous exportez un rootfs de distro ou quelque chose de plus proche d’un instantané complet. Sachez ce que votre version prend en charge.
• L’emplacement de stockage par défaut a bougé dans l’esprit des gens, pas toujours en réalité : les utilisateurs pensent « c’est dans mon home Linux ». C’est généralement dans %LOCALAPPDATA% sous un dossier de package. Surprise pour la sauvegarde et la conformité.
• Le modèle réseau de WSL a évolué : NAT et modes miroir de WSL2 affectent quels secrets/configs importent (proxies, bundles de certificats, configs SSH). Les sauvegardes qui restaurent mais ne restaurent pas les attentes réseau échouent encore.

Le comportement sain par défaut : export/import, pas l’espoir

Export/import est le mécanisme de migration intégré de WSL. Ce n’est pas glamour. C’est aussi ce qui a le plus de chances de fonctionner après une réinstallation Windows, un changement de disque ou un nouveau portable.

Ce que l’export/import réussit bien

• Produit une archive de la distribution que vous pouvez stocker n’importe où (disque externe, partage réseau, coffre chiffré).
• Restaure sur une autre machine Windows sans se soucier de l’endroit où vivait le VHDX d’origine.
• Permet d’importer à un emplacement spécifique (comme D:\WSL\Ubuntu) pour séparer OS et données dev.

Ce que l’export/import ne résout pas magiquement

• Hygiène des secrets : si votre distro contient des clés/tokens, l’export les exporte. Décidez si cette archive doit être chiffrée au repos.
• Consistence des fichiers ouverts : exporter pendant que la distro écrit activement peut capturer un état « à peu près correct » jusqu’à ce que ce ne le soit plus.
• Bizarretés entre versions : importer une archive de distro ancienne dans un WSL beaucoup plus récent peut nécessiter une mise à jour des paquets.

Règle pratique : avant l’export, arrêtez la distro ou au moins terminez WSL pour que le système de fichiers soit silencieux. Vous verrez ce thème souvent parce que c’est la différence entre « je l’ai sauvegardé » et « j’ai sauvegardé une cible en mouvement ».

Blague n°1 : Sauvegarder un système en cours d’exécution sans le mettre en quiescence, c’est comme photographier un colibri avec une patate — techniquement possible, émotionnellement coûteux.

Tâches pratiques (commandes, sorties et décisions)

Voici des tâches d’opérateur réelles. Chacune inclut : la commande, une sortie exemple, ce que la sortie signifie, et la décision suivante. Exécutez-les dans PowerShell ou CMD quand approprié ; la gestion WSL se fait côté Windows.

Task 1: List installed distros and see what’s running

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

Signification : Vous avez trois distributions. Ubuntu-22.04 est en cours d’exécution, donc son disque est monté et peut changer.

Décision : Si vous effectuez un export complet, prévoyez de l’arrêter d’abord (ou acceptez le risque pour des données non critiques).

Task 2: Shut down WSL cleanly (quiesce everything)

cr0x@server:~$ wsl --shutdown

Signification : La VM et les distributions WSL sont terminées. Aucune sortie est normale.

Décision : Procédez à l’export ou à la copie du VHDX avec un risque bien moindre d’état incohérent.

Task 3: Export a distro to a tar archive (portable backup)

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

Signification : Vous avez maintenant une archive tar qui peut être importée ailleurs.

Décision : Vérifiez immédiatement la taille et le hash du fichier ; ne faites pas confiance à la simple existence d’un fichier.

Task 4: Validate backup size and timestamp (cheap sanity check)

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

Signification : L’export a produit un tar d’environ 12,8 Go. Si votre distro est massive et que le tar est minuscule, quelque chose cloche (ou vous êtes essentiellement vide).

Décision : Si la taille est suspectement petite, relancez l’export après avoir vérifié que le nom de la distro est correct et que WSL a accès au disque de destination.

Task 5: Hash the tar to detect corruption (and enable dedupe on your side)

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.

Signification : Vous avez une empreinte d’intégrité que vous pouvez stocker à côté de la sauvegarde.

Décision : Si ce fichier quitte la machine (NAS/cloud), stockez le hash séparément et revérifiez après le transfert.

Task 6: Confirm you can read the tar (basic archive integrity)

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

Signification : Le tar est lisible et contient des chemins attendus.

Décision : Si tar -tf renvoie une erreur (EOF inattendu, erreurs de checksum), jetez la sauvegarde et refaites l’export — de préférence après wsl --shutdown et vers un autre disque.

Task 7: See where a distro actually lives (so you know what you’re moving)

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

Signification : À l’intérieur de WSL2, cela ressemble à un périphérique bloc. Cela n’affiche pas le chemin Windows, mais indique la taille logique et l’utilisation.

Décision : Si l’utilisation est énorme, attendez‑vous à ce que l’export prenne du temps et produise un tar volumineux. Envisagez d’élaguer les caches avant la sauvegarde si le temps compte.

Task 8: Clean up obvious space hogs before export (optional, but effective)

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

Signification : /var/cache et les logs sont lourds ; peut‑être avez‑vous de vieux paquets, des couches de conteneur ou un log spammeur.

Décision : Si c’est une station de développement et que les caches reconstruits sont reproductibles, nettoyez‑les et exportez un tar plus petit.

Task 9: Actually clean apt caches and old packages (don’t get cute)

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) ...

Signification : Espace récupéré. Les exports seront plus petits et plus rapides.

Décision : Si cette distro sert au travail sur noyau/modules ou à des toolchains figés, n’exécutez pas autoremove à l’aveugle ; sauvegardez d’abord, puis élaguez. « Sauvegarde plus petite » ne vaut pas « build cassé ».

Task 10: Export after cleaning (and verify again)

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

Signification : Vous avez une nouvelle archive. Attendez‑vous à ce qu’elle soit plus petite si le nettoyage a réduit la taille.

Décision : Conservez au moins une sauvegarde « non nettoyée » périodique si vous craignez d’effacer quelque chose que vous regretterez plus tard (comme un artefact local jamais poussé).

Task 11: Import to a specific location (migration or restore)

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

Signification : Une nouvelle distro est créée nommée Ubuntu-22.04-Restored à l’emplacement choisi.

Décision : Faites cela pour tester les restaurations. Ne remplacez pas votre distro en production tant que la restaurée n’a pas démarré et ne contient pas vos données.

Task 12: Verify the restored distro boots and has expected users/files

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

Signification : L’utilisateur par défaut et le contenu du répertoire home existent. C’est un contrôle basique « il est vivant ».

Décision : Ensuite, validez les éléments spécifiques qui vous importent : dépôts, clés SSH, dotfiles, toolchains de build et tout état de service dont vous dépendez.

Task 13: Set the default distro (after you’re confident)

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

Signification : Exécuter wsl sans arguments lancera désormais la distro restaurée.

Décision : Ne le faites qu’après que votre restauration a fait ses preuves pendant une journée de travail réelle.

Task 14: Check WSL version and status (debugging export/import weirdness)

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

Signification : Cela indique la plateforme WSL sur laquelle vous êtes. Des incompatibilités de version sont une vraie cause de surprises à la restauration.

Décision : Si vous restaurez depuis une machine beaucoup plus ancienne, envisagez de mettre WSL à jour d’abord pour que le comportement d’import corresponde à vos attentes.

Task 15: Export to a network path (and decide if it’s worth it)

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

Signification : Il écrit directement sur un chemin UNC. Pratique, mais souvent plus lent et plus sujet aux échecs si le Wi‑Fi a des ratés.

Décision : Pour la fiabilité : exportez localement, hachez, puis copiez vers le réseau avec un outil qui réessaie (et rehachez après la copie).

Task 16: Copy with verification semantics (robust transfer)

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

Signification : La copie a réussi, elle montre la vitesse et le comportement de retry. Si vous voyez FAILED > 0, vous n’avez pas une sauvegarde sur le serveur, vous avez une histoire.

Décision : Rehachez le fichier de destination et comparez‑le avec le hash source. Si différent, recopiez ou investiguez un stockage/réseau instable.

Conception de sauvegarde : à quoi ressemble du « bon » pour WSL

Décidez ce que vous protégez

La plupart des distributions WSL contiennent un mélange de :

• Irremplaçable : clés, certificats, configurations locales, commits non poussés, notebooks, scripts.
• Reconstituable : installations de paquets, toolchains de langage, images de conteneur, sorties de build.
• Actuellement nuisible : caches qui gonflent les sauvegardes et rallongent les restaurations sans avantage.

Votre stratégie de sauvegarde doit en tenir compte. L’objectif n’est pas de préserver chaque octet. L’objectif est de préserver les octets qui vous manqueront quand la machine brûlera et que votre agenda ne sera pas compatissant.

Export/import vs copie VHDX : choisissez délibérément

Export/import (tar) est votre plan de portabilité. C’est ce que vous faites quand vous prévoyez que l’hôte change : nouveau portable, réinstallation OS, reimage d’entreprise, déplacement entre disques, ou quand vous voulez une reconstruction propre qui n’emporte pas autant d’état caché.

Copie VHDX est votre instantané « lift and shift » rapide. Elle peut vous restaurer dans l’état exact, mais elle est plus sensible à la consistance et à la manière dont vous la copiez.

Si vous insistez pour copier le VHDX : arrêtez WSL d’abord. Si vous le copiez pendant que WSL tourne, vous misez l’environnement sur un timing. Le timing n’est pas une stratégie.

Chiffrement et contrôle d’accès : votre tar est un sac de secrets

Les fichiers tar exportés incluent souvent :

• ~/.ssh
• ~/.gnupg
• identifiants cloud et tokens CLI
• ~/.kube/config et certificats de cluster
• secrets d’application dans des fichiers .env oubliés

Cela signifie que la destination de sauvegarde compte. Si c’est un partage partagé, votre modèle de menace vient de changer. Si c’est un SSD externe personnel, chiffre‑le. Si c’est un stockage d’entreprise, assurez‑vous que les permissions sont correctes et auditées.

Rétention : conservez moins mais rendez-les fiables

Pour des postes de développeurs, un schéma de rétention pratique :

• Export quotidien pendant 7 jours
• Export hebdomadaire pendant 4–8 semaines
• Export mensuel pendant 6–12 mois (si conformité ou recherche longue durée)

Plus que ça tend à pourrir parce que personne ne vérifie les restaurations. Gardez moins, vérifiez‑les, et dormez mieux.

Une citation qui compte

L’espoir n’est pas une stratégie. — idée paraphrasée couramment répétée dans les cercles fiabilité/ops (attribuée largement, pas à une source unique).

Blague n°2 : Si votre plan de sauvegarde est « je penserai à exporter avant de réinstaller », félicitations — vous venez d’inventer un rappel de calendrier qui vous en veut.

Mode d’emploi pour un diagnostic rapide (trouver le goulot vite)

Les exports prennent parfois une éternité, les imports parfois « bloquent », et les copies parfois rampent. Ne devinez pas. Triez.

Première étape : WSL tourne‑t‑il encore ou est‑il bloqué ?

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

Si c’est Running : L’export peut encore fonctionner, mais vous exportez un système vivant. Arrêtez‑le d’abord sauf si vous faites volontairement une sauvegarde à chaud.

Décision : Si possible, exécutez wsl --shutdown et réessayez. Si vous ne pouvez pas, au moins arrêtez les services bavards dans la distro (bases de données, gestionnaires de paquets, boucles de build).

Deuxième étape : le stockage de destination est‑il lent ou instable ?

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

Signification : Vous avez lancé une copie sans sens (intentionnellement) et Robocopy s’est plaint immédiatement. C’est bon : l’outil répond. Faites maintenant un test de copie local réel avec un gros fichier si vous suspectez un disque défaillant.

Décision : Si les copies sur le même disque sont lentes, votre goulot est le stockage local. Si seules les copies réseau sont lentes, c’est le réseau ou la limitation côté serveur.

Troisième étape : la création du tar est‑elle CPU‑bound (compression) ou I/O‑bound (écritures) ?

L’option --export de WSL écrit typiquement un tar sans que vous choisissiez la compression. Le coût lourd est la lecture de nombreux petits fichiers et métadonnées, et l’écriture d’un gros fichier séquentiel. C’est généralement I/O‑bound, mais l’antivirus et la protection endpoint peuvent donner l’impression que c’est CPU‑bound à cause des hooks.

Décision : Si vous suspectez une interférence de la protection endpoint, testez l’export sur un répertoire exclu du scan en temps réel (selon la politique). Si vous ne pouvez pas exclure, exportez d’abord sur un disque local rapide, puis déplacez‑le.

Quatrième étape : la distro est‑elle énorme à cause des couches de conteneur ou des artefacts de build ?

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	/

Signification : Un /var massif est souvent le stockage des conteneurs (/var/lib/docker) ou des caches de paquets.

Décision : Décidez si vous voulez sauvegarder cet état. Si vous en dépendez pour une itération locale rapide, conservez‑le. Si ce ne sont que des couches en cache, nettoyez‑avant l’export et acceptez une reconstruction plus longue ensuite.

Cinquième étape : l’import échoue‑t‑il pour des raisons d’autorisations ou de chemin ?

Les imports vers des emplacements protégés (comme C:\Program Files) échouent souvent ou se comportent bizarrement à cause des ACL.

Décision : Importez sous un chemin accessible en écriture par l’utilisateur sur un disque de données que vous contrôlez (par exemple D:\WSL\...), et gardez‑le cohérent entre les machines.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: Export file exists but restore is missing your user/home

Cause racine : Vous avez exporté le mauvais nom de distro (ou un « base » propre que vous n’utilisiez pas). Cela arrive souvent quand les gens ont Ubuntu plus « Ubuntu Preview » plus une distro de test.

Correctif : Listez les distros avec wsl --list --verbose. Vérifiez à l’intérieur de chaque distro laquelle contient votre répertoire home (ls -la /home). Exportez la bonne.

2) Symptom: Export fails with access denied or writes a 0-byte tar

Cause racine : Permissions du chemin de destination, antivirus bloquant, ou le disque externe est formaté avec un système/politique qui interdit les gros fichiers.

Correctif : Exportez dans un dossier local sous votre profil (par ex. C:\Users\...\Backups), vérifiez la taille, puis déplacez avec Robocopy. Assurez‑vous aussi que la destination supporte les gros fichiers et n’est pas en lecture seule.

3) Symptom: Export takes hours and the machine is sluggish

Cause racine : Grand nombre de petits fichiers (node_modules, arbres de build), scan endpoint, ou stockage de destination lent.

Correctif : Élaguez les répertoires reconstituables avant l’export, ou maintenez une sauvegarde « données uniquement » séparée pour les projets tout en utilisant l’export moins fréquemment. Si la politique le permet, exportez vers un emplacement exclu du scan puis copiez.

4) Symptom: Import succeeds, but launching the distro fails or drops you into root

Cause racine : L’utilisateur par défaut n’est pas défini pour la distro importée, ou désaccord des métadonnées utilisateur après la restauration.

Correctif : Lancez et définissez explicitement votre utilisateur. Si nécessaire, ajustez la config WSL pour cette distro et assurez‑vous que l’utilisateur existe. Validez avec id et getent passwd.

5) Symptom: VHDX copy “restores,” but filesystem errors appear later

Cause racine : Vous avez copié le VHDX pendant que WSL tournait, capturant un état de disque incohérent.

Correctif : Arrêtez WSL (wsl --shutdown) avant de copier. Préférez export/import pour la reprise après sinistre. Si vous avez déjà une mauvaise copie, essayez une réparation du système de fichiers dans WSL (peut ou non aider), et retombez sur l’export tar si disponible.

6) Symptom: You can’t find the distro files after a Windows profile change

Cause racine : Les distributions WSL vivent souvent dans les dossiers AppData du profil utilisateur. Un nouveau profil signifie un nouvel emplacement, et l’ancien peut être orphelin.

Correctif : Utilisez export/import à l’avenir. Si vous devez récupérer, localisez l’ancien dossier de profil et ses données de package WSL, puis exportez depuis cette installation si possible.

7) Symptom: Backup is huge even after cleanup

Cause racine : Données de conteneur, caches de toolchains, ou gros artefacts sous /home (images VM, datasets, sorties de build).

Correctif : Identifiez les gros consommateurs avec du. Décidez ce qui est reconstituable. Si vous avez besoin de datasets, sauvegardez‑les séparément de l’export WSL et montez‑les dans WSL depuis Windows pour une gestion de cycle de vie meilleure.

Trois mini-histoires d’entreprise du pays du « ça marche sur ma machine »

Mini-story 1: The incident caused by a wrong assumption

L’équipe avait une doc d’onboarding standard : installer WSL, cloner les dépôts, lancer les builds. Un nouveau collaborateur l’a suivie, a ajusté quelques dotfiles, et est devenu productif rapidement. Des semaines plus tard, son portable a subi une réimage d’entreprise de routine parce qu’un autre outil nécessitait une base Windows plus propre. Personne ne s’est inquiété — tout important était « dans Git ».

Sauf que non. Le développeur avait généré des clés SSH, stocké quelques certificats CA internes dans la distro, et avait une config locale uniquement pour un environnement de staging qui n’aurait jamais dû exister hors du portable, mais qui existait. Ces éléments n’étaient pas dans Git pour de bonnes raisons. Ils étaient dans WSL parce que ça « ressemblait à Linux ».

Après la réimage, WSL est revenu vide. Les dépôts étaient faciles à récupérer. Les clés, non. Les demandes d’accès se sont retrouvées en file d’attente. Les builds ont bloqué. L’astreinte a été pingée parce qu’un pipeline CI a commencé à échouer : quelqu’un avait « temporairement » utilisé la machine dev comme signataire ad hoc pour un artefact de test. Maintenant l’identité de cette machine avait disparu.

L’hypothèse erronée n’était pas « Git contient tout ». C’était « WSL est éphémère ». La correction a été ennuyeuse : exports WSL programmés vers un emplacement chiffré d’entreprise, plus une liste courte de ce qui ne doit jamais vivre uniquement dans une distro. Le postmortem disait encore plus ennuyeusement : « traitez les environnements dev comme des systèmes avec état. » Cette ligne devrait être imprimée sur un autocollant et collée sur chaque portable.

Mini-story 2: The optimization that backfired

Une autre organisation a tenté d’accélérer les sauvegardes en copiant directement les fichiers VHDX. Leur raisonnement tenait sur le papier : copier un gros fichier est plus rapide qu’archiver des millions de petits fichiers. Ils ont mis en place un script qui copiait le VHDX de la distro sur un partage réseau chaque nuit.

Ça a marché jusqu’à ce que ça ne marche plus. Quelques ingénieurs ont commencé à exécuter des workloads conteneurisés dans WSL2. Beaucoup d’écritures. Fort turnover. Le job de copie VHDX a parfois chevauché une activité disque intense. Personne n’a remarqué parce que « le fichier s’est copié avec succès ». Une copie réussie n’équivaut pas à un snapshot cohérent.

Des semaines plus tard, un développeur a voulu restaurer une distro après une panne de disque. Ils ont inséré le VHDX copié et ont booté. Ça a démarré, puis a commencé à lancer des erreurs système de fichiers sous charge. La restauration était pire qu’une reconstruction propre parce qu’elle échouait de façon subtile : problèmes aléatoires de toolchain, fichiers manquants qui auraient dû exister, base de paquets corrompue. Le débogage a mangé des jours.

Ils sont revenus à la copie VHDX de la nuit précédente. Même histoire. Finalement, ils ont trouvé un ancien export tar qu’un collègue avait pris manuellement pour une migration. Ça a restauré proprement.

L’« optimisation » a échoué parce qu’ils ont optimisé le mauvais métrique : la vitesse de sauvegarde, pas la correction de la restauration. Ils ont conservé des copies VHDX par commodité ensuite, mais seulement quand WSL était arrêté et seulement comme couche secondaire. Export/import est redevenu la source de vérité DR.

Mini-story 3: The boring but correct practice that saved the day

Une équipe plateforme soucieuse de la sécurité avait une règle simple pour les développeurs utilisant WSL : export hebdomadaire, test de restauration mensuel. Pas par paranoïa. Parce qu’ils s’étaient déjà fait avoir, et ils n’aimaient pas se répéter.

Ils fournissaient un petit script : lister les distros, arrêter WSL, exporter chacune vers un tar horodaté, hacher, puis copier vers un partage protégé. Le script gardait aussi un petit fichier manifeste avec les hashes. Le test de restauration était volontairement manuel : importer le tar sous un nouveau nom de distro, booter, vérifier quelques chemins et commandes connues, puis supprimer la distro test.

Un jour, une mise à jour Windows a coïncidé avec un problème de pilote de stockage sur un sous‑ensemble de portables. Quelques machines dev sont revenues avec des distros WSL qui ne démarraient plus. Ce n’était pas global, mais suffisant pour causer une vraie perturbation.

Les équipes avec la pratique ennuyeuse étaient opérationnelles le matin même. Elles ont importé le tar de la semaine précédente, ont perdu au plus quelques jours d’état local seulement, et ont continué. Les autres ont ouvert des tickets, attendu, et appris à la dure que « je m’occuperai des sauvegardes plus tard » est juste une façon de préprogrammer la douleur.

Checklists / plan étape par étape

Checklist A: One-time setup for a trustworthy WSL backup routine

1. Inventaire des distros : identifiez lesquelles comptent (développement, data science, outils ops).
2. Choisissez les destinations de sauvegarde : disque local rapide pour la mise en scène ; externe chiffré ou partage protégé pour la rétention.
3. Décidez la rétention : quotidien/hebdomadaire/mensuel, selon l’état local non synchronisé.
4. Définissez une politique pour les secrets : si les exports incluent des secrets, exigez chiffrement et ACL restreintes.
5. Créez l’habitude du test de restauration : import mensuel sous un nouveau nom et vérification des workflows clés.

Checklist B: Weekly “do the backup” steps (operator-grade)

1. Lister les distros : wsl --list --verbose
2. Arrêter WSL : wsl --shutdown
3. Exporter chaque distro critique vers la mise en scène locale (disque rapide)
4. Hacher chaque tar (SHA-256) et stocker le texte du hash séparément
5. Copier vers la destination long terme avec un outil à retries
6. Rehacher à destination et comparer
7. Optionnel : importer un tar comme distro de test et exécuter une vérification basique

Checklist C: Restore after catastrophe (reimage, new laptop, disk loss)

1. Installer/mettez à jour la plateforme WSL (match version moderne)
2. Créer un emplacement d’import sur un disque de données stable (ex. D:\WSL\...)
3. Importer le tar sous un nouveau nom de distro d’abord (ne pas écraser aveuglément)
4. Lancer, vérifier user/home, vérifier SSH, vérifier dépôts
5. Changer la distro par défaut une fois sûr
6. Alors seulement, supprimer les enregistrements de distro cassés/anciens

Checklist D: Optional “data separation” plan (my preferred setup)

Si votre distro WSL contient de gros datasets ou de gros dépôts, envisagez de séparer :

• Gardez la distro petite : outils, configs, état minimal.
• Stockez les projets sur le système de fichiers Windows dans un emplacement contrôlé, monté dans WSL (compromis existants).
• Sauvegardez les projets avec votre outil de sauvegarde poste de travail habituel, indépendamment des exports WSL.

Cela réduit le rayon d’impact quand WSL casse. Cela rend aussi les exports plus petits et les restaurations plus rapides. Ce n’est pas gratuit — performances cross‑FS et permissions peuvent être agaçantes — mais c’est souvent le bon compromis en entreprise.

FAQ

1) Should I back up using wsl --export or by copying the VHDX?

Par défaut, préférez wsl --export pour la portabilité et la reprise après sinistre. N’utilisez les copies VHDX que si vous pouvez arrêter WSL de façon fiable et que vous souhaitez des restaurations rapides à l’état exact.

2) Do I need to run wsl --shutdown before exporting?

Vous devriez, sauf si vous acceptez le risque. Exporter une distro en cours d’exécution peut capturer un état incohérent. Les systèmes calmes s’en sortent souvent. Les systèmes occupés finissent par vous punir.

3) Where are my WSL distro files stored on Windows?

Typiquement sous l’app data local de votre profil utilisateur, dans un dossier de package pour les distros installées via le Store. Si vous importez vers un emplacement personnalisé, le VHDX vivra là où vous l’avez indiqué. C’est pourquoi importer dans D:\WSL\... est une bonne idée.

4) Can I restore a tar export onto a different Windows machine?

Oui. C’est le but. Importez le tar sous un nouveau nom de distro et emplacement, puis validez qu’il démarre et que vos données sont là.

5) Why is my export tar file enormous?

Parce que votre distro est énorme. Coupables courants : /var/lib/docker, caches de langages, artefacts de build et logs. Identifiez avec du, puis décidez de conserver ou d’élaguer le contenu reconstituable.

6) My import worked, but my default user is wrong. How do I fix it?

Confirmez que l’utilisateur existe dans la distro, puis définissez votre utilisateur par défaut pour cette distro (la méthode dépend de votre launcher/config). Comme vérification rapide, lancez et exécutez id ; si vous êtes root de façon inattendue, corrigez avant de travailler.

7) Can I automate WSL backups?

Oui. Planifiez une tâche Windows qui exécute : lister les distros, arrêter WSL, exporter vers un chemin de mise en scène, hacher, puis copier avec retries. L’automatisation est bonne. L’automatisation sans vérification n’est qu’une déception accélérée.

8) How do I know my backup is actually restorable?

Importez‑la sous un nouveau nom et testez‑la. Au minimum : booter, vérifier votre répertoire home, vérifier un dépôt, vérifier SSH. C’est votre exercice de restauration.

9) Should I compress the tar further (zip, 7z)?

Parfois. La compression peut économiser de l’espace mais coûte du CPU et du temps, et ajoute une couche supplémentaire qui peut échouer. Si le stockage est bon marché, gardez‑le simple. Si le stockage est contraint, compressez et soyez rigoureux sur les hashes et les tests de restauration.

10) What about backing up only /home?

C’est une stratégie valide si vous pouvez reconstruire le reste rapidement et de façon reproductible (dotfiles, paquets, toolchains via scripts). C’est plus rapide et plus petit. Le risque est d’oublier « une chose bizarre » qui vivait dans /etc ou /usr/local.

Conclusion: next steps you can do today

Faites trois choses et vous serez en avance sur la plupart des équipes :

1. Exécutez un export propre aujourd’hui : arrêtez WSL, exportez votre distro principale, hachez‑la et stockez le hash séparément.
2. Prouvez que vous pouvez restaurer : importez le tar sous un nouveau nom et vérifiez votre répertoire home et vos workflows clés.
3. Rendez‑le routinier : planifiez des exports hebdomadaires et un test de restauration mensuel. Gardez le processus ennuyeux, répétable et documenté.

WSL est suffisamment fiable pour vous endormir en oubliant qu’il a de l’état. Votre travail est de vous en souvenir — avant que Windows ne « vous aide » en s’en souvenant à votre place.