Резервне копіювання дистрибуцій WSL: експортуйте та імпортуйте правильно

Що ви насправді резервуєте (і чому це важливо)

Дистрибуції WSL — це не якісь чарівні папки з милими пінгвінами. Під капотом це файлові системи Linux, що живуть всередині віртуального диска. Для WSL2 це зазвичай файл .vhdx, що зберігається в профілі Windows. WSL1 інший: він зберігає файли більш «безпосередньо» у структурі файлової системи Windows, і ви побачите зовсім іншу продуктивність та поведінку при бекапі.

Коли люди втрачають середовище WSL, рідко це через якусь екзотику Linux. Зазвичай Windows робить щось звичне: скидає профіль, змінює літеру диска, застосовує політику роумінгу профілів, антивірус поміщає в карантин, працює «Storage Sense» або робиться «перевстановлення — все буде добре».

Існують три підходи до резервного копіювання, про які ви почуєте:

1. WSL export/import (tar): канонічно і портативно, але треба розуміти, що воно охоплює, а що ні.
2. Копіювання VHDX: швидко й повно (включно з кешами та всілякими артефактами), але більш крихке між версіями і ризикує корупцією, якщо копіювати, поки диск підключений і змінюється.
3. Бекап зсередини Linux (rsync тощо): добре для вибіркових даних, але не дає повного образу дистрою, якщо ви не дієте дуже виважено.

Моя однозначна порада: використовуйте export/import як стандартний план відновлення після катастроф, і за потреби тримайте знімки VHDX як «швидке відновлення», якщо ви контролюєте хост і час. Export/import — це нудний, сумісний шлях. Нудний — хороший. Нудний відновлює о 2-й ночі.

І ще: резервна копія, яку ніколи не відновлювали, — це не резервна копія. Це файл, що вас заспокоює.

Цікаві факти та коротка історія (те, що впливає на рішення)

• WSL1 і WSL2 — принципово різні: WSL1 транслює виклики ядра Linux; WSL2 запускає справжнє ядро Linux у легкій віртуальній машині. Саме тому WSL2 загалом сумісніший, але зберігає дані у VHDX.
• WSL2 використовує формат віртуального диска з Hyper-V: VHDX підтримує більші диски й функції стійкості в порівнянні з старішим VHD. Це добре для зростання, але нагадує: ставтеся до нього як до диска VM.
• Продуктивність файлової системи в WSL змінила розмову про бекапи: на ранньому етапі для WSL1 часто використовували доступ з боку Windows; WSL2 зробив операції в Linux швидшими всередині віртуального диска, але доступ Windows до \\wsl$ може бути повільнішим і складнішим для консистентного бекапу.
• Ера «store apps» має значення: дистрибуції WSL часто надходять із Microsoft Store, тому оновлення та процес перевстановлення схожі на поведінку додатків, а не на «традиційну Linux-інсталяцію». Добре — поки корпоративний менеджмент образів не вирішує за вас.
• systemd у WSL з’явився пізніше: старі припущення про те, що служби не працюють під час бекапу, можуть бути неправильними тепер. Якщо systemd увімкнений, у вас може бути більше фонових станів, які варто зупинити перед створенням знімка.
• Формат експорту еволюціонував: WSL export традиційно давав tar-архів. Нові інструменти WSL додали опції, що впливають на те, чи експортується rootfs дистрою або щось ближче до повного знімка. Знайте, що підтримує ваша версія.
• Користувачі помилково змінюють уявлення про місце зберігання: люди думають «це в моєму Linux-домі». Насправді зазвичай у %LOCALAPPDATA% під папкою пакета. Це приємний сюрприз для бекапів і відповідності.
• Модель мережі WSL змінювалася: NAT у WSL2 та інші режими впливають на те, які секрети/конфіги важливі (проксі, сертифікати, SSH-конфіги). Бекапи, що відновлюють файли, але не мережеві очікування, усе одно провалюються.

Розумний стандарт: export/import, а не надія

Export/import — вбудований механізм міграції WSL. Це не гламурно. Це також те, що найімовірніше спрацює після перевстановлення Windows, зміни дисків або переносu на новий ноутбук.

Що export/import робить добре

