Back Up WSL Distros: Export/Import the Right Way

What you’re actually backing up (and why it matters)

WSL distributions are not magic folders with cute penguin vibes. Under the hood, they’re Linux filesystems living inside a virtual disk. For WSL2, that’s typically a .vhdx file sitting under your Windows profile. WSL1 is different: it stores files more “directly” in Windows filesystem structures, and you’ll see very different performance and backup behavior.

When people lose a WSL environment, it’s rarely because Linux did something exotic. It’s because Windows did something normal: a profile reset, a drive letter change, a roaming profile policy, an antivirus quarantine, a “storage sense” cleanup, or a “just reinstall and it’ll be fine” refurb.

There are three backup approaches you’ll hear about:

1. WSL export/import (tar): canonical and portable, but you need to be aware of what it captures and what it doesn’t.
2. Copy the VHDX: fast and complete (including caches and weirdness), but more brittle across versions and more likely to be corrupted if you copy it while it’s mounted and changing.
3. Backup from inside Linux (rsync, etc.): good for targeted data, not a full distro image unless you’re very deliberate.

My opinionated guidance: use export/import as your default “disaster recovery” backup, and optionally keep VHDX snapshots as “fast restore” when you control the host and the timing. Export/import is the boring, compatible path. Boring is good. Boring restores at 2 a.m.

Also: a backup that hasn’t been restored is not a backup. It’s a file that makes you feel better.

Interesting facts & short history (the parts that change decisions)

• WSL1 and WSL2 are fundamentally different: WSL1 translates Linux syscalls; WSL2 runs a real Linux kernel in a lightweight VM. That’s why WSL2 is generally more compatible but stores data in a VHDX.
• WSL2 uses a virtual disk format from the Hyper-V world: VHDX supports larger disks and resilience features compared to older VHD. That’s good for growth, and also a reminder: treat it like a VM disk.
• WSL’s filesystem performance changed the backup conversation: early WSL1 patterns often relied on Windows-side file access; WSL2 made Linux filesystem operations faster inside the virtual disk, but Windows-side access into \\wsl$ can be slower and trickier to back up consistently.
• The “store apps” era matters: WSL distributions frequently come from the Microsoft Store, which means updates and reinstall flows resemble app lifecycle behavior more than “traditional Linux install.” Great until your corporate image management decides it knows better.
• WSL gained systemd support later: older backup/restore assumptions about services not running may be wrong now. If systemd is enabled, you can have more background state that you may want to quiet before snapshotting.
• Export format choices evolved: WSL export traditionally produces a tar archive. Newer WSL tooling added options that affect whether you’re exporting a distro rootfs or something closer to a full snapshot. Know what your version supports.
• Default storage location moved in people’s minds, not always in reality: users think “it’s in my Linux home.” It’s usually in %LOCALAPPDATA% under a package folder. That’s a backup and compliance surprise.
• WSL’s networking model changed over time: WSL2 NAT and mirrored modes affect which secrets/configs matter (proxies, cert bundles, SSH configs). Backups that restore but don’t restore network expectations still fail.

The sane default: export/import, not hope

Export/import is WSL’s built-in migration mechanism. It’s not glamorous. It’s also the thing most likely to work after you wipe and rebuild your Windows machine, change drives, or move to a new laptop.

What export/import does well

• Produces a distro archive that you can store anywhere (external drive, network share, encrypted vault).
• Restores onto another Windows machine without caring about where the original VHDX lived.
• Lets you import to a specific location (like D:\WSL\Ubuntu) so you can keep OS and dev data separate.

What export/import does not magically solve

• Secrets hygiene: if your distro contains keys/tokens, exporting is exporting secrets. Decide whether that archive is encrypted at rest.
• Open file consistency: exporting while the distro is actively writing can capture a state that is “mostly fine” until it isn’t.
• Cross-version oddities: importing an ancient distro archive into a much newer WSL can require a package update dance.

Rule of thumb: before export, stop the distro or at least terminate WSL so the filesystem is quiet. You’ll see this theme a lot because it’s the difference between “I backed it up” and “I backed up a moving target.”

