Полное решение: как организовать инкрементальный бэкап с CentOS 6 на Windows 11, используя совместимый файловый формат, оптимальный способ передачи данных и максимально надежный механизм хранения версий. Документ включает инструкцию по настройке Windows 11 (включая установку SSH-сервера), рекомендации по выбору файловой системы и сценарии rsync с поддержкой --link-dest.

Введение

Инкрементальный резервный копировщик на CentOS 6 ранее сохранял бэкапы локально на диск с файловой системой Linux, используя утилиту rsync для создания снимков состояния системы с эффективным использованием места. При каждом запуске скрипта создавалась новая папка с датой, в которую копировались только изменившиеся файлы, а неизменённые файлы между бэкапами представлялись жёсткими ссылками на копии из предыдущего снимка. Таким образом, каждый бэкап выглядел как полная копия данных на ту дату, но общий объём на диске рос только на размер изменений. Данная схема обеспечивала удобный доступ к файлам на любую дату и экономию дискового пространства.

Теперь требуется организовать такой же инкрементальный бэкап через сеть на Windows 11, сохраняя целевым каталогом диск B:\CentOS.6\ на Windows. Это задача непростая, поскольку нужно учесть различия между Linux и Windows: различия в типах файловых систем (например, EXT4 vs NTFS), поддержку ссылок и прав доступа, а также сетевое взаимодействие между CentOS и Windows. В этом руководстве мы рассмотрим возможные подходы и предложим наилучшее решение, подробно описав его реализацию.

1. Возможные подходы к резервному копированию между CentOS и Windows

Существует несколько вариантов организации бэкапа с сервера CentOS на хранилище под управлением Windows 11:

• Использование общих папок (SMB/CIFS) с push-методом – можно расшарить папку на Windows и примонтировать её на CentOS как CIFS-диск. Затем запускать rsync на CentOS, копируя данные в сетевой монтаж. Такой подход прост в настройке, но есть тонкости:
• Нужно убедиться, что Samba/NTFS поддерживает создание жёстких ссылок через CIFS. NTFS поддерживает жёсткие ссылки на уровне файловой системы, поэтому при правильной настройке rsync сможет создавать их и на сетевом диске. Однако поддержка жёстких ссылок по протоколу CIFS может зависеть от версий и настроек. В некоторых случаях rsync при прямом копировании по сети выдаёт ошибку remote host doesn't support hard links, тогда как при монтировании CIFS и локальном создании ссылок – всё работает. Нестабильность CIFS может создать проблемы.
• Нужно сохранить права и владельцев файлов Linux на NTFS. По умолчанию при монтировании CIFS права могут теряться или маппиться на одного пользователя. Это затруднит полноценное восстановление системы по бэкапу.
• С точки зрения безопасности, постоянное монтирование Windows-шары на CentOS несёт риск: если сервер CentOS скомпрометируют, злоумышленник получит доступ и к резервной копии.
• Использование rsync-сервера или SSH на Windows с push-методом – можно установить на Windows утилиту rsync (например, через Cygwin/cwRsync) или настроить встроенный OpenSSH-сервер Windows. CentOS-скрипт тогда будет отправлять данные на Windows по SSH/rsync-протоколу. Это устранит проблемы CIFS, потому что rsync на Windows сможет самостоятельно создавать жёсткие ссылки на NTFS. Однако придётся устанавливать и поддерживать POSIX-окружение на Windows (Cygwin) или OpenSSH + утилиты, что усложняет настройку. Кроме того, запускать rsync-сервер/демон постоянно на Windows не всегда удобно и безопасно.
• Использование утилиты резервного копирования на Windows с pull-методом – напротив, можно перенести логику на Windows: настроить Windows на запрос данных с CentOS. Например, задействовать Windows Subsystem for Linux (WSL) или Cygwin для запуска скрипта, который по SSH заберёт данные с CentOS. При таком подходе инициатором бэкапа выступает Windows. Это выгодно в плане безопасности: бэкап-сервер сам забирает данные, а производственный сервер (CentOS) не имеет прямого доступа к хранилищу резервных копий. Если CentOS скомпрометирован, он не сможет напрямую стереть или зашифровать резервные копии, т.к. не знает учётных данных доступа к Windows.
• Форматирование диска Windows в Linux-совместимую ФС (например, EXT4) – вне зависимости от push/pull, можно использовать на Windows файловую систему, которая полностью поддерживает POSIX-атрибуты и жёсткие ссылки. NTFS хоть и поддерживает жёсткие ссылки, не хранит Unix-права и владельцев. Поэтому есть вариант отформатировать диск B: в EXT4 и работать с ним через WSL (Windows Subsystem for Linux). Windows 11 с WSL2 умеет монтировать физические диски с EXT4 напрямую в Linux-окружение. В таком случае среда WSL (Ubuntu) будет видеть диск точно так же, как CentOS, со всеми возможностями Linux-файловой системы. Это позволит использовать rsync с --link-dest без ограничений, хранить правильные UID/GID и права, а Windows при необходимости сможет получать доступ к файлам через WSL (по пути \\wsl$ в Проводнике). Недостаток – сам Windows 11 “из коробки” не умеет читать EXT4, то есть прямого доступа к файлам на диске B: из проводника не будет (только через WSL). Однако, если это выделенный диск под резервные копии, то доступ через WSL или временное подключение драйверов EXT4 – приемлемая плата за надёжность.

Выбор оптимального решения: Мы рекомендуем перенести логику бэкапа на Windows 11, используя WSL и при необходимости отформатировав целевой диск в EXT4. Этот вариант требует установки WSL (что несложно), но даёт наибольшую надёжность и гибкость:

• Надёжность POSIX-семантики: В WSL (особенно с EXT4-диском) будут полностью поддерживаться символические и жёсткие ссылки, права доступа, UID/GID и т.д., как на обычном Linux. Инкрементные бэкапы будут идентичны по структуре тем, что вы делали на CentOS – со ссылками на неизменённые файлы и т.д. Не нужно беспокоиться о том, поддержит ли CIFS создание ссылок – WSL работает с диском напрямую на уровне файловой системы.
• Безопасность: Реализация pull-метода – Windows/WSL инициирует подключение к CentOS – означает, что CentOS сервер не хранит реквизитов для доступа к Windows. Если CentOS будет взломан, атакующий не сможет легко уничтожить резервные копии, т.к. диск B: не смонтирован на CentOS постоянно.
• Производительность: WSL2 – это легковесная VM с Linux-ядром, обеспечивающая почти родной уровень производительности дисковых операций. Rsync будет выполняться локально внутри WSL с доступом к диску, минуя лишние сетевые прослойки (данные передаются по SSH или по сети только один раз – с CentOS на WSL). Это эффективнее, чем писать по CIFS (где мог бы быть оверхед из-за SMB). Кроме того, EXT4 лучше подходит для большого количества файлов и линков, чем NTFS.
• Гибкость: WSL-окружение позволит использовать привычные Linux-утилиты (ssh, rsync, bash) прямо на Windows. Можно легко модифицировать скрипт, добавить мониторинг, отправку уведомлений и т.д., используя богатый набор Linux-инструментов, не завися от наличия аналогов под Windows.