• Створює архів дистрибуції, який можна зберігати будь-де (зовнішній диск, мережевий шар, зашифрований сейф).
• Відновлює на іншому Windows без прив’язки до того, де зберігався оригінальний VHDX.
• Дозволяє імпортувати в конкретне місце (наприклад, D:\WSL\Ubuntu), щоб розділяти ОС та дані розробки.

Що export/import не вирішує сам по собі

• Гігієна секретів: якщо у дистрибуції є ключі/токени, експорт експортує й секрети. Вирішіть, чи повинен архів бути зашифрованим у спокої.
• Консистентність відкритих файлів: експорт під час активного запису може зафіксувати стан, який «переважно нормальний», аж поки не виявиться інакше.
• Питання сумісності між версіями: імпорт старого архіву в значно новішу версію WSL може потребувати оновлення пакетів.

Правило: перед експортом зупиніть дистрою або хоча б завершіть роботу WSL, щоб файлову систему було заспокоєно. Це тема, що зустрічатиметься часто — різниця між «я зробив бекап» і «я зробив бекап рухомої цілі».

Жарт №1: Резервувати працюючу систему без її заглушення — як фотографувати колібрі картофелем: технічно можливо, але емоційно дорого.

Практичні завдання (команди, виводи та рішення)

Це реальні операційні кроки. Кожен включає: команду, приклад виводу, що вивід означає, і наступне рішення. Виконуйте їх у PowerShell або CMD, де це доречно; керування WSL — це панель керування з боку Windows.

Завдання 1: Перелічити встановлені дистрибуції та побачити, що запущено

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

Значення: У вас три дистрибуції. Ubuntu-22.04 запущена, отже її диск активно змонтований і може змінюватися.

Рішення: Якщо робите повний експорт, плануйте спочатку зупинити її (або прийміть ризик для некритичних даних).

Завдання 2: Чисто зупинити WSL (заспокоїти все)

cr0x@server:~$ wsl --shutdown

Значення: VM WSL і дистрибуції завершені. Відсутність виводу — це нормально.

Рішення: Продовжуйте з експортом або копіюванням VHDX з набагато нижчим ризиком неконсистентного стану.

Завдання 3: Експортувати дистрибуцію в tar-архів (портативний бекап)

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

Значення: Тепер у вас є tar-архів, який можна імпортувати в іншому місці.

Рішення: Негайно перевірте розмір файлу та хеш; не довіряйте лише наявності файлу.

Завдання 4: Перевірити розмір і мітку часу бекапу (дешевий саніті-чек)

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

Значення: Експорт створив приблизно 12.8 ГБ tar. Якщо ваша дистрибуція велика, а tar крихітний, щось не так (або вона майже порожня).

Рішення: Якщо розмір підозріло малий, перезапустіть експорт після перевірки правильності імені дистрибуції та доступу WSL до диска призначення.

Завдання 5: Хешувати tar, щоб виявити корупцію (і використовувати для дедупації)

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.

Значення: У вас є контрольний відбиток цілісності, який можна зберегти поруч із бекапом.

Рішення: Якщо файл йде за межі машини (NAS/хмара), зберігайте хеш окремо й перевіряйте після передачі.

Завдання 6: Переконатися, що tar читається (базова перевірка архіву)

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

Значення: Tar читається і містить очікувані шляхи.

Рішення: Якщо tar -tf видає помилки (unexpected EOF, checksum errors), відкиньте бекап і експортуйте знову — бажано після wsl --shutdown і на інший диск.

Завдання 7: Дізнатися, де фактично живе дистрибуція (щоб знати, що ви переміщаєте)

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

Значення: Всередині WSL2 це виглядає як блочний пристрій. Це не показує шлях у Windows, але дає логічний розмір і використання.

Рішення: Якщо використання велике, очікуйте, що експорт займе час і створить великий tar. Розгляньте очищення кешів перед бекапом, якщо час важливий.

Завдання 8: Очистити очевидні «їдці місця» перед експортом (опціонально, але ефективно)

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

Значення: /var/cache і логи важкі; можливо, у вас старі пакети, шари контейнерів або лог-спамер.

Рішення: Якщо це робоча станція розробника і відтворювані кеші не потрібно зберігати, очистіть їх і експортуйте менший tar.

Завдання 9: Дійсно очистити apt-кеш і старі пакети (не вигадуйте)

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