Joke #1: Backing up a running system without quiescing it is like photographing a hummingbird with a potato—technically possible, emotionally expensive.

Practical tasks (commands, outputs, and decisions)

These are real operator tasks. Each one includes: the command, sample output, what the output means, and what you decide next. Run them in PowerShell or CMD where appropriate; WSL management is a Windows-side control plane.

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

Meaning: You have three distros. Ubuntu-22.04 is running, so its disk is actively mounted and may be changing.

Decision: If you’re doing a full backup export, plan to stop it first (or accept risk for non-critical data).

Task 2: Shut down WSL cleanly (quiesce everything)

cr0x@server:~$ wsl --shutdown

Meaning: WSL’s VM and distros are terminated. No output is normal.

Decision: Proceed with export or VHDX copy with much lower risk of inconsistent state.

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

Meaning: You now have a tar archive that can be imported elsewhere.

Decision: Immediately verify the file size and hash; do not trust the mere existence of a file.

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

Meaning: The export produced a ~12.8 GB tar. If your distro is huge and the tar is tiny, something’s wrong (or you’re mostly empty).

Decision: If size is suspiciously small, re-run export after ensuring the distro name is correct and WSL had access to the destination drive.

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.

Meaning: You have an integrity fingerprint you can store next to the backup.

Decision: If this file is going off-machine (NAS/cloud), store the hash separately and re-check after transfer.

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

Meaning: The tar is readable and contains expected paths.

Decision: If tar -tf errors (unexpected EOF, checksum errors), discard the backup and export again—preferably after wsl --shutdown and to a different disk.

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% /

Meaning: Inside WSL2, this looks like a block device. That doesn’t show the Windows path, but it tells you the logical size and usage.

Decision: If usage is huge, expect export to take time and produce a large tar. Consider pruning caches before backup if time matters.

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

Meaning: /var/cache and logs are heavy; maybe you’ve got old packages, container layers, or a log spammer.

Decision: If this is a developer workstation and reproducible caches don’t need to be backed up, clean them and export a smaller tar.

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

Meaning: Space reclaimed. Exports will be smaller and faster.

Decision: If this distro is used for kernel/module work or pinned toolchains, don’t autoremove blindly; backup first, then prune. “Smaller backup” is not worth “broken build.”

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

Meaning: You have a new archive. Expect it to be smaller if the cleanup mattered.

Decision: Keep at least one “uncleaned” periodic backup if you’re worried you’ll delete something you later regret (like a local artifact you never pushed).

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

Meaning: A new distro is created named Ubuntu-22.04-Restored at your chosen location.

Decision: Do this for testing restores. Don’t overwrite your working distro until you’ve confirmed the restored one boots and has your data.

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

Meaning: The default user and home directory content exists. That’s a basic “it’s alive” check.

Decision: Next, validate the specific things you care about: repos, SSH keys, dotfiles, build toolchains, and any service state you rely on.

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

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

Meaning: Running wsl without arguments will now launch the restored distro.

Decision: Only do this after your restore has proven itself for a day of real work.

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

Meaning: This tells you what WSL platform you’re on. Version mismatches are a real cause of restore surprises.

Decision: If you’re restoring from a much older machine, consider updating WSL first so import behavior matches your expectations.

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

Meaning: It writes directly to a UNC path. This can be convenient, but can also be slower and more failure-prone if Wi‑Fi hiccups.

Decision: For reliability: export locally, hash, then copy to network with a tool that retries (and re-hash after copy).

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

Meaning: Copy succeeded, shows speed and retry behavior. If you see FAILED > 0, you don’t have a backup on the server, you have a story.

Decision: Re-hash the destination file and compare with the source hash. If different, recopy or investigate flaky storage/network.

Backup design: what “good” looks like for WSL

Decide what you’re protecting

Most WSL distros contain a blend of:

• Irreplaceable: keys, certs, local config, unpushed commits, notebooks, scripts.
• Rebuildable: package installs, language toolchains, container images, build outputs.
• Actively hostile: caches that bloat backups and add restore time with no upside.

Your backup strategy should reflect that. The point isn’t to preserve every byte. The point is to preserve the bytes you’ll miss when the machine is on fire and your calendar is not sympathetic.