Далее мы подробно разберём все шаги реализации этого решения: от установки WSL и подготовки диска на Windows 11, до настройки скрипта бэкапа и его автоматизации. Также уделим внимание ключевым моментам (правам доступа, созданию ссылок, сохранности данных баз данных MySQL и т.п.), чтобы ничего не упустить в такой критически важной инфраструктуре.

2. Настройка Windows 11: установка WSL и подготовка диска под бэкап

Прежде чем перенести сам механизм бэкапа, настроим окружение на Windows 11.

2.1. Установка Windows Subsystem for Linux (WSL)

1. Установите WSL. Откройте PowerShell от имени администратора (через поиск меню Пуск, введите «PowerShell», правый клик – запуск с правами администратора). Выполните команду установки WSL с дистрибутивом Ubuntu по умолчанию:

   wsl --install

Эта команда включит необходимые компоненты и скачает образ Ubuntu (по умолчанию) из Microsoft Store. После завершения установки может потребоваться перезагрузка Windows. Первый запуск WSL попросит вас задать имя пользователя и пароль для Ubuntu – создайте пользователя (например, backupuser) и запомните пароль. Этот пользователь будет использован для запуска наших скриптов.

2. Обновление WSL (при необходимости). Убедитесь, что используете WSL2 (в Windows 11 по умолчанию). Выполните в PowerShell:

   wsl --update

Это обновит WSL ядро до последней версии.

3. Установите необходимые пакеты в Ubuntu (WSL). Откройте терминал WSL (например, в PowerShell наберите wsl для входа в Ubuntu). Обновите менеджер пакетов и установите rsync, ssh-клиент и zip (вдруг не установлены по умолчанию):

   sudo apt update
   sudo apt install -y rsync openssh-client zip

Примечание: Пакет openssh-client обычно уже есть, но на всякий случай. zip нужен для упаковки конфигов (NGINX.zip) как в старом скрипте.

4. Настройка SSH-доступа к CentOS. Чтобы WSL-скрипт мог подключаться к серверу CentOS без пароля, создадим SSH-ключи и скопируем их на CentOS:

• В WSL (под вашим пользователем) сгенерируйте ключ без пароля: ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N "" Это создаст файлы ~/.ssh/id_rsa (приватный ключ) и ~/.ssh/id_rsa.pub (публичный ключ).
• Скопируйте публичный ключ на CentOS. Можно использовать утилиту ssh-copy-id (установите на CentOS, если нет, или вручную): ssh-copy-id -i ~/.ssh/id_rsa.pub root@<IP-адрес_CentOS> Введите пароль root на CentOS при запросе. После этого ключ добавится в ~/.ssh/authorized_keys на CentOS, и дальнейшие входы из WSL по ключу не запросят пароль.
• Проверьте соединение. Из WSL выполните: ssh root@<IP-адрес_CentOS> "hostname" Должно войти без пароля и вывести имя хоста CentOS. Если по каким-то причинам прямое SSH-подключение с Windows к CentOS невозможно (например, сервер CentOS находится за NAT), нужно настроить доступность либо проброс портов (VPN, SSH-туннель), либо рассмотреть push-сценарий (в котором CentOS сам коннектится к Windows). В этом руководстве предполагается, что SSH-доступ с Windows к CentOS есть (например, по локальной сети или белому IP).

2.2. Подготовка диска B:\CentOS.6 для хранения резервных копий

Вариант 1: Форматирование диска в EXT4 (рекомендуется для полного соответствия Linux-среде).

Поскольку вы готовы отформатировать диск, рассмотрим процесс перевода диска B: в файловую систему EXT4 и подключение его в WSL. Внимание: Это уничтожит все данные на диске B:. Убедитесь, что на нём нет нужной информации, или сделайте резервную копию перед форматированием.

1. Отключение диска от Windows: Чтобы Windows не мешал, рекомендуется снять букву диска B: в системе, прежде чем форматировать его в EXT4. Это можно сделать через «Управление дисками»: правой кнопкой по разделу B: -> «Изменить букву и путь…» -> Удалить букву. (После перевода в EXT4 Windows его всё равно не сможет читать, но этот шаг гарантирует, что Windows не попытается что-то записывать на него во время процесса.)
2. Определение номера диска: Нам нужно узнать, под каким идентификатором Windows видит физический диск B:. В PowerShell (администратор) выполните:

   GET-CimInstance -query "SELECT * from Win32_DiskDrive"

Это выведет список дисков. Найдите диск, соответствующий вашему B: (по размеру или модели). Скопируйте его DeviceID – будет вида \\.\PHYSICALDRIVE0, \\.\PHYSICALDRIVE1, … В примере будем считать, что диск – \\.\PHYSICALDRIVE2 (у вас номер может отличаться).

3. Подключение диска в WSL: Запустите команду (в PowerShell от администратора):

   wsl --mount \\.\PHYSICALDRIVE2 --bare

Ключ --bare означает «подключить диск к WSL, но не монтировать автоматически». Мы хотим сами выполнить форматирование. Команда сделает диск доступным внутри WSL (но ещё не смонтирует файловую систему). Если на диске уже был раздел, WSL мог попытаться его автомонтировать. Убедимся в состоянии следующим шагом.

4. Форматирование раздела в EXT4: Откройте терминал WSL (если не открыт) и выполните:

   sudo lsblk

Вы должны увидеть новый блоковый девайс (например, /dev/sdc и, возможно, /dev/sdc1 если на диске есть разбивка на разделы). Если диск был разбит и имел один раздел (типично для диска B:), он отобразится как /dev/sdc1 (в нашем примере). Предположим, что раздел – /dev/sdc1. Выполните форматирование EXT4:

   sudo mkfs.ext4 /dev/sdc1 -L "CentOS-Backup"

Параметр -L задаёт метку тома (можно указать любую осмысленную метку).

Подтвердите действие, если будет предупреждение, и дождитесь завершения форматирования. Теперь на разделе /dev/sdc1 создана пустая файловая система EXT4.

5. Монтирование EXT4-раздела в WSL: Создадим точку монтирования и примонтируем диск:

   sudo mkdir -p /mnt/backup
   sudo mount -t ext4 /dev/sdc1 /mnt/backup

Вы можете использовать другой путь, но /mnt/backup выбрано для определённости. Теперь содержимое диска B: доступно внутри WSL по пути /mnt/backup. Поскольку диск новый, каталог пустой.

Совет: WSL по умолчанию монтирует такие диски в каталог /mnt/wsl/... при подключении без --bare. Однако ручной mount даёт больше контроля. Можно добавить запись в /etc/fstab внутри WSL, но это будет работать только пока диск виден WSL (после wsl --mount). Автоматизируем монтирование позднее.

6. Проверка доступа: Создайте тестовый файл:

   echo "WSL backup test" | sudo tee /mnt/backup/test.txt
   ls -l /mnt/backup/test.txt

Убедитесь, что файл создан и доступен.

По умолчанию, все файлы на вновь смонтированном EXT4 будут принадлежать root и иметь права по умолчанию (например, 755 для директорий, 644 для файлов). В нашем случае, так как мы будем запускать бэкап-скрипт с привилегиями (можно под root в WSL или через sudo), проблем с правами на /mnt/backup не ожидается. При желании, можно изменить владельца /mnt/backup на вашего WSL-пользователя:

   sudo chown -R $(whoami):$(whoami) /mnt/backup

Тогда запись от вашего пользователя не потребует sudo. Однако создание жёстких ссылок и сохранение UID/GID оригинальных файлов потребует root-привилегий при копировании системы, поэтому скрипт мы всё равно будем запускать через sudo.

7. Настройка доступа к содержимому из Windows (опционально): Вы не увидите диск B: в Проводнике напрямую, но Windows может получить доступ к файлам через UNC-путь WSL. Например, откройте Проводник Windows и введите путь:

   \\wsl$\Ubuntu\mnt\backup

Здесь Ubuntu – имя дистрибутива WSL (для Ubuntu по умолчанию). Вы должны увидеть файл test.txt. Он откроется как обычный файл. Таким образом, в случае необходимости можно вручную брать файлы из резервной копии, не устанавливая дополнительных драйверов EXT4. Важно: Никогда не изменяйте файлы бэкапа с этой стороны (через Windows), чтобы не нарушить UNIX-права и жёсткие ссылки. Используйте доступ только для чтения/копирования файлов из резервной копии, а запись/удаление – только через WSL/Linux-инструменты.

8. Отключение диска после работы (опционально): Когда вы завершите работы (например, отладку или первые тесты), можно отключить диск из WSL:

   sudo umount /mnt/backup
   exit  # выход из WSL

А затем в PowerShell:

   wsl --unmount \\.\PHYSICALDRIVE2

Это отсоединит диск от WSL. Поскольку мы собираемся использовать этот диск постоянно для резервного копирования, можно его не отключать каждый раз вручную. При перезагрузке Windows он и так отсоединится, так что нужно будет заново подключать (см. раздел автоматизации).

Вариант 2: Использование диска в NTFS (без форматирования).

Если вы предпочитаете не форматировать диск B: (например, на нём уже есть данные или вы хотите иметь к нему прямой доступ из Windows), можно оставить NTFS, но тогда бэкап будет чуть менее “прозрачен” для Linux. WSL позволяет монтировать диски с NTFS с включением поддержки Unix-атрибутов. Кратко опишем эту альтернативу:

• В WSL можно примонтировать существующий диск B: как drvfs. Обычно Windows разделы автоматически доступны в WSL по пути /mnt/b, однако, чтобы сохранять права Unix, нужно добавить опцию metadata. Например:

  sudo umount /mnt/b  # если уже смонтирован автоматически
  sudo mount -t drvfs B: /mnt/backup -o metadata

Опция metadata заставляет WSL хранить UID/GID и права файлов в специальной альтернативной потоковой информации NTFS. Это позволит rsync сохранять владельцев и права как на Linux. Без этой опции все файлы выглядели бы с одинаковыми правами и владельцем. Учтите, что жёсткие ссылки на NTFS WSL создавать умеет – ln внутри /mnt/c или /mnt/b создаёт настоящие Windows hard link. Однако, символические ссылки WSL на NTFS-диске создаёт в Windows-формате, что может приводить к тому, что Windows их увидит, а Linux – сможет использовать. Для нашей цели (symlink last указывать на последнюю папку) это не критично. Если возникнут проблемы с созданием symlink на NTFS (возможно, понадобится запустить WSL с правами администратора или включить Developer Mode в Windows для не-привилегированного создания symlink), можно заменить её созданием джанкции Windows (mklink /J) или обходиться без неё.

• Недостатки NTFS-подхода: возможны небольшие накладные расходы на хранение метаданных, и потенциально менее надёжно хранение структуры прав Linux (хоть и должно работать). Кроме того, NTFS при очень большом количестве файлов может работать медленнее EXT4. Тем не менее, если форматирование невозможно, решение с NTFS + WSL тоже работоспособно. Мы далее будем описывать реализацию, исходя из того, что диск в EXT4 и смонтирован на /mnt/backup. Но вы можете адаптировать скрипт под /mnt/backup на NTFS (с опцией metadata) – отличия минимальны.

3. Разработка скрипта резервного копирования в WSL

Теперь подготовим скрипт, выполняющий резервное копирование. По сути он повторяет логику оригинального скрипта под CentOS, но с учётом новой архитектуры (CentOS – источник, Windows/WSL – получатель). Мы будем выполнять скрипт в WSL (Ubuntu), запуская команды по SSH на CentOS для получения данных.

Для удобства, расположим скрипт в WSL, например в домашнем каталоге пользователя backupuser (которого создали при установке). Назовём файл centos_backup.sh. Создайте файл /home/backupuser/centos_backup.sh и откройте его в редакторе (nano, vim или через VSCode/Notepad, как вам удобнее – WSL-файлы доступны по \\wsl$\Ubuntu\home\backupuser\).

Вставьте в файл следующий содержимый скрипт:

#!/bin/bash

# ----------------------------------------------
# CentOS-to-Windows Incremental Backup Script
# Author: Mikhail Deynekin.ru
# Date:   07/07/2025
# ----------------------------------------------
#
# Этот скрипт выполняется в среде WSL (Ubuntu на Windows 11)
# и копирует данные с сервера CentOS 6 на локальный диск,
# монтируемый в WSL (например, /mnt/backup).
# Используется rsync с инкрементальным копированием (--link-dest)
# для сохранения только изменений относительно предыдущего запуска.
# Кроме файловой системы, скрипт также экспортирует дампы MySQL баз данных.
# 
# !!! Внимание: Перед запуском убедитесь, что:
#     1) Диск с EXT4 (или NTFS) смонтирован на /mnt/backup.
#     2) SSH-ключи настроены, и можно входить на CentOS без пароля.
#     3) Указаны верные IP/имя хоста CentOS и пути к файлам.
#
# ----------------------------------------------

# Конфигурационные переменные
CENTOS_HOST="root@<IP-адрес_CentOS>"    # Учетные данные для SSH на сервер CentOS (пользователь@адрес)
CENTOS_ROOT="/"                        # Корневой путь на сервере CentOS, который бэкапим. "/" - весь сервер.
EXCLUDE_FILE="/home/backupuser/rsync-exclude.txt"  # Локальный путь к файлу исключений rsync
BACKUP_MOUNT="/mnt/backup"             # Точка монтирования резервного диска в WSL
SNAPSHOT_DIR="$BACKUP_MOUNT/backup.RSYNC"  # Каталог для инкрементных снимков
DAILY_DIR_NAME="$(date +%Y-%m-%d)"     # Название папки для текущего бэкапа (текущая дата)
CURRENT_SNAPSHOT="$SNAPSHOT_DIR/$DAILY_DIR_NAME"  # Путь для нового снимка
LAST_SNAPSHOT_LINK="$SNAPSHOT_DIR/last"           # Ссылка (symlink) на последний снимок

BACKUP_MISC_DIR="$BACKUP_MOUNT/backup" # Каталог для прочих резервных данных (mysql, конфиги)
MYSQL_BACKUP_DIR="$BACKUP_MISC_DIR/mysql"       # Здесь будут свежие дампы MySQL
MYSQL_BACKUP_OLD_DIR="$BACKUP_MISC_DIR/mysql.old"   # Здесь хранятся предыдущие дампы MySQL
NGINX_CONF_DIR="/usr/local/nginx"     # Папка с конфигурацией NGINX на CentOS (для отдельного архива)

# Проверка наличия точки монтирования
if [ ! -d "$BACKUP_MOUNT" ]; then
    echo "Ошибка: каталог $BACKUP_MOUNT не найден. Убедитесь, что диск смонтирован в WSL."
    exit 1
fi

# Создание необходимых каталогов на резервном диске, если их ещё нет
mkdir -p "$SNAPSHOT_DIR" "$BACKUP_MISC_DIR" "$MYSQL_BACKUP_DIR" "$MYSQL_BACKUP_OLD_DIR"

# 1. Очистка кэша памяти на сервере CentOS (опционально, для уменьшения нагрузки при чтении)
echo "Очистка дисковых кэшей на сервере CentOS..."
ssh $CENTOS_HOST "free && sync && echo 3 > /proc/sys/vm/drop_caches && free" 

# 2. Очистка временных файлов/сессий на сервере (опционально, чтобы не тащить мусор в бэкап)
echo "Очистка временных файлов на CentOS..."
ssh $CENTOS_HOST "find /var/www/md/data/mod-tmp/ -maxdepth 1 -name 'sess_*' -delete"

# 3. (Опционально) Подготовка списка изменений с прошлого бэкапа (diff)
# Если требуется, можно расскомментировать следующие строки, чтобы собрать список изменённых файлов:
# echo "Составление списка отличий с предыдущего снимка..."
# DIFF_FILE="$BACKUP_MISC_DIR/different.txt"
# ssh $CENTOS_HOST "diff -rwBdq --speed-large-files -X /home/diff_exclude.txt /var/www/ $LAST_SNAPSHOT_LINK/var/www/ || true" > "$DIFF_FILE"
# sed -i -r 's/(Files|Файлы) /diff -rwB\t\t/gi' "$DIFF_FILE"
# sed -i -r 's/( and | и )/\t\t\t/gi' "$DIFF_FILE"
# sed -i -r 's/( differ| различаются)//gi' "$DIFF_FILE"
# # отправить файл по почте (потребуется настроенный sendmail/Postfix):
# # cat "$DIFF_FILE" | mail -s "Change log ($DIFF_FILE)" admin@example.com

# 4. Основное резервное копирование с помощью rsync
echo "Запуск rsync для инкрементного бэкапа $(date)..."
# Параметры rsync:
# -a : архивный режим (рекурсия, сохранение прав, владельцев и т.д.)
# -v : подробный вывод (verbose)
# -R : сохранять относительный путь (чтобы корневой '/' правильно обрабатывался)
# --delete : удалять на приемнике файлы, которые удалены на источнике (в пределах этого запуска)
# --link-dest : ссылка на предыдущий бэкап для неизменённых файлов
# --exclude-from : исключить определённые пути (список в файле)
rsync -avR --delete --link-dest="$LAST_SNAPSHOT_LINK" --exclude-from="$EXCLUDE_FILE" \
    -e "ssh" $CENTOS_HOST:"$CENTOS_ROOT" "$CURRENT_SNAPSHOT"

# Проверка кода выхода rsync
if [ $? -ne 0 ]; then
    echo "Ошибка: rsync завершился с ошибкой. Проверяйте вывод выше."
    # При неудаче можно прибраться, чтобы не оставить битый снимок:
    rm -rf "$CURRENT_SNAPSHOT"
    exit 1
fi

# 5. Обновление символической ссылки "last" на новый снимок
echo "Обновление ссылки на последний снимок -> $DAILY_DIR_NAME"
# Удаляем старую ссылку и создаём новую
rm -f "$LAST_SNAPSHOT_LINK"
ln -s "$CURRENT_SNAPSHOT" "$LAST_SNAPSHOT_LINK"

# 6. Резервирование (ротация) дампов MySQL с сервера CentOS
echo "Копирование предыдущих дампов MySQL в архивную папку..."
# Переместим содержимое текущих mysql-дампиков в mysql.old (удалим старое и заменим новым)
rm -rf "$MYSQL_BACKUP_OLD_DIR/*"
cp -al "$MYSQL_BACKUP_DIR/." "$MYSQL_BACKUP_OLD_DIR/" 2>/dev/null || true
# (cp -al пытается сделать жёсткие ссылки на файлы, чтобы быстро скопировать; если не получится, просто игнорируем)

echo "Создание новых дампов MySQL с сервера CentOS..."
# Список баз данных для дампа
databases=(bs12v stella-com-bx stella_bitrix_backup batteryservice batteryexpert bs-com tickets ticket-com optimate optimate.com.ua optimate1.com.ua midtronics ledzom logiccell puska4 wizard wizard_beta wizard_online zabbix cadex.com.ua cadex armuretendre stellapremio_ru kolben qr bsdocs)

# Проходим по списку и выгружаем каждую базу в отдельный .sql файл
for db in "${databases[@]}"; do
    # Формируем удобное имя файла (заменяем опасные символы вроде '/' или '.' на допустимые)
    safe_name=$(echo "$db" | sed 's/[\/\\\:\*\?\"<>\|]/_/g; s/\.com\.ua/-ua/; s/\.com/-com/; s/\./-/g')
    echo "  -> Экспорт базы '$db'..."
    ssh $CENTOS_HOST "mysqldump --single-transaction --add-drop-table --flush-logs $db" > "$MYSQL_BACKUP_DIR/${safe_name}.sql"
done

# Дополнительно: полный дамп всех баз и очистка binlogs (если нужно, с правами репликации)
echo "  -> Экспорт всех баз данных сразу (mysql_db_backup.sql) и очистка старых binlog на сервере..."
ssh $CENTOS_HOST "mysqldump --single-transaction --add-drop-table --flush-logs --master-data=2 --all-databases" > "$MYSQL_BACKUP_DIR/mysql_db_backup.sql"
# Отдать команду серверу очистить binlogs старше 7 дней
ssh $CENTOS_HOST "mysql -e \"PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);\""

# 7. Резервное копирование конфигурации NGINX (архивирование)
echo "Архивирование конфигурации NGINX..."
NGINX_ZIP_PATH=\"$BACKUP_MISC_DIR/NGINX.zip\"
ssh $CENTOS_HOST "zip -r -0 -q - /usr/local/nginx" > $NGINX_ZIP_PATH

# Завершение
echo "Резервное копирование завершено: $(date). Снимок $DAILY_DIR_NAME создан."

Давайте разберём ключевые моменты этого скрипта:

• Конфигурация путей и переменных: В начале мы определяем переменные:
• CENTOS_HOST – адрес и пользователь для подключения (поставьте тут реальный адрес вашего сервера CentOS 6, пользователь root или другой с нужными правами).
• CENTOS_ROOT – что бэкапим. По умолчанию / – корень (весь сервер). Можно указать подкаталог, если нужно бэкапить выборочно, но обычно для полного бэкапа системы это / с исключениями.
• EXCLUDE_FILE – путь к файлу со списком исключённых путей. Важно: Создайте этот файл rsync-exclude.txt и пропишите туда то, что не нужно копировать. Например, стандартно исключают: /proc/*, /sys/*, /dev/*, /run/*, /mnt/*, /media/*, а также, возможно, временные директории (/tmp/*, кеши). Это предотвратит копирование виртуых ФС и прочего хлама. Можно также исключить сам каталог резервных копий, если он монтируется в файловую систему (но у нас он на другом диске, не в /).
• SNAPSHOT_DIR – каталог, где будут лежать папки с датами (снапшоты) на дискe /mnt/backup. Мы используем структуру как раньше: backup.RSYNC/<YYYY-MM-DD>/.
• LAST_SNAPSHOT_LINK – симлинк на последний снимок, аналогично оригинальному скрипту. Он обновляется при каждом бэкапе, указывая на свежий каталог.
• BACKUP_MISC_DIR и связанные – для прочих данных (MySQL дампы, лог изменений, архив конфигов). В оригинале это было /3TB/backup/mysql и т.п., у нас на Windows будет B:\CentOS.6\backup\mysql и пр., что в WSL монтируется как /mnt/backup/backup/mysql.
• NGINX_CONF_DIR – путь к конфигурациям NGINX на CentOS (если у вас путь отличается, отредактируйте).
• Подготовка каталогов: Скрипт на всякий случай создаёт нужные папки на целевом диске, если их нет (при первом запуске).
• Очистка кэша и временных файлов на CentOS: По SSH выполняется echo 3 > /proc/sys/vm/drop_caches. Это сбрасывает диск-кэш на CentOS, чтобы максимально освободить RAM и избегать долговременного кеширования (опционально, но автор оригинального скрипта это делал). Удаляются временные файлы сессий в /var/www/md/data/mod-tmp/, чтобы не копировать «мусор» (скорее всего, в вашем случае это php-сессии или кеш, можно менять или убирать этот шаг, либо расширить список очищаемых временных данных).
• Diff изменённых файлов: В оригинальном скрипте был блок (закомментированный) для генерации списка различий между текущим состоянием и предыдущим бэкапом с помощью diff -r. В нашем скрипте он также включён как закомментированный (опционально). Если раскомментировать, он выполнит на CentOS команду сравнения (diff -rwBdq) между актуальными данными и последним бэкапом (через доступ к $LAST_SNAPSHOT_LINK). Результат перенаправляется в файл different.txt на резервном диске. Потом несколько строк sed форматируют этот файл, убирая лишние слова и делая столбцы для удобства. Можно затем отправить этот отчёт на почту (для этого нужна настроенная отправка почты, в примере – команда mail на CentOS, закомментирована). Это полезно, например, для ежедневного отчёта, какие файлы поменялись или удалились со вчерашнего дня. Вы можете настроить это, если требуется.
• Основной rsync: Это сердце бэкапа. Команда:

  rsync -avR --delete --link-dest="$LAST_SNAPSHOT_LINK" --exclude-from="$EXCLUDE_FILE" -e "ssh" $CENTOS_HOST:"$CENTOS_ROOT" "$CURRENT_SNAPSHOT"

Разберём параметры:

• -a (archive) – рекурсивно копирует, сохраняет права, владельцев, симлинки и т.д.
• -v – вывод прогресса (можно убрать, если будете запускать по расписанию, чтобы не копился большой лог).
• -R (relative) – очень важно, если источник "/": без -R rsync может не создать корректную структуру. С -R он сохранит полный путь относительно корня. Например, без -R, мог игнорировать ведущий ‘/’, а с -R он внутри $CURRENT_SNAPSHOT создаст папку var/www/... и т.д., как нужно.
• --delete – удаляет файлы в текущем копировании, если они были удалены на исходнике. Здесь важно понимать: ключ --delete в сочетании с --link-dest не трогает предыдущие снапшоты, а только синхронизирует текущее состояние: то есть, если на CentOS что-то удалено с момента последнего бэкапа, то в новом снимке этих файлов не будет. (Они останутся в старых снимках, потому что там жесткие ссылки.)
• --link-dest="$LAST_SNAPSHOT_LINK" – ключ, заставляющий rsync для каждого файла проверять: если файл не изменился по сравнению с тем, что лежит в $LAST_SNAPSHOT_LINK, то rsync не будет копировать файл заново, а сделает жёсткую ссылку на файл из предыдущего снимка. Именно эта опция организует инкрементность. \$LAST_SNAPSHOT_LINK указывает на папку предыдущего бэкапа (например, вчерашнего), на которую у нас имеется symlink last. Таким образом, rsync понимает, где искать “старые” версии файлов.
  • Примечание: Жёсткая ссылка возможна только внутри одного дискового тома/раздела. Поэтому важно, что $LAST_SNAPSHOT_LINK и $CURRENT_SNAPSHOT лежат на одном смонтированном диске (/mnt/backup). В нашем случае так и есть (оба на EXT4-диске B:). Если бы вы попытались сделать --link-dest на удалённую систему, ничего бы не вышло – rsync не умеет линковать по сети. Но здесь всё происходит локально в WSL на одном файловом системе.
• --exclude-from="$EXCLUDE_FILE" – подключает файл с шаблонами исключений. Обязательно настройте этот файл, чтобы не копировать ненужное (см. выше).
• -e "ssh" – говорит rsync использовать SSH как транспорт. В командной строке источник указан как $CENTOS_HOST:"$CENTOS_ROOT", то есть, например, root@192.168.0.10:/. Rsync запустит соединение по SSH на этот хост и будет там исполнять свою серверную часть (там должен быть установлен rsync на CentOS, обычно он есть по умолчанию; если нет, установите yum install rsync).
• Последним параметром идёт путь назначения: "$CURRENT_SNAPSHOT", т.е. локальная папка для нового снимка. Важный момент: Мы не создаём $CURRENT_SNAPSHOT вручную до запуска rsync. Rsync сам создаст директорию "$DAILY_DIR_NAME" (например, 2025-07-30) внутри backup.RSYNC, потому что мы указали -R и путь "/" – он начнёт создавать структуру. Если хотите, можете предварительно делать mkdir "$CURRENT_SNAPSHOT", это не повредит. В нашем случае mkdir делается выше на всю SNAPSHOT_DIR, но не на подкаталог даты. После выполнения rsync мы проверяем код возврата. Если он не 0 (ошибка), на всякий случай удаляем папку $CURRENT_SNAPSHOT (чтобы не оставить неполный бэкап) и выходим с ошибкой. В норме, rsync завершится кодом 0, и скрипт пойдёт дальше.
• Обновление ссылки last: Удаляем старую ссылку last и создаём новую, указывающую на папку только что сделанного снимка. Это нужно сделать после успешного копирования. Мы используем ln -s без флага -f (force) потому что перед этим уже удалили старую ссылку командой rm -f. В результате, last всегда будет указывать на последний инкрементный бэкап. В Linux/WSL эта ссылка работает как обычный симлинк. Windows её напрямую не увидит как папку, но через WSL/сам rsync – это не проблема.
• Резервирование MySQL дампов: Здесь наша задача – аналогично вашему скрипту – сохранять дампы баз данных. В исходном скрипте CentOS выполнялся ряд mysqldump команд, результат писался сразу на диск /3TB (т.е. на тот же диск бэкапов). Мы реализуем нечто похожее, но по SSH. Обратите внимание:
• Сначала мы переносим старые дампы в папку mysql.old. В вашем скрипте это делалось через rsync -rtvu или mv. Я использовал сочетание rm -rf и cp -al:
  • rm -rf "$MYSQL_BACKUP_OLD_DIR/*" – очищаем папку старых дампов.
  • cp -al "$MYSQL_BACKUP_DIR/." "$MYSQL_BACKUP_OLD_DIR/" – эта команда пытается скопировать все файлы из текущих дампов в старую папку, используя жёсткие ссылки (-l) вместо новых копий (в целях экономии места и скорости). Если она не сработает (например, на NTFS без соответствующей поддержки), скрипт просто проигнорирует ошибку (2>/dev/null || true). В EXT4 всё окей – файлы будут мгновенно «скопированы» как ссылки.
  • В результате, папка mysql.old будет содержать предыдущий набор dump-файлов (по сути дублируя mysql перед перезаписью).
• Далее очищаем (или перезаписываем) файлы в mysql свежими дампами:
  • Мы формируем массив databases с названиями всех баз, которые нужно сохранить. Я взял имена из вашего скрипта. Учтите, что имена с точками (например, optimate.com.ua) и прочими символами я обрабатываю через sed, чтобы в имени файла не было недопустимых символов. В частности, .com.ua заменяем на -ua, .com -> -com, остальные точки на -. Это нужно, чтобы на Windows/NTFS не было проблем с именами, и просто для единообразия (в вашем скрипте исходном вы тоже заменяли точки на дефисы в именах файлов).
  • Для каждой базы выполняется SSH с командой mysqldump на CentOS. Обратите внимание: я не указал пользователь/пароль для mysqldump – предполагается, что на CentOS настроен .my.cnf для root с нужным паролем, либо у root нет пароля для локального MySQL, либо использует socket auth. Если это не так, добавьте -u user -p'password' в команду mysqldump (но тогда придётся где-то безопасно хранить пароль; лучше использовать .my.cnf).
  • Вывод каждой команды mysqldump перенаправляется на локальный файл "$MYSQL_BACKUP_DIR/${safe_name}.sql". То есть дамп поступает по SSH прямо на Windows-диск. Это может занять время, особенно для больших баз, но сеть используется один раз. Альтернативный подход: запускать mysqldump на CentOS и сохранять там временно, потом rsync’ом скачивать – но это усложняет. Прямой поток нормально справится, просто мониторьте, чтобы соединение не обрывалось.
  • Дополнительно выполняется один общий дамп --all-databases (в файл mysql_db_backup.sql), на случай если понадобится полное восстановление всех баз разом. Также после этого отправляется SQL-команда на очистку binlog-логов старше 7 дней (у вас в исходнике это делалось через mysql -e 'purge master logs...' – я сохранил, адаптировав к единой строке). Если у вас нет репликации и binlog, эта команда безвредна.
• По итогу, в папке backup/mysql будут свежие .sql дампы всех перечисленных баз + общий backup, а в backup/mysql.old – предыдущая версия этих файлов (свежая перезапишется при следующем запуске).
• Архивация конфигов NGINX: Выполняется zip на CentOS, результат передаётся на stdout и перенаправляется в файл NGINX.zip на нашем диске. Обратите внимание, я экранировал имя файла в переменной NGINX_ZIP_PATH кавычками, чтобы Windows-путь с двоеточием не трактовался неправильно. zip -r -0 без сжатия (-0) используется, видимо, чтобы быстро создать архив (можно и со сжатием, но оригинал делал -0). Если NGINX установлен не в /usr/local/nginx, поправьте путь или добавьте другие нужные конфиги по аналогии.
• Завершение: Скрипт выводит отметку о завершении с датой. Вы можете расширить логирование (например, писать вывод в лог-файл на Windows, или отправлять письмо по завершении). На уровне Windows, если запускать через планировщик, можно настроить, чтобы сообщения скрипта писались в файл.

Не забудьте сделать скрипт исполняемым:

chmod +x /home/backupuser/centos_backup.sh

Также создайте файл rsync-exclude.txt по пути, указанному в EXCLUDE_FILE. Например:

/proc/
,/sys/
,/dev/
,/run/
,/mnt/
,/media/
,/lost+found

(Этот файл может содержать шаблоны; строки начинающиеся с ‘/’ – от корня исходника. Запись ,/dev/ означает исключить всё внутри /dev. Подробный синтаксис exclude-файла см. man rsync.)

При желании можно отработать скрипт сначала без флага --delete и с флагом --dry-run у rsync, чтобы увидеть список копируемых файлов, не изменяя ничего:

rsync -avnR --link-dest=... ... 

Но учитывайте, что --dry-run не создаст жёстких ссылок, он просто симулирует. Для первой копии (когда last ещё не существует), нужно специальное условие. Сейчас, кстати, стоит учесть: при первом запуске не будет папки last. Наш скрипт не делает ничего специального для первого раза. Лучше создать на целевом диске пустой «нулевой» снимок, или обработать это условие. Простейший подход:

• Создайте вручную ссылку last указывающую на пустой каталог или на сам себя. Или модифицируйте скрипт: если нет backup.RSYNC/last, то копировать без --link-dest (полный бэкап) и потом установить last. Поскольку первый бэкап всё равно будет полным, можно так:

  if [ ! -e "$LAST_SNAPSHOT_LINK" ]; then
      # Первый запуск, просто делаем полный бэкап
      rsync -avR --delete --exclude-from="$EXCLUDE_FILE" -e "ssh" $CENTOS_HOST:"$CENTOS_ROOT" "$CURRENT_SNAPSHOT"
  else
      rsync -avR --delete --link-dest="$LAST_SNAPSHOT_LINK" ... "$CURRENT_SNAPSHOT"
  fi

Мы здесь опустили подробности ради краткости. Не забудьте потом всё равно создать last.

В нашем случае, чтобы не усложнять код, можно выполнить подготовительный шаг: когда всё готово к первому запуску, создайте на диске /mnt/backup/backup.RSYNC/last временно пустую директорию или ссылку:

mkdir -p /mnt/backup/backup.RSYNC/last

и оставьте её пустой. Тогда при первом запуске rsync с --link-dest будет считать, что все файлы «не найдены» в link-dest и скопирует заново – что нам и нужно. После копирования скрипт обновит last на актуальный снимок.

4. Автоматизация запуска бэкапа

Автоматизация процесса резервного копирования с применением WSL и физического Linux-диска (например, в EXT4) на Windows требует особого внимания к механизму подключения и монтирования диска в среде WSL. Как показывает практика, сам скрипт бэкапа можно удобно запускать через планировщик задач Windows или cron в WSL, однако именно подготовка диска—а именно автоматическое подключение блочного устройства в WSL—ключевой момент, от которого зависит надежность всего цикла резервирования.

4.1. Проблематика: почему просто fstab не решает вопрос

В отличие от стандартных Linux-систем, где достаточно прописать раздел в /etc/fstab, в WSL физический диск (например, EXT4 на B:) появляется только после явного вызова wsl.exe --mount из Windows с правами администратора. Раннее /etc/fstab пробуется при старте дистрибутива, но если устройство не подключено—возникает ошибка, и монтирование не производится. Поэтому запускать wsl.exe --mount вручную после каждой загрузки неудобно и чревато ошибками [см. предыдущие разделы]. Для профессиональной инфраструктуры нужен полностью автоматизированный и отказоустойчивый цикл:

• Диск автоматически подключается к WSL после загрузки или входа в систему.
• Раздел монтируется по UUID к правильной точке в файловой системе.
• Скрипт резервного копирования запускается либо по расписанию, либо по событию (например, после появления диска или в заданное время).

4.2. Решение: автоматизация подключения физического диска через Планировщик заданий Windows

Классический сценарий автоматизации подключения физического Linux-диска в WSL сводится к созданию служебной задачи, которая при старте Windows или входе пользователя:

1. Выполняет подключение физического устройства в среду WSL (wsl.exe --mount ...);
2. Гарантирует, что раздел EXT4 или другой Linux-файловой системы доступен как блочное устройство;
3. При необходимости запускает автоматическое монтирование средствами самой WSL (например, mount по UUID через /etc/fstab или вручную).

Исполнение задачи обязательно требует прав администратора!

Пошаговая инструкция:

4.2.1. Определяем номер PHYSICALDRIVE вашего резервного диска

• Откройте PowerShell с правами администратора: textGet-CimInstance -Query "SELECT * from Win32_DiskDrive" Найдите ваш диск по размеру или модели, скопируйте идентификатор DeviceID, например: \\.\PHYSICALDRIVE2.

4.2.2. Добавьте запись в /etc/fstab (для автомонтирования после появления устройства)

Откройте Ubuntu/WSL, получите UUID раздела:

textsudo blkid /dev/sdc1    # замените sdc1 на ваш номер раздела

Добавьте строку:

textUUID=ВАШ-UUID /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout=0 0 2

(nofail гарантирует, что при отсутствии устройства система просто пропустит монтирование без ошибок.)

Убедитесь, что в /etc/wsl.conf прописано:

text[automount]
mountFsTab=true

4.2.3. Создаём задачу в Планировщике Windows для подключения диска автоматически

Используйте PowerShell или интерфейс Планировщика Windows. Пример для PowerShell:

powershell$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument '/c wsl.exe --mount \\.\PHYSICALDRIVE2 --partition 1 --type ext4 && wsl -d Ubuntu -- mount -a'
$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

• Задача будет запускаться при старте Windows, монтировать диск в WSL и выполнять монтирование файловых систем по /etc/fstab (опционально запускается mount -a).
• При использовании другого дистрибутива поменяйте -d Ubuntu на -d ваш-дистрибутив.
• Если номер PHYSICALDRIVE может меняться (например, при перестановке USB или SATA-устройств), рекомендуем делать скрипт поиска по серийному номеру/модели. Выражение:

powershell$disk = Get-CimInstance Win32_DiskDrive | where Model -match "название_вашего_диска"
wsl.exe --mount $disk.DeviceID --partition 1 --type ext4

4.2.4. Запуск резервного копирования по расписанию

Когда диск появляется в WSL, задача или другой планировщик (например, cron в WSL) запускает основной backup-скрипт (см. предыдущий раздел). Например, для автоматического запуска каждую ночь:

bash0 2 * * * sudo /home/backupuser/centos_backup.sh >> /var/log/centos_backup.log 2>&1

или через Windows-задачу по аналогии с вышеуказанной (планировщик командой wsl -d Ubuntu -- bash -c "sudo /home/backupuser/centos_backup.sh").

Важно знать

• Административные права обязательны: Подключение физического диска через wsl.exe --mount требует максимальных привилегий — задача должна запускаться с повышенными правами.
• nofail и systemd.device-timeout: Используйте параметры nofail,x-systemd.device-timeout=0 в fstab, чтобы избежать лишних предупреждений при отсутствии устройства в момент загрузки.
• Мониторинг отказов: Желательно включать логирование всех стадий резервирования: как этапа подключения, так и самого процесса бэкапа для быстрого выявления аномалий.
• VHDX как альтернатива: Вместо физического диска можно использовать VHDX-образ, который также можно автоматически монтировать в WSL при старте системы — сценарий аналогичен, и во многом ещё более гибок.

---

Вывод:
Такая схема полностью устраняет ручные действия со стороны администратора, обеспечивает гарантированное появление Linux-диска внутри WSL и позволяет запускать резервное копирование действительно в автоматическом, промышленном режиме. Это критически важно для моделей “pull” и для долгосрочной надёжности инфраструктуры резервного копирования с использованием Windows- и Linux-решений одновременно.4.

5. Проверка восстановления и важные замечания

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

• Проверка целостности: Вы можете периодически выбирать один из бэкапов и сравнивать с текущими данными или пытаться восстановить на тестовую машину. Особенно важно проверять дампы баз данных (можно ли их импортировать без ошибок).
• Восстановление файлов: Чтобы восстановить конкретный файл, вы можете на Windows через проводник зайти в \\wsl$\Ubuntu\mnt\backup\backup.RSYNC\<Дата>\... и скопировать файл. Либо в WSL смонтировать куда-то CIFS шару, либо передать по SCP обратно. Структура каталогов такая же, как была на CentOS, от корня.
• Восстановление всей системы: При выходе из строя сервера CentOS, вы можете установить заново OS и затем скопировать содержимое нужного снимка поверх (учитывая что некоторые спец. директории как /proc, /sys, /dev не копировались – их создаст ОС). Права и владельцы при копировании из EXT4 будут сохранены. Если NTFS – тоже, при условии что использовали опцию metadata или восстанавливаете через rsync.

Замечание по жёстким ссылкам: Windows проводник не показывает явно, что два файла – это одна физическая копия (NTFS Hard Link). Но на EXT4 через WSL можно увидеть, что у файлов одинаковый номер inode. На NTFS тоже можно это узнать через fsutil или через WSL (inode эмулируется). Главное, не удаляйте произвольно файлы внутри старых снимков вручную – это может разорвать цепочку ссылок. Удалять целиком старые снимки можно без опасений – файлы, на которые не осталось ссылок, реально освободят место.

6. Заключение

Мы организовали надёжную систему инкрементального бэкапа для CentOS 6 с сохранением на Windows 11, использовав возможности WSL для преодоления несовместимостей между Unix и Windows средами. Решение включает в себя:

• Использование EXT4-диска на Windows (через WSL) для нативной поддержки Unix-атрибутов и ссылок.
• Перенос логики резервного копирования на сторону Windows (pull-модель) для повышения безопасности.
• Настройку скрипта на баше с понятной структурой, комментариями и расширяемостью. Скрипт не только копирует файлы, но и обслуживает дампы баз данных, архивы конфигураций и может вести лог изменений.
• Инструкции по автоматизации, чтобы бэкап выполнялся регулярно без участия человека.

Подход, описанный выше, аналогичен работе профессионального системного администратора, и учитывает большинство возможных подводных камней:
правильное монтирование дисков, сохранение прав доступа, использование жёстких ссылок для экономии места, защита бэкапа от потенциальных угроз, а также ротацию данных (сохранение предыдущих версий дампов, удаление старых binlog). Мы предусмотрели даже мелочи, вроде очистки временных файлов и кэшей для минимизации лишнего трафика и нагрузки во время резервирования.

После реализации этого решения у вас будет система резервного копирования, способная эффективно хранить долгосрочные снимки вашего сервера на Windows-машине. Каждая дата – как полная копия, но фактически дисковое пространство используется оптимально. Не забывайте следить за доступным местом на диске B: и периодически очищать очень старые снимки, если они больше не нужны. Удалить устаревший снимок можно просто удалив соответствующую папку с датой – благодаря структуре hard-link это освободит только те блоки, которые не используются никаким другим снимком.

Надеемся, эта инструкция поможет вам настроить резервное копирование правильно. В случае возникновения вопросов (например, при обновлении ОС или переносе на другой сервер), вы всегда можете адаптировать данный скрипт – благодаря тому, что он написан на bash с комментариями, его логика будет понятна даже спустя время. Успехов в администрировании и пусть ваши данные всегда будут в сохранности!