Значення: Місце звільнено. Експорти будуть меншими і швидшими.

Рішення: Якщо дистро використовується для роботи з ядром/модулями або зафіксованих тулчейнів, не робіть autoremove бездумно; спочатку зробіть бекап, потім тримайте чистку. «Менший бекап» не вартий «зламаної збірки».

Завдання 10: Експортувати після очищення (і знову перевірити)

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

Значення: У вас новий архів. Очікуйте, що він стане меншим, якщо очищення дало результат.

Рішення: Зберігайте принаймні один «неочищений» періодичний бекап, якщо боїтеся випадково видалити щось потрібне (наприклад локальний артефакт, який ви не запушили).

Завдання 11: Імпортувати в конкретне місце (міграція або відновлення)

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

Значення: Створено нову дистрибуцію з іменем Ubuntu-22.04-Restored у вказаному місці.

Рішення: Робіть це для тестування відновлень. Не перезаписуйте робочу дистрибуцію, поки перевірка відновленої не підтвердить працездатність і наявність даних.

Завдання 12: Перевірити, що відновлена дистрибуція завантажується і має очікуваних користувачів/файли

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

Значення: За замовчуванням користувач і домашні файли присутні. Це базова перевірка «воно живе».

Рішення: Далі перевірте конкретні речі, що для вас важливі: репозиторії, SSH-ключі, dotfiles, тулчейни збірки і стан сервісів, від яких ви залежите.

Завдання 13: Встановити дистрибуцію за замовчуванням (після того, як упевнилися)

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

Значення: Виконання wsl без аргументів тепер запускатиме відновлену дистрибуцію.

Рішення: Робіть це тільки після того, як відновлення довело свою працездатність протягом дня реальної роботи.

Завдання 14: Перевірити версію WSL і статус (для налагодження проблем import/export)

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

Значення: Це показує платформу WSL, на якій ви працюєте. Різниця в версіях — реальна причина сюрпризів при відновленні.

Рішення: Якщо відновлюєте зі значно старішої машини, оновіть WSL спочатку, щоб поведінка імпорту відповідала очікуванням.

Завдання 15: Експорт на мережевий шлях (і вирішіть, чи варто так робити)

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

Значення: Пише напряму на UNC-путь. Це зручно, але може бути повільніше й чутливіше до обривів Wi‑Fi.

Рішення: Для надійності: експортуйте локально, хешуйте, потім копіюйте на мережу інструментом з повторними спробами (і перевіряйте хеш після копіювання).

Завдання 16: Копіювання з перевіркою (надійна передача)

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

Значення: Копіювання успішне, показує швидкість і поведінку повторних спроб. Якщо бачите FAILED > 0, у вас на сервері немає бекапу — у вас є історія.

Рішення: Повторно зхешуйте файл у призначенні та порівняйте з хешем джерела. Якщо різниця, рекопіюйте або розбирайтеся з нестабільним сховищем/мережею.

Дизайн бекапу: як виглядає «добре» для WSL

Визначте, що ви захищаєте

Більшість дистрибуцій WSL містить суміш:

• Незамінного: ключі, сертифікати, локальні конфіги, незапушені коміти, нотатки, скрипти.
• Відновлюваного: встановлені пакети, мовні тулчейни, образи контейнерів, результати збірки.
• Активно зайвого: кеші, що роздувають бекапи й додають час відновлення без користі.

Стратегія бекапу має це відображати. Мета не зберегти кожен байт. Мета — зберегти байти, які ви пошкодуєте, якщо машина згорить, а календар не співчуває.

Export/import vs копія VHDX: обирайте свідомо

Export/import (tar) — ваш шлях портативності. Це те, що робити, коли хост може змінитися: новий ноутбук, перевстановлення ОС, корпоративне реімеджування, переміщення між дисками або коли хочете чисте «перебудування», що не тягне зайвий прихований стан.

Копія VHDX — швидкий «lift and shift» знімок. Може відновити точний стан, але чутливий до консистентності та до того, як ви його копіюєте.

Якщо наполягаєте на копіюванні VHDX: спочатку зупиніть WSL. Копіювати під час роботи WSL — означає ставити все на випадок вимірювання часу. Час — не стратегія.

Шифрування й контроль доступу: ваш tar — це мішок із секретами

Експортовані tar-файли часто включають:

• ~/.ssh
• ~/.gnupg
• креденшіали хмарних CLI і токени
• ~/.kube/config та сертифікати кластерів
• секрети в .env, про які ви забули

Це означає, що місце зберігання бекапу має значення. Якщо це спільний диск — ваша модель загроз змінилася. Якщо це особистий SSD — зашифруйте його. Якщо це корпоративне сховище — переконайтеся в коректних ACL та аудиті.

Збереження: тримайте менше бекапів, але довіряйте їм

Для робочих станцій розробника практичний шаблон збереження:

• Щоденний експорт на 7 днів
• Щотижневий експорт на 4–8 тижнів
• Щомісячний експорт на 6–12 місяців (якщо потрібна відповідність або довготривалі дослідження)

Більше зазвичай псується, бо ніхто не перевіряє відновлення. Тримайте менше — перевіряйте — спіть краще.

Цитата, що має значення

Надія — це не стратегія. — перефразована ідея, поширена в колах надійності/операцій (без прив’язки до одного джерела).

Жарт №2: Якщо ваш план бекапу — «я згадаю експортувати перед перевстановленням», вітаю — ви придумали нагадування в календарі, яке вас ненавидить.

План швидкої діагностики (швидко знайти вузьке місце)

Експорти іноді тягнуться вічність, імпорти іноді «виснуть», а копіювання іноді повзе. Не гадіть. Тріажуйте.

Перше: WSL ще працює чи завис?

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

Якщо Running: експорт може працювати, але ви експортуєте живу систему. Спочатку зупиніть її, якщо не робите «гарячий» бекап цілеспрямовано.

Рішення: Якщо безпечно, виконайте wsl --shutdown і повторіть спробу. Якщо не можете — хоча б зупиніть галасливі служби в дистрої (бази даних, пакетні менеджери, цикли збірки).

Друге: чи повільне або ненадійне сховище призначення?

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

Значення: Ви навмисно запустили невдалу копію, і Robocopy відреагував миттєво. Це добре: інструмент відповідає. Тепер зробіть реальний локальний тест копіювання великого файлу, якщо підозрюєте проблеми з диском.

Рішення: Якщо локальні копії на тому ж диску повільні — вузьке місце в локальному сховищі. Якщо повільні тільки мережеві копії — проблема в мережі або серверному обмеженні.

Третє: створення tar пов’язане з CPU (стисканням) чи I/O (записом)?

--export зазвичай записує tar без вибору стиснення. Основні витрати — читання багатьох дрібних файлів і метаданих, та запис великого послідовного файлу. Зазвичай це I/O-bound, але антивірус і захист кінцевої точки можуть створити відчуття CPU-bound через хуки.

Рішення: Якщо підозрюєте взаємодію з endpoint protection, протестуйте експорт у директорію, виключену з реального часу сканування (за політикою). Якщо не можете виключити — експортуйте на локальний швидкий диск, потім перемістіть.

Четверте: чи дистро величезне через шари контейнерів або артефакти збірки?

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	/

Значення: Величезний /var часто означає сховище контейнерів (/var/lib/docker) або кеші пакетів.

Рішення: Вирішіть, чи варто бекапити цей стан. Якщо потрібен для швидкої локальної ітерації — зберігайте. Якщо це лише кеші — очистіть перед експортом і прийміть довший час відтворення пізніше.

П’яте: імпорт падає через права чи шляхи?

Імпорт у захищені місця (наприклад, C:\Program Files) часто не вдається або поводиться дивно через ACL.

Рішення: Імпортуйте в шлях, доступний для запису користувачу, на стабільному диску даних (наприклад, D:\WSL\...), і дотримуйтеся консистентності між машинами.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: файл експорту є, але відновлення не містить вашого користувача/домашнього каталогу

Корінь: Ви експортували не ту дистрибуцію (або експортували чисту «базову» дистрибуцію, якою не користувалися). Це часто трапляється, коли є Ubuntu, «Ubuntu Preview» і тестова дистроя одночасно.

Виправлення: Перелічіть дистрибуції через wsl --list --verbose. Перевірте в кожній дистрої, де саме ваш домашній каталог (ls -la /home). Експортуйте правильну.

2) Симптом: експорт не вдається з Access Denied або створює 0-байт tar

Корінь: Права шляху призначення, антивірус блокує або зовнішній диск відформатований у файловій системі/політиці, що не дозволяє великі файли.

Виправлення: Експортуйте у локальну папку під профілем (наприклад, C:\Users\...\Backups), перевірте розмір, потім перемістіть Robocopy. Також переконайтеся, що призначення підтримує великі файли і не є лише для читання.

3) Симптом: експорт триває годинами і машина повільна

Корінь: Велика кількість дрібних файлів (node_modules, дерева збірки), сканування в реальному часі кінцевою точкою або повільне сховище призначення.

Виправлення: Обріжте відтворювані директорії перед експортом або ведіть окремий «лише дані» бекап для проєктів, а export використовуйте рідше. Якщо політика дозволяє — експортуйте у виключену від сканування локацію, а потім копіюйте.

4) Симптом: імпорт вдався, але запуск дистрибуції не вдається або ви потрапляєте в root

Корінь: Користувач за замовчуванням не встановлений для імпортованої дистрибуції або метадані користувача після відновлення не збігаються.

Виправлення: Запустіть дистрибуцію і встановіть бажаного користувача явно. Якщо потрібно, налаштуйте конфігурацію WSL для цієї дистрибуції і переконайтеся, що користувач існує. Перевірте id і getent passwd.

5) Симптом: копія VHDX «відновлюється», але пізніше з’являються помилки файлової системи

Корінь: Ви копіювали VHDX, поки WSL працював, захопивши неконсистентний стан диска.

Виправлення: Зупиніть WSL (wsl --shutdown) перед копіюванням. Для DR віддавайте перевагу export/import. Якщо у вас вже є погана копія, спробуйте відновлення файлової системи всередині WSL (може допомогти або ні) і як запасний варіант використайте tar-export, якщо він доступний.

6) Симптом: не можете знайти файли дистрибуції після зміни профілю Windows

Корінь: Дистрибуції WSL часто живуть у папках AppData локального профілю. Новий профіль — нове розташування, старе може залишитися сиротою.

Виправлення: Надалі використовуйте export/import. Якщо потрібно відновити, знайдіть стару папку профілю та її дані пакета WSL, потім експортуйте з тієї установки, якщо можливо.

7) Симптом: бекап величезний навіть після очищення

Корінь: Данні контейнерів, кеші мовних тулчейнів або великі артефакти у /home (образи VM, набори даних, результати збірки).

Виправлення: Знайдіть основні споживачі за допомогою du. Визначте, що відновлюване. Якщо потрібні датасети — бекапте їх окремо від export WSL і монтуйте в WSL з боку Windows для кращого життєвого циклу.

Три корпоративні історії з краю «в мене працює»

Історія 1: Інцидент через хибне припущення

Команда мала стандартну інструкцію для onboarding: встановити WSL, клонувати репозиторії, запускати збірки. Новий співробітник швидко став продуктивним. Через кілька тижнів його ноутбук отримав планове корпоративне реімеджування, бо інший інструмент вимагав чистішу Windows-базу. Ніхто не хвилювався — «все важливе в Git».

Але не все було в Git. Розробник згенерував SSH-ключі, зберіг кілька внутрішніх CA-сертифікатів у дистрої і мав локальний конфіг для стейджинг-середовища, який ніколи не мав виходити за межі ноутбука, але вийшов. Цього не було в Git з вагомих причин — воно просто жило в WSL, бо «так зручно».

Після реімеджу WSL повернувся порожнім. Репозиторії — легко. Ключі — ні. Заявки на доступ пішли в черги. Збірки зупинилися. On-call отримав повідомлення, бо CI почав падати: хтось «тимчасово» використовував девмашину як підписувач тестового артефакту. Тепер ідентичність тієї машини пропала.

Хибне припущення не було «Git має все». Воно було «WSL — ефермерний». Вирішення було нудним: заплановані експорти WSL у зашифроване корпоративне сховище й короткий список речей, які ніколи не повинні жити лише в дистрої. Постмортемна нотатка була ще менш гламурною: «ставтеся до девсередовищ як до систем зі станом». Наклейте цю фразу на кожен ноутбук.

Історія 2: Оптимізація, що відклалася боком

Інша організація намагалася пришвидшити бекапи, копіюючи VHDX напряму. Ідея на папері була зрозуміла: копіювання одного великого файлу швидше, ніж архівування мільйонів дрібних файлів. Вони налаштували скрипт, що щовечора копіював VHDX на мережевий шар.

Працювало — поки не перестало. Декілька інженерів почали запускати контейнерні навантаження у WSL2. Багато записів. Високий churn. Робота копіювання VHDX іноді перекривалася з важкою дисковою активністю. Ніхто не помічав, бо «файл скопійовано успішно». Успішне копіювання — не те саме, що консистентний знімок.

Через кілька тижнів розробнику знадобилося відновити дистрою після збою диска. Вони підсунули скопійований VHDX і завантажили. Він запустився, але під навантаженням почав викидати помилки файлової системи. Відновлення було гірше за чисту перебудову: випадкові проблеми з тулчейнами, відсутні файли, проблеми з базою пакетів. Налагодження зайняло дні.

Вони відкотилися до попереднього нічного VHDX. Та сама історія. Нарешті знайшли старий tar-експорт, який хтось робив вручну для міграції. Він відновився чисто.

«Оптимізація» програла, бо оптимізували неправильний критерій: швидкість бекапу, а не коректність відновлення. Тепер вони тримають VHDX-копії як зручність, але лише коли WSL зупинено і як вторинний шар. Export/import став джерелом істини для DR.

Історія 3: Нудна, але правильна практика, що врятувала

Команда платформи з акцентом на безпеку мала просте правило для розробників з WSL: щотижневий експорт, щомісячний тест відновлення. Не через параною — вони вже горіли раніше й не хотіли повторювати.

Вони надали скрипт: перелічити дистрибуції, зупинити WSL, експортувати кожну з позначкою дати, зхешувати, потім скопіювати в захищений шар. Скрипт зберігав міні-маніфест з хешами. Тест відновлення був навмисно ручним: імпортувати tar як нову дистрибуцію, завантажити, перевірити кілька шляхів і команд, потім видалити тест.

Одного дня оновлення Windows зіткнулося з проблемою драйвера сховища на частині ноутбуків. Декілька девмашин повернулися з дистроями, що не стартували. Це не був глобальний інцидент, але достатній, щоб спричинити реальні проблеми.

Команди з нудною практикою повернулися в роботу того ж ранку. Вони імпортували тижневий tar, втратили максимум кілька днів локального стану і продовжили. Решта подавали заявки, чекали і вчилися болісно, що «я розберусь із бекапами потім» — це просто заздалегідь запланований біль.

Контрольні списки / покроковий план

Контрольний список A: Одноразове налаштування для надійного бекапу WSL

1. Інвентаризація дистрибуцій: визначте, які важливі (dev, data science, ops-утиліти).
2. Виберіть місця зберігання: локальний швидкий диск для стагінгу; зашифрований зовнішній чи захищений шар для збереження.
3. Визначте політику збереження: щоденно/щотижнево/щомісяця залежно від локального стану.
4. Визначте політику секретів: якщо експорти містять секрети, вимагається шифрування і обмежені ACL.
5. Створіть звичку тестувати відновлення: щомісячний імпорт під новим іменем і перевірка ключових робочих процесів.

Контрольний список B: Щотижневі кроки «зробити бекап» (операторський рівень)

1. Перелічити дистрибуції: wsl --list --verbose
2. Зупинити WSL: wsl --shutdown
3. Експортувати кожну критичну дистрибуцію у локальний стагінг (швидкий диск)
4. Хешувати кожен tar (SHA-256) і зберегти хеш окремо
5. Копіювати в довгострокове сховище інструментом із повторними спробами
6. Повторно зхешувати у призначенні і порівняти
7. Опційно: імпортувати один tar як тестову дистрибуцію і виконати базову перевірку

Контрольний список C: Відновлення після катастрофи (реімедж, новий ноутбук, втрата диска)

1. Встановити/оновити платформу WSL (підтримуйте сучасну версію)
2. Створити місце імпорту на стабільному диску даних (наприклад, D:\WSL\...)
3. Імпортувати tar під новою назвою спочатку (не перезаписуйте бездумно)
4. Запустити, перевірити користувача/домашній каталог, перевірити SSH, перевірити репозиторії
5. Поставити дистро за замовчуванням лише після впевненості
6. Лише після цього видаляти зламані/старі реєстрації дистрибуцій

Контрольний список D: Опціональний план розділення даних (мій улюблений варіант)

Якщо у вашому дистро є великі набори даних або гігантські репозиторії, розгляньте розділення:

• Тримайте дистро маленькою: інструменти, конфіги, мінімальний стан.
• Зберігайте проєкти в Windows-файловій системі у контрольованому місці і монтуйте в WSL (є компроміси).
• Бекапте проєкти звичним інструментом робочої станції, окремо від експорту WSL.

Це зменшує вибухову зону при збої WSL. Також робить експорт меншим і відновлення швидшим. Це не безкоштовно — продуктивність міжфайлової системи і права можуть дратувати — але часто це вірний компроміс у корпоративному середовищі.

Питання й відповіді

1) Чи краще бекапити через wsl --export чи копіювати VHDX?

За замовчуванням обирайте wsl --export для портативності відновлення. Копії VHDX використовуйте лише коли впевнені, що можете надійно зупинити WSL і хочете швидко відновити точний стан.

2) Чи треба виконувати wsl --shutdown перед експортом?

Рекомендується, якщо ви не приймаєте ризик. Експорт працюючої дистрибуції може зафіксувати неконсистентний стан. Тихі системи зазвичай переживають такий експорт. Завантажені — карають вас згодом.

3) Де зберігаються файли моїх дистрибуцій у Windows?

Зазвичай під вашим профілем у локальному AppData, всередині папки пакета для дистро, встановлених із магазину. Якщо ви імпортували в кастомне місце — VHDX житиме там, куди ви вказали. Тому імпорт у D:\WSL\... — добра ідея.

4) Чи можу відновити tar-експорт на іншій Windows-машині?

Так. Саме для цього. Імпортуйте tar під новою назвою і місцем, потім переконайтеся, що воно завантажується і дані на місці.

5) Чому мій tar-архів експорту величезний?

Бо дистро велике. Звичайні винуватці: /var/lib/docker, кеші мов, артефакти збірки та логи. Знайдіть через du, потім вирішіть, що обрізати.

6) Імпорт спрацював, але мій користувач за замовчуванням — не той. Як виправити?

Переконайтеся, що користувач існує у дистро, потім встановіть бажаного користувача за замовчуванням (метод залежить від вашого лаунчера/конфігу). Швидка перевірка: запустіть і виконайте id; якщо ви root несподівано — виправте перед роботою.

7) Чи можна автоматизувати бекапи WSL?

Можна. Заплануйте завдання Windows, яке виконує: перелік дистро, shutdown WSL, експорт у стагінг, хеш, потім копію з повторними спробами. Автоматизація — добре. Автоматизація без перевірок — просто швидше розчарування.

8) Як дізнатися, що мій бекап справді відновлюваний?

Імпортуйте під новим іменем і протестуйте. Мінімум: завантаження, перевірка домашнього каталогу, перевірка репозиторію, перевірка SSH. Це ваш тренування з відновлення.

9) Чи варто додатково стискати tar (zip, 7z)?

Іноді. Стиснення економить місце, але коштує CPU і часу, додає ще один шар, який може зламатися. Якщо сховище дешеве — тримайте просто. Якщо місця мало — стискайте і дисципліновано хешуйте та тестуйте відновлення.

10) А як щодо бекапу тільки /home?

Це життєздатна стратегія, якщо ви швидко і послідовно відтворюєте решту (dotfiles, пакети, тулчейни через скрипти). Це швидше і компактніше. Ризик — забути «одну дивну річ», що жила в /etc або /usr/local.

Висновок: наступні кроки, які можна зробити сьогодні

Зробіть три речі — і ви випередите більшість команд:

1. Зробіть один чистий експорт сьогодні: зупиніться WSL, експортуйте основну дистрибуцію, зхешуйте її і збережіть хеш окремо.
2. Доведіть, що можете відновити: імпортуйте tar під новою назвою і перевірте домашню теку та ключові робочі процеси.
3. Зробіть це рутиною: заплануйте щотижневі експорти і щомісячний тест відновлення. Тримайте процес нудним, відтворюваним і документованим.

WSL настільки надійний, що змушує забувати, що в нього є стан. Ваша задача — пам’ятати раніше, ніж Windows «допоможе» вам згадати.