Export/import vs VHDX copy: pick deliberately

Export/import (tar) is your portability play. It’s what you do when you expect the host to change: new laptop, OS reinstall, corporate reimage, moving between disks, or when you want a clean “rebuild” that doesn’t carry as much hidden state.

VHDX copy is your fast “lift and shift” snapshot. It can restore you to the exact same state, but it’s more sensitive to consistency and to how you copy it.

If you insist on copying VHDX: shut down WSL first. If you copy it while WSL is running, you’re betting your environment on timing. Timing is not a strategy.

Encryption and access control: your tar is a bag of secrets

Exported tar files often include:

• ~/.ssh
• ~/.gnupg
• cloud credentials and CLI tokens
• ~/.kube/config and cluster certs
• application secrets in .env files you forgot you had

That means your backup destination matters. If it’s a shared drive, your threat model just changed. If it’s a personal external SSD, encrypt it. If it’s corporate storage, ensure permissions are correct and audited.

Retention: keep fewer backups, but make them trustworthy

For developer workstations, a practical retention pattern:

• Daily export for 7 days
• Weekly export for 4–8 weeks
• Monthly export for 6–12 months (if compliance or long-running research matters)

More than that tends to rot because nobody verifies restores. Keep fewer, verify them, and sleep better.

One quote that matters

Hope is not a strategy. — paraphrased idea commonly repeated in reliability/operations circles (attributed broadly, not pinned to one exact source).

Joke #2: If your backup plan is “I’ll remember to export before I reinstall,” congratulations—you’ve invented a calendar reminder that hates you.

Fast diagnosis playbook (find the bottleneck fast)

Exports sometimes take forever, imports sometimes “hang,” and copies sometimes crawl. Don’t guess. Triage.

First: is WSL still running or stuck?

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

If it’s Running: Export may still work, but you’re exporting a live system. Shutdown first unless you’re intentionally doing a hot-ish backup.

Decision: If safe, run wsl --shutdown and retry. If you can’t, at least stop chatty services in the distro (databases, package managers, build loops).

Second: is the destination storage slow or flaky?

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

Meaning: You tried a nonsense copy (on purpose) and Robocopy complained immediately. That’s good: the tool is responsive. Now do a real local copy test with a large file if you suspect disk issues.

Decision: If copies to the same disk are slow, your bottleneck is local storage. If only network copies are slow, it’s network or server-side throttling.

Third: is the tar creation CPU-bound (compression) or I/O-bound (writes)?

WSL’s --export typically writes a tar without you choosing compression. The heavy cost is reading lots of small files and metadata, and writing a big sequential file. That’s usually I/O-bound, but antivirus scanning and endpoint protection can make it feel CPU-bound due to hooks.

Decision: If you suspect endpoint protection interference, test exporting to a directory excluded from real-time scanning (per policy). If you can’t exclude, export to a local fast disk first, then move.

Fourth: is the distro huge because of container layers or build artifacts?

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	/

Meaning: Massive /var is often container storage (/var/lib/docker) or package caches.

Decision: Decide whether you want to back up that state. If you rely on it for fast local iteration, keep it. If it’s just cached layers, clean it before export and accept longer rebuild later.

Fifth: is import failing due to permissions or path issues?

Imports to protected locations (like inside C:\Program Files) often fail or behave strangely due to ACLs.

Decision: Import under a user-writable path on a data drive you control (like D:\WSL\...), and keep it consistent across machines.

Common mistakes: symptoms → root cause → fix

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

Root cause: You exported the wrong distro name (or exported a clean “base” distro you never used). This happens a lot when people have Ubuntu plus “Ubuntu Preview” plus a test distro.

Fix: List distros with wsl --list --verbose. Verify inside each distro which one contains your home directory data (ls -la /home). Export the correct one.

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

Root cause: Destination path permissions, antivirus blocking, or the external drive is formatted with a filesystem/policy that denies large files.

Fix: Export to a local folder under your profile (e.g., C:\Users\...\Backups), verify size, then move it with Robocopy. Also ensure the destination supports large files and isn’t read-only.

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

Root cause: Large numbers of small files (node_modules, build trees), endpoint scanning, or slow destination storage.

Fix: Prune rebuildable directories before export, or maintain a separate “data-only” backup for projects while using export less frequently. If policy allows, export to a scanning-excluded location and then copy.

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

Root cause: Default user not set for the imported distro, or user metadata mismatch after restore.

Fix: Launch and set your user explicitly. If needed, adjust WSL config for that distro and ensure the user exists. Validate with id and getent passwd.

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

Root cause: You copied the VHDX while WSL was running, capturing an inconsistent disk state.

Fix: Stop WSL (wsl --shutdown) before copying. Prefer export/import for disaster recovery. If you already have the bad copy, try filesystem repair inside WSL (may or may not help), and fall back to tar export if available.

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

Root cause: WSL distros often live under the user profile’s app data directories. A new profile means a new location, and the old one may be orphaned.

Fix: Use export/import going forward. If you must recover, locate the old profile directory and its WSL package data, then export from that installation if possible.

7) Symptom: Backup is huge even after cleanup

Root cause: Container data, language tool caches, or large artifacts under /home (VM images, datasets, build outputs).

Fix: Identify top consumers with du. Decide what’s rebuildable. If you need datasets, back them up separately from WSL export and mount them into WSL from Windows for better lifecycle management.

Three corporate mini-stories from the land of “works on my machine”

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

The team had a standard onboarding doc: install WSL, clone repos, run builds. A new hire followed it, tweaked a few dotfiles, and got productive fast. Weeks later, their laptop got a routine corporate reimage because a different tool needed a cleaner Windows baseline. No one was worried—everything important was “in Git.”

Except it wasn’t. The developer had generated SSH keys, stored a couple of internal CA certs in the distro, and had a local-only config for a staging environment that never should have existed outside the laptop, but did. Those weren’t in Git for good reasons. They were in WSL because it felt like “Linux land.”

After the reimage, WSL came back empty. The repos were easy. The keys weren’t. Access requests went into queues. Builds blocked. On-call got pinged because a CI pipeline started failing: someone had “temporarily” used the dev machine as an ad hoc signer for a test artifact. Now that machine’s identity was gone.

The wrong assumption wasn’t “Git has everything.” It was “WSL is ephemeral.” The fix was boring: scheduled WSL exports to an encrypted corporate location, plus a short list of what must never live only inside a distro. The postmortem note was even more boring: “treat dev environments as systems with state.” That line should be printed on a sticker and slapped on every laptop.

Mini-story 2: The optimization that backfired

Another org tried to speed up backups by copying VHDX files directly. Their reasoning was sound on paper: copying a single large file is faster than archiving millions of tiny files. They set up a script that copied the distro VHDX to a network share every night.

It worked until it didn’t. A few engineers started running container workloads inside WSL2. Lots of writes. High churn. The VHDX copy job sometimes overlapped with heavy disk activity. No one noticed because “the file copied successfully.” Successful copy is not the same as consistent snapshot.

Weeks later, a developer needed to restore a distro after a disk failure. They dropped in the copied VHDX and booted. It launched, then started throwing filesystem errors under load. The restore was worse than a clean rebuild because it failed in subtle ways: random toolchain issues, missing files that should have existed, package database problems. Debugging ate days.

They rolled back to the previous night’s VHDX. Same story. Eventually they found an older tar export someone had taken manually for a migration. That restored cleanly.

The “optimization” failed because they optimized the wrong metric: backup speed, not restore correctness. They kept VHDX copies for convenience later, but only when WSL was shut down and only as a secondary tier. Export/import became the DR source of truth.

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

A security-minded platform team had a simple rule for developers using WSL: weekly export, monthly restore test. Not because they were paranoid. Because they’d been burned before, and they didn’t enjoy repeating themselves.

They provided a small script: list distros, shut down WSL, export each to a date-stamped tar, hash it, then copy to a protected share. The script also kept a little manifest file with hashes. The restore test was intentionally manual: import the tar as a new distro name, boot it, verify a few known paths and commands, then delete the test distro.

One day, a Windows update collided with a storage driver issue on a subset of laptops. A few dev machines came back with WSL distros that wouldn’t start. It wasn’t global, but it was enough to cause real disruption.

The teams with the boring practice were back in business the same morning. They imported last week’s tar, lost at most a few days of local-only state, and moved on. Everyone else filed tickets, waited, and learned the hard way that “I’ll deal with backups later” is just a way to pre-schedule pain.

Checklists / step-by-step plan

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

1. Inventory distros: identify which ones matter (dev, data science, ops tooling).
2. Pick backup destinations: local fast disk for staging; encrypted external or protected share for retention.
3. Decide retention: daily/weekly/monthly, based on how much local-only state exists.
4. Decide secrets policy: if exports include secrets, require encryption and restricted ACLs.
5. Create a restore test habit: monthly import under a new name and verify core workflows.

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

1. List distros: wsl --list --verbose
2. Stop WSL: wsl --shutdown
3. Export each critical distro to local staging (fast disk)
4. Hash each tar (SHA-256) and store the hash text separately
5. Copy to long-term destination using a retry-capable tool
6. Re-hash at destination and compare
7. Optionally: import one tar as a test distro and run basic verification

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

1. Install/update WSL platform (match modern version)
2. Create an import location on a stable data drive (e.g., D:\WSL\...)
3. Import tar under a new distro name first (don’t overwrite blindly)
4. Launch, verify user/home, verify SSH, verify repos
5. Switch default distro once you’re confident
6. Only then delete broken/old distro registrations

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

If your WSL distro holds large datasets or giant repos, consider splitting:

• Keep the distro small: tools, configs, minimal state.
• Store projects under Windows filesystem in a controlled location, mounted into WSL (trade-offs apply).
• Back up projects with your normal workstation backup tooling, independently of WSL exports.

This reduces the blast radius when WSL breaks. It also makes exports smaller and restores faster. It’s not free—cross-filesystem performance and permissions can be annoying—but it’s often the right trade in corporate environments.

FAQ

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

Default to wsl --export for disaster recovery portability. Use VHDX copies only when you can reliably shut down WSL first and you want fast “exact state” restores.

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

You should, unless you accept risk. Exporting a running distro can capture inconsistent state. Quiet systems often survive it. Busy ones eventually punish you.

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

Typically under your user profile’s local app data, inside a package directory for store-installed distros. If you import to a custom location, the VHDX will live where you told it to live. That’s why importing to D:\WSL\... is a good idea.

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

Yes. That’s the point. Import the tar to a new distro name and location, then validate it boots and your data is there.

5) Why is my export tar file enormous?

Because your distro is enormous. Common culprits: /var/lib/docker, language caches, build artifacts, and logs. Identify with du, then decide whether to keep or prune rebuildable content.

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

Confirm the user exists in the distro, then set your preferred default user for that distro (method depends on your launcher/config). As a quick check, launch and run id; if you’re root unexpectedly, fix before doing real work.

7) Can I automate WSL backups?

Yes. Schedule a Windows task that runs: list distros, shutdown WSL, export to a staging path, hash, then copy with retries. Automation is good. Automation without verification is just faster disappointment.

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

Import it under a new name and test it. At minimum: boot, verify your home directory, verify a repo, verify SSH. That’s your restore drill.

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

Sometimes. Compression can save space but costs CPU and time, and it adds another layer that can fail. If storage is cheap, keep it simple. If storage is constrained, compress and be disciplined about hashing and restore tests.

10) What about backing up only /home?

That’s a valid strategy if you can rebuild the rest quickly and consistently (dotfiles, packages, toolchains via scripts). It’s faster and smaller. The risk is you’ll forget “one weird thing” that lived in /etc or /usr/local.

Conclusion: next steps you can do today

Do three things and you’ll be ahead of most teams:

1. Run one clean export today: shut down WSL, export your primary distro, hash it, and store the hash separately.
2. Prove you can restore: import the tar under a new name and verify your home directory and key workflows.
3. Make it routine: schedule weekly exports and a monthly restore test. Keep the process boring, repeatable, and documented.

WSL is reliable enough to lull you into forgetting it has state. Your job is to remember—before Windows “helpfully” remembers for you.