Инкрементальный бэкап rsync: с Unix на Windows через WSL

Задача типовая для небольшой инфраструктуры: Linux-сервер надо бэкапить на машину с Windows, причём так, чтобы каждый день появлялся полный на вид снимок, а место росло только на объём изменений. Такой инкрементальный бэкап rsync делает через --link-dest: неизменённые файлы в новом снимке становятся жёсткими ссылками на файлы предыдущего. Сложность начинается на приёмнике: Windows не хранит Unix-права, а NTFS и Linux по-разному обходятся с ссылками. Ниже — рабочая схема «Linux → Windows через WSL», где приёмником служит отдельный диск с EXT4, плюс то, что в исходной версии этой статьи было ошибкой или умолчанием: ограничения wsl --mount, судьба CentOS 6 и обязательная проверка восстановления.

Материал переписан 13 ноября 2026 года: конфигурация и команды сохранены, факты о EOL и о монтировании дисков проверены по первоисточникам.

TL;DR: что это и как проверить за десять минут

1. Схема. Источник — Linux-сервер (например, CentOS), приёмник — Windows 11 с WSL2 и отдельным диском в EXT4. Копирование инициирует Windows (pull-модель).
2. Инкрементность. rsync -a --link-dest=<прошлый снимок>: изменившиеся файлы копируются, остальные — жёсткие ссылки. Каталог каждого дня выглядит полным.
3. Права и ссылки. Хранить снимки на EXT4: NTFS не хранит UID/GID, а без них восстановление системы теряет смысл.
4. Монтирование. Диск подключается wsl --mount с правами администратора; флешки и SD-карты не поддерживаются, диск загрузки Windows — тоже.
5. Проверка. Раз в месяц — восстановление файла и импорт дампа базы на тестовой машине; без этого бэкап считается непроверенным.

Быстрая проверка окружения (Windows-часть — в PowerShell, Linux-часть — в WSL):

wsl --status                                  # WSL установлен и работает
Get-CimInstance Win32_DiskDrive | Select-Object DeviceID,Model,Size

rsync --version | head -2
lsblk -f                                      # диск бэкапа виден и размечен
df -h /mnt/backup                             # точка монтирования существует

Ожидаемо: WSL отвечает версией, диск бэкапа виден отдельным устройством, /mnt/backup смонтирован. Если wsl --status отвечает ошибкой доступа — WSL не установлен, и это первое, что надо исправить.

Проблема, которую это решает

Бэкап «рядом с данными» не защищает от главного сценария: сервер потерян целиком — вместе с диском, на котором лежали копии. Второй сценарий — шифровальщик: если приёмник смонтирован на сервере постоянно, шифровальщик дойдёт и до копий. Отсюда два требования, которые и определяют архитектуру: копии должны быть на другой машине и инициатором должен быть приёмник — тогда у скомпрометированного сервера нет учётных данных к хранилищу.

Дальше начинается вторая проблема — совместимость. rsync сохраняет владельцев, права, символьные ссылки и время; Windows-файловая система этого не умеет. Копирование на общую папку SMB даёт потерю прав и нестабильность с жёсткими ссылками, а без ссылок инкрементальность превращается в «полная копия каждый день», и диск кончается за месяц. Поэтому в схеме ниже приёмник — не «папка на Windows», а Linux-диск, подключённый внутрь WSL: для rsync это обычная POSIX-файловая система, и --link-dest работает так же, как на сервере.

Третья проблема — тихая деградация. Бэкап, который «уже год работает», обычно не проверяли ни разу: снимки есть, а восстановить нечего. В схеме ниже проверка восстановления — не пожелание, а шаг регламента.

Полезно заранее посчитать арифметику хранения, иначе место кончится внезапно. Первый снимок занимает полный объём данных, каждый следующий — только изменения плюс накладные расходы на метаданные и новые inode. На сервере с 500 ГБ данных и 2 % дневных изменений полный снимок даст 500 ГБ, а каждый последующий — около 10 ГБ; тридцать снимков выйдут примерно в 800 ГБ вместо 15 ТБ при полном копировании. Если считать лень, есть надёжное правило: держать глубину хранения так, чтобы прогнозируемый рост за период хранения не превышал 60 % свободного места.

Что такое схема «rsync + —link-dest на Windows»

Три части: источник, транспорт и приёмник. Источник — Linux-сервер с rsync и SSH. Транспорт — SSH, по которому приёмник забирает данные. Приёмник — Windows-машина, внутри которой работает WSL с отдельным диском; на этом диске лежат каталоги-снимки и вспомогательные данные (дампы баз, архивы конфигов).

flowchart LR
  SRC["Linux-сервер: rsync + SSH"] --> NET["SSH-туннель"]
  NET --> WSL["WSL2 на Windows: rsync"]
  WSL --> SNAP[("Диск бэкапа: снимки по датам")]
  SNAP --> LAST["симлинк last"]
  WSL --> DB[("Дампы MySQL")]
  WSL --> CONF[("Архив конфигов")]
  LAST --> SNAP

Ключевая деталь — жёсткие ссылки. rsync сравнивает файл с тем, что лежит в каталоге --link-dest, и если файл не изменился (по размеру и времени, а с -c — по контрольной сумме), создаёт жёсткую ссылку вместо копии. Файл существует в двух каталогах под одним inode, место занимает один раз. Удаление старого снимка освобождает только те блоки, на которые больше нет ссылок.

Возможности

Снимки и экономия места

Передача и доступ

Данные, кроме файлов

Как это устроено внутри

Один запуск — это последовательность из шести шагов, и каждый может сломать весь бэкап, если его пропустить.

flowchart TD
  A["Старт скрипта"] --> B{"точка монтирования есть?"}
  B -- нет --> X["выход с ошибкой и уведомление"]
  B -- да --> C{"симлинк last есть?"}
  C -- нет --> D["полный снимок без link-dest"]
  C -- да --> E["rsync с --link-dest"]
  D --> F["обновить last на новый снимок"]
  E --> F
  F --> G["дампы баз и архив конфигов"]
  G --> H["журнал и уведомление"]
  H --> I["проверка восстановления по регламенту"]

1. Проверка точки монтирования. Скрипт убеждается, что /mnt/backup существует и это именно диск бэкапа, а не пустой каталог на системном разделе. Пропуск этой проверки — классическая причина «бэкап писался в /, диск забит, сервер встал».
2. Подготовка каталогов. Создаются backup.RSYNC, backup/mysql, backup/mysql.old, если их ещё нет.
3. Первый запуск. Если симлинка last нет, копирование идёт без --link-dest: первый снимок всегда полный. Это надо обрабатывать явно, иначе --link-dest на несуществующий путь даст ошибку.
4. Основное копирование. rsync -aR --delete --link-dest=... --exclude-from=... -e ssh host:/ "$CURRENT". Ключ -R сохраняет структуру путей от корня, поэтому в снимке появляется var/www/..., а не «всё в одну папку».
5. Обновление last. Старый симлинк удаляется, новый указывает на свежий снимок. Только после успешного rsync — иначе следующий запуск будет ссылаться на битый каталог.
6. Данные и отчёт. Дампы баз, архив конфигов, запись в журнал и уведомление. Отчёт обязателен: молчащий бэкап неотличим от сломанного.

Минимальная рабочая основа скрипта выглядит так (сокращённо, без ветки дампов):

#!/bin/bash
set -euo pipefail                       # любая ошибка останавливает скрипт

SRC="root@server.example.org"
MOUNT="/mnt/backup"
SNAP="$MOUNT/backup.RSYNC"
TODAY="$SNAP/$(date +%Y-%m-%d)"
LAST="$SNAP/last"

mountpoint -q "$MOUNT" || { echo "диск бэкапа не смонтирован"; exit 1; }
mkdir -p "$SNAP"

if [ -L "$LAST" ]; then
    rsync -aR --delete --numeric-ids --link-dest="$LAST" \
          --exclude-from=/etc/backup-exclude.txt -e ssh "$SRC:/" "$TODAY/"
else
    rsync -aR --delete --numeric-ids \
          --exclude-from=/etc/backup-exclude.txt -e ssh "$SRC:/" "$TODAY/"
fi

ln -sfn "$TODAY" "$LAST"
echo "ok: $(date -Is) $(du -sh "$TODAY" | cut -f1)" >> /var/log/backup.log

Файл исключений — обязательная часть, а не «настройка по вкусу»:

/proc/*
/sys/*
/dev/*
/run/*
/mnt/*
/media/*
/tmp/*
/var/cache/*
/var/lib/mysql/*

--numeric-ids здесь важен: без него rsync сопоставляет владельцев по именам, а на приёмнике таких пользователей может не быть — в снимке окажется чужой UID.

Замеры и цифры

Все числа сняты 13 ноября 2026 года и проверяемы: состояние дистрибутивов — через API endoflife.date, ограничения WSL — по документации Microsoft, поведение жёстких ссылок — локальным тестом на Windows 11 (сборка 10.0.26300).

Границы замера: скорость копирования, коэффициент дедупликации и размер снимков здесь не измерялись — для этого нужен реальный сервер, диск и ночной прогон. Приведённые числа описывают состояние инструментов и ограничения платформы, а не производительность вашей схемы. Отдельно отмечу: на машине, где готовился материал, WSL не установлен (wsl --status отвечает «The file cannot be accessed by the system»), поэтому поведение wsl --mount проверено по документации, а не запуском.

Сильные стороны продукта

Речь о сильных сторонах самой схемы «rsync + —link-dest + WSL».

1. Снимок каждого дня выглядит полным. Восстановить отдельный файл можно, просто открыв каталог нужной даты, — не нужен ни репозиторий, ни распаковка.
2. Место растёт на объём изменений. Неизменённые файлы — жёсткие ссылки; на файловом сервере, где меняется 1–2 % данных в день, экономия на порядок.
3. Права и владельцы сохраняются. На EXT4 внутри WSL rsync -a работает как на Linux: UID/GID, режимы, симлинки.
4. Pull-модель уменьшает ущерб от компрометации. У сервера нет ключа к приёмнику: снести копии с него нельзя.
5. Транспорт — обычный SSH. Не нужен ни агент, ни открытый порт на Windows, ни SMB-шара.
6. Восстановление не требует специального софта. Любая Linux-машина с rsync заберёт данные обратно; читать снимки можно и через \\wsl$ из Проводника.
7. Схема расширяется. Дампы баз, архивы конфигов и журнал — те же несколько строк в скрипте, без отдельного продукта.

Установка

Порядок: поставить WSL, обновить его, установить пакеты, подготовить диск, настроить ключ.

wsl --install
wsl --update
wsl --status

sudo apt update && sudo apt install -y rsync openssh-client
ssh-keygen -t ed25519 -f ~/.ssh/id_backup -N ""
ssh-copy-id -i ~/.ssh/id_backup.pub root@server.example.org
ssh -i ~/.ssh/id_backup root@server.example.org hostname

Подготовка диска: снять букву в «Управлении дисками», найти номер устройства и подключить его внутрь WSL.

Get-CimInstance Win32_DiskDrive | Select-Object DeviceID,Model,Size
wsl --mount \\.\PHYSICALDRIVE2 --bare

sudo lsblk
sudo mkfs.ext4 /dev/sdc1 -L backup
sudo mkdir -p /mnt/backup
sudo mount -t ext4 /dev/sdc1 /mnt/backup

Настройка

Дальше — шесть решений, которые надо принять явно: где хранить снимки, что исключать, как часто запускать, сколько хранить, кто получает отчёт и как проверяется восстановление.

flowchart TD
  S["Настройка схемы"] --> FS{"файловая система приёмника"}
  FS -- EXT4 --> P["права и ссылки сохраняются"]
  FS -- NTFS --> M["опция metadata в WSL"]
  P --> EX["файл исключений"]
  M --> EX
  EX --> SCH["расписание и автомонтирование"]
  SCH --> RET["глубина хранения снимков"]
  RET --> CHK{"восстановление проверено?"}
  CHK -- нет --> CHK
  CHK -- да --> OK["схема принята в эксплуатацию"]

Автоматизация монтирования: wsl --mount требует прав администратора, поэтому диск подключается задачей Планировщика при старте системы, а монтирование раздела — строкой в /etc/fstab с nofail.

$action = New-ScheduledTaskAction -Execute "cmd.exe" `
  -Argument '/c wsl.exe --mount \\.\PHYSICALDRIVE2 --partition 1 --type ext4'
$trigger = New-ScheduledTaskTrigger -AtStartup
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
Register-ScheduledTask -TaskName "WSL-Mount-BackupDisk" -Action $action -Trigger $trigger -Principal $principal -Force

Номер PHYSICALDRIVE может измениться после перестановки дисков — тогда задачу придётся править. Надёжнее искать диск по модели в отдельном скрипте и передавать найденный DeviceID.

Подводные камни

1. CentOS 6 не получает обновлений с 30 ноября 2020 года. Схема бэкапа не делает систему безопаснее: она лишь позволяет её восстановить. Хост на EOL-дистрибутиве — это временное состояние, и планировать миграцию надо параллельно с бэкапом.

2. wsl --mount не работает с флешками и кардридерами. Документация Microsoft прямо перечисляет: USB-накопители, кардридеры и SD-карты не поддерживаются; диск, с которого загружена Windows, тоже подключить нельзя. Для бэкапа нужен отдельный SATA/NVMe-диск или VHDX.

3. wsl --mount подключает диск целиком. Даже если указан --partition, в WSL попадает весь диск: нельзя отдать один раздел и оставить остальные Windows.

4. Права администратора обязательны. Задача, запущенная от обычного пользователя, молча не смонтирует диск — и бэкап упадёт на первом же шаге. Проверяйте RunLevel Highest.

5. Первый запуск без last. Если не обработать отсутствие симлинка, --link-dest укажет в пустоту. Ветка «первый снимок без link-dest» — не украшение, а необходимость.

6. --delete пугает напрасно. Он удаляет файлы только в новом снимке: старые снимки не меняются, потому что там свои копии и ссылки. Опасность другая — --delete при неверно указанном источнике (например, пустой каталог вместо /).

7. --numeric-ids забывают. Без него владельцы сопоставляются по именам: если на приёмнике нет пользователя www-data, файлы получат чужой UID, и восстановление прав станет ручной работой.

8. rsync на источнике может быть старым. CentOS 6 несёт давнюю версию, и часть современных ключей ей неизвестна. Проверяйте rsync --version на сервере, а не на приёмнике; при расхождении версий помогает --rsync-path с явным путём к свежему бинарнику.

9. echo 3 > /proc/sys/vm/drop_caches в скрипте бэкапа — плохая идея. Это сбрасывает кэш страниц всей системы: на боевом сервере это удар по производительности ради нулевой пользы для копирования. В исходной версии статьи шаг был «как в оригинальном скрипте» — из рабочей схемы его лучше убрать.

10. Потоковый zip в stdout ненадёжен. Конструкция вида ssh host "zip -r -0 - /path" > file.zip на части сборок Info-ZIP не работает: архиватор не пишет архив в стандартный вывод в таком режиме. Для конфигов надёжнее tar: ssh host "tar czf - /etc /usr/local/nginx" > conf.tgz.

11. PURGE BINARY LOGS в бэкап-скрипте — это изменение сервера. Очистка binlog меняет состояние источника и может сломать репликацию. Ей место в отдельном регламенте обслуживания, а не в скрипте копирования.

12. Жёсткие ссылки живут в пределах одной файловой системы. --link-dest работает, только если прошлый и новый снимок лежат на одном смонтированном разделе. Перенос каталога снимков на другой диск превращает инкремент в полное копирование.

13. Удаление файлов внутри старого снимка «руками» рвёт цепочку. Снимки не независимы: удаление одного файла в старом каталоге может испортить вид других дат. Удалять нужно снимок целиком.

14. Бэкап без проверки восстановления — это надежда, а не бэкап. Раз в месяц: восстановить произвольный файл, импортировать дамп базы на тестовую машину, сверить размер и число файлов.

Чек-лист внедрения

• [ ] Диск бэкапа — отдельный (не системный, не флешка), размечен в EXT4 или NTFS с metadata.
• [ ] WSL2 установлен и обновлён; wsl --status отвечает без ошибок.
• [ ] wsl --mount выполняется задачей с правами администратора, раздел монтируется по fstab с nofail.
• [ ] SSH-ключ с приёмника на источник работает без пароля, ключ без парольной фразы (для расписания).
• [ ] Скрипт проверяет mountpoint перед копированием и выходит с ошибкой, если диск не смонтирован.
• [ ] Файл исключений покрывает виртуальные ФС, кэши и каталог базы.
• [ ] Обработан первый запуск (без --link-dest) и обновление симлинка last.
• [ ] Настроено расписание и уведомление о результате; журнал пишется в файл.
• [ ] Определена глубина хранения и порядок удаления старых снимков целиком.
• [ ] Проведена учебная проверка восстановления: файл и дамп базы.

FAQ

Итог

Схема «Linux → Windows» через WSL с диском в EXT4 остаётся рабочим решением для небольшой инфраструктуры: снимки выглядят полными, место растёт на изменения, права сохраняются, а инициатива копирования — на стороне приёмника. Требования к дисциплине при этом высокие: проверка монтирования, файл исключений, обработка первого запуска, контроль результата и регулярная проверка восстановления.

Главное, что стоит держать в голове: бэкап EOL-системы — это отсрочка, а не решение. CentOS 6 без обновлений с 2020 года; копии сохранят данные, но не устранят причину, по которой сервер надо переводить на поддерживаемый дистрибутив.

Цитата: Резервная копия становится бэкапом только в тот момент, когда из неё что-то успешно восстановили; до этого это просто занятое место.

Связанные материалы

• Документация Microsoft: подключение диска в WSL 2 — wsl --mount, --bare, --vhd и полный список ограничений.
• Описание rsync (man) — --link-dest, --numeric-ids, --delete и правила исключений.
• Даты окончания поддержки CentOS — таблица EOL по веткам, использованная в замерах.
• restic — дедуплицированные зашифрованные репозитории как современная альтернатива снимкам.
• BorgBackup — второй вариант дедуплицирующего бэкапа с проверкой целостности.
• Рубрика «Системное администрирование» — остальные материалы по эксплуатации серверов.

LLM Summary

• Тема: инкрементальный бэкап с Linux-сервера на Windows-машину через WSL2 и rsync --link-dest.
• Что делает: создаёт ежедневный снимок, который выглядит полным, но занимает место только на изменения; хранит права и владельцев за счёт EXT4.
• Форма: pull-модель — Windows/WSL инициирует копирование по SSH с сервера; у источника нет доступа к хранилищу копий.
• Устройство: WSL2 + отдельный диск (wsl --mount), каталоги backup.RSYNC/<дата>, симлинк last как источник --link-dest, дампы MySQL и архивы конфигов рядом.
• Ключевые команды: rsync -aR --delete --numeric-ids --link-dest=<last> -e ssh host:/ <снимок>/, mountpoint -q, wsl --mount \\.\PHYSICALDRIVE2 --bare, wsl.exe --mount <Disk> --partition 1 --type ext4.
• Проверенные ограничения: wsl --mount требует прав администратора, не поддерживает USB/флешки/SD и диск загрузки Windows, подключает диск целиком.
• Состояние платформы: CentOS 6 — EOL 30.11.2020, CentOS 7 — 30.06.2024 (endoflife.date, 13.11.2026).
• Замеры: NTFS-жёсткие ссылки проверены локально на Windows 11 (два имени — один файл); скорость и дедупликация не измерялись — нужен реальный прогон.
• Грабли: отсутствие проверки точки монтирования, забытый --numeric-ids, первый запуск без last, удаление файлов внутри старых снимков, drop_caches и PURGE BINARY LOGS в скрипте бэкапа, zip в stdout.
• Альтернативы: restic 0.19.1 и borg 1.4.5 — дедупликация и шифрование вместо «полных на вид» снимков.
• Ссылки: документация Microsoft по wsl --mount, man rsync, endoflife.date/centos, restic.net.

Промт для агента (установка и настройка)

Источник шагов — документация Microsoft по подключению диска в WSL 2 (wsl2-mount-disk), справочная страница man rsync и файл исключений из этой статьи; отдельных файлов AGENTS.md или README у задачи нет — это инфраструктурная схема, а не проект с репозиторием.

Задача: настроить инкрементальный бэкап Linux-сервера на Windows-машину через WSL2 с rsync --link-dest.

1. Проверить источник: rsync --version, ssh-доступ, свободное место, не EOL ли дистрибутив (endoflife.date).
2. Установить WSL2 и дистрибутив: wsl --install; wsl --update; wsl --status.
3. Поставить пакеты в WSL: sudo apt update && sudo apt install -y rsync openssh-client.
4. Сгенерировать ключ без пароля и скопировать его на сервер: ssh-keygen -t ed25519, ssh-copy-id.
5. Подготовить отдельный диск: снять букву в «Управлении дисками», найти DeviceID через Get-CimInstance Win32_DiskDrive.
6. Подключить диск в WSL с правами администратора: wsl --mount \\.\PHYSICALDRIVE<N> --bare; проверить sudo lsblk.
7. Разметить и смонтировать: mkfs.ext4 -L backup, mount -t ext4 /dev/sdX1 /mnt/backup, запись в /etc/fstab с nofail.
8. Создать структуру: каталог снимков, каталоги дампов баз и конфигов.
9. Написать файл исключений: /proc, /sys, /dev, /run, /mnt, /media, /tmp, кэши, каталог базы.
10. Написать скрипт: проверка mountpoint, ветка первого запуска без --link-dest, rsync с -aR --numeric-ids --link-dest, обновление симлинка last, журнал.
11. Добавить сбор данных: mysqldump --single-transaction в отдельный каталог, tar для конфигов (не zip в stdout).
12. Настроить расписание: задача Планировщика для wsl --mount при старте, запуск скрипта ночью, уведомление при ошибке.
13. Проверить вручную: запуск с --dry-run, затем боевой прогон, контроль размера снимка и записи в журнале.
14. Провести учебное восстановление: вернуть один файл и импортировать дамп базы на тестовую машину.
15. Зафиксировать регламент: глубина хранения, кто читает журнал, как часто проверяется восстановление.