Синхронизация файлов между Windows серверами RSync

В процессе создания кластера стал вопрос: чем же можно обеспечить синхронизацию файлов и папок на отдельных узлах? После недолгих поисков всевозможных готовых решений наткнулся на известную утилиту, работающую под Unix – Rsync. У многих администраторов появилась необходимость синхронизировать каталоги между Unix-Windows серверами. Так получил жизнь проект cwRsynс. Суть этого проекта в том, что утилита Rsync запускается по Windows с помощью библиотеки cygwin.

В моем случае возможность взаимодействия с Unix серверами в перспективе очень радовала. Также отзывы админов о работе Rsync под Unix были очень положительными, и я решил попробовать.

В этой статье мы рассмотрим каким образом настраивается синхронизация жесткого диска с помощью cwRsynс. Русскоязычных статей по работе с cwRsync я не нашел – все дружно копируют четыре шага по установке, и не касаются работы и настройки. Основную массу информации я черпал из http://rsync.samba.org, ведь параметры запуска для Rsync и cwRsync остаются одинаковыми.

Принцип синхронизации с помощью cwRsync состоит в следующем: на главном сервере (в нашем случае Сервер№1) запускается демон cwRsync при старте системы. В конфиге указывается к каким ресурсам будет даваться доступ. Клиент конфигурируется на втором сервере (Сервер№2). С определенной периодичностью на втором сервере запускается клиент, который соединяется с сокетом первого сервера, после чего происходит синхронизация. Взаимодействие происходит по локальным IP адресам:

Пример: Схема синхронизации cwRsync.

1. Установка cwRsync.
Для начала необходимо скачать и установить утилиту cwRsync. Установщик можно скачать отсюда.

Нужно выбрать последнюю версию. Перед установкой стоит убедиться, что совместима с конфигами старой версии.
Нам необходимо установить его на все узлы кластера. Процесс установки совсем прост: все значения можно оставить по умолчанию. cwRsync установиться в c:\Program Files\cwRsync\.

После установки можно выполнить следующие рекомендации:

У меня после установки проблем с кодировкой либо работой не наблюдалось. Также далее при конфигурировании я использовал прямые пути. Поэтому рекомендации можно не выполнять.

2. Работа с cwRsync на Сервер№1:
Для начала необходимо создать конфиг. файл. Создадим в c:\Program Files\cwRsync\bin\ папки conf и log. В папке conf создадим файл rsyncd.conf следующего содержания:

Примечание:

Зато когда указываешь имя папки в параметрах клиента, то всё работает.

Далее создадим bat файлы для запуска демона: создадим в папке conf файл rsync_server_start.bat с таким содержимым:

Полный перечень возможных параметров:

После запуска демона появится окно Windows Firewall и процесс в менеджере задач.

Windows Firewall: Блокирование rsync демона.

Необходима нажать Unblock. Если всё работает нормально, то нужно добавить запуск bat файла в Планировщик Задач:

Планировщик задач: Запуск демона cwRsync при старте сервера.

Таким образом, сервер cwRsync будет запускаться при старте узла.

3. Работа с cwRsync на Сервер№2:
Установим cwRsync на Сервер№2. Создадим в c:\Program Files\cwRsync\bin\ папки bat и log. В папке bat создадим следующий файл с именем sync_all.bat. В этом файле создадим записи для синхронизации каждой необходимой папки. Следует включать исключения для папок с логами и статистикой. Вот общий вид строки.

Необходимо сформировать подобные строки для каждой папки, и указывать их одна за одной в этом файле.

Примечание:

Каждая запись состоит из следующих частей

Обратите внимание на последний слеши в путях, так как они имеют значение для rsync. Если на конце исходной директории стоит «/», то это означает копирование содержимого директории; отсутствие слеша означает копирование директории и ее содержимого.
Если не указать /, то на клиент в папке создастся папка с файлами. Иначе просто её содержимое.
При первом запуске синхронизации на Cервер№2, также появится сообщения от брандмауэра Windows о блокировании Rsync. Необходимо нажать Unblock.
Вот список всех допустимых параметров:

Rsync для Windows — Резервное копирование файлов rsync

Резервное копирование rsync — изначально один из популярных алгоритмов синхронизации файлов и бэкапа для Unix-подобных систем, реализованный впоследствии и для Windows. Handy Backup использует алгоритм rsync копирования для проверки атрибутов, синхронизации файлов и папок и т.д.

Версия 8.2.3 от 29 марта 2021. 111 MB
30-дневный полнофункциональный пробный период

Технологии rsync в решении Handy Backup

Сравнение файлов и атрибутов

При помощи rsync резервное копирование и синхронизация данных в Handy Backup может осуществляться с учётом атрибутов файлов, их размера и т.д. (например, для извлечения более новых файлов или предотвращения копирования одинаковых данных).

Выполнение с помощью rsync инкрементального бэкапа

Алгоритм rsync для Windows и Linux используется Handy Backup в операциях смешанного, дифференциального и инкрементального копирования. При этом библиотека rsync Windows client вызывается напрямую, без обращения к внешним приложениям (встроена в Handy Backup).

Сетевой доступ

В отдельных случаях алгоритмы Windows rsync server применяются для получения сетевого доступа к удалённым машинам в решении Server Network. Например, это может быть необходимо для бэкапа Oracle с помощью RMAN, синхронизации сетевых папок и т.д.

Handy Backup Server Network

С помощью этой версии программы, Вы сможете управлять бэкапом удаленных рабочих станций по сети. Бесплатный полнофункциональный пробный период — 30 дней!

Преимущества использования rsync for Windows в Handy Backup

Использование алгоритмов и библиотек rsync копирования позволяет программе Handy Backup эффективнее распределять ресурсы системы, так как для копирования файлов rsync технология предоставляет массу хорошо отработанных возможностей. С помощью rsync бэкапа достигаются:

• Минимизация траффика (передачи данных) при rsync бэкапе по сети или синхронизации двух папок.
• Доступ к файлам на сетевых машинах, в т.ч. Unix-подобных ОС, через Windows rsync server.
• Оптимизация дополнительных операций, таких, как сравнение файлов и атрибутов.

Разработчики Handy Backup планируют дальнейшее расширение функций rsync бэкапа в новых версиях там, где это необходимо. В случаях, когда для rsync Windows настройка и использование оказываются недостаточно целесообразными, Handy Backup использует другие алгоритмы.

Вышеуказанный подход позволяет решениям Handy Backup использовать все преимущества rsync для Windows и Linux, избегая вместе с тем как возможных недостатков этой утилиты, так и слишком жёсткой привязки к единственному алгоритму копирования файлов.

Версия 8.2.3 от 29 марта 2021. 111 MB
30-дневный полнофункциональный пробный период

Автоматизированное резервное копирование рабочих станций Windows при помощи rsync и vshadow — Часть 1

Если у вас возникло желание поддерживать рабочие станиции в максимально «защищённом» состоянии, а так же насколько возможно «автоматизировать» этот процесс, то этот пост для вас.

Немного batch файла
Немного Linux сервера
Немного Windows Server 2008 R2 и Групповых политик

Идея в следующем — незаметно от самого юзера, чтобы не нарушать его работу, делать еженедельное копирование его профиля, дабы исключить потерю данных, и сохранять его на сервере в максимально защищённом виде.

Для этого начнём с клиентской части. Мы используем shadow volume create — expand, дабы исключить проблему нечитания открытых пользователем файлов, таких как Outlook pst, или документов. Нам понадобится набор от Microsoft, который содержит vshadow — это Volume Shadow Copy Service SDK 7.2, который можно бесплатно скачать с серверов Microsoft, http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23490.Нам понадобятся vshadow.exe и vshadow.pdb файлы из этого SDK. Внимание — они разные для 64-битных, и 32-битных систем.

После инсталляции их можно будет найти тут:

64-bit — %PROGRAMFILES%\Microsoft\VSSSDK72\TestApps\vshadow\bin\obj-chk\amd64
32-bit — %PROGRAMFILES%\Microsoft\VSSSDK72\TestApps\vshadow\bin\release-xp

После инсталляции их можно будет найти тут:

Складываем все файлы в одну папку, назовём её для удобства «Backup», и начинаем создавать файл, который будет запускать эту «машину смерти» — по факту, это простой batch файл, который будет отрабатывать все действия. Назовём его для удобства «backup.cmd»

setlocal
if NOT «%CALLBACK_SCRIPT%»==»» goto :IS_CALLBACK
set SOURCE_VOLUME=C:
set DESTINATION_VOLUME=O:
set CALLBACK_SCRIPT=%

dpnx0
set TEMP_GENERATED_SCRIPT=GeneratedVarsTempScript.cmd
%

dp0\vshadow.exe -nw -p -script=%TEMP_GENERATED_SCRIPT% -exec=%CALLBACK_SCRIPT% %SOURCE_VOLUME%
del /f %TEMP_GENERATED_SCRIPT%
goto :EOF
:IS_CALLBACK
setlocal
call %TEMP_GENERATED_SCRIPT%
%

Эта часть «макаронного кода» делает shadow volume copy с C: и подключает её на O:, который мы и будем использовать для копирования, а потом тем же скриптом уберём. Теперь часть, которая отвечает за действия rsync:

setlocal
SET CWRSYNCHOME=C:\Backup\ (где папка с файлами rsync и vshadow)
SET CWOLDPATH=%PATH%
SET CYGWIN=nontsec
SET PATH=%CWRSYNCHOME%;%PATH%
SET HOME=С:\Backup\LOG\ (сюда будем сохранять логи)
SET RSYNC_PASSWORD=(тут пароль, который установлен на принимающем сервере rsync)
SET MY_NAME=%computername%

(теперь указываем, что копировать)

SET FS_SRC_HOME=»/cygdrive/O/Users/» (используем именно в таком формате, указываем папку до «Users»)
SET FS_SRC_BCK=»/cygdrive/C/Backup/» (где файлы rsync, чтобы положить их вместе с логами на бекап сервер)

del /q С:\backup\log\*.log (стираем старые логи перед запуском)

rsync -av —chmod=ug=rwx %FS_SRC_B2% backupusr@hostname::sbackupusr/%MY_NAME%
rsync -avhP —inplace —stats —del —modify-window=1 —log-file=%FS_SRC_BCK%DATA/backupwork.log —exclude-from=%FS_SRC_BCK%DATA/exclude %FS_SRC_HOME% backupusr@hostname::sbackupusr/%MY_NAME%/snapshot/
rsync -av %FS_SRC_BCK% backupusr@hostname::sbackupusr/%MY_NAME%/snapshot/Backup/

Первой командой мы создаём директорию по имени компьютера %computername%
Второй командой мы копируем данные с временно подключенного диска O:\Users, с сохранением лог-файла.
Третьей командой мы копируем всю папку C:\Backup, для сохранности лога и самой программы.

Вот эта строка «backupusr@hostname::sbackupusr» — указывает на пользователя на принимающей стороне а так же хост принимающей стороны. (Будет рассмотрено во втором псто).

После этого нам необходимо отключить O: диск, так как если мы этого не сделаем, в следующий раз vshadow не сможет подключить туда копию, и копия будет делаться со старого O:\ диска всё время, не смотря на то, что файлы в папке пользователя уже давно изменились.

Это всё нужно сложить в обычный .cmd файл, как я уже указывал выше, сохранить его в папку Backup, где хранятся файлы rsync и vshadow, и запускать по мере надобности. Работает на Windows Vista, Windows 7, Windows XP, 32 и 64-bit

P.S: Конечно, будет необходимо поднять принимающую машину, в нашем случае на базе *nix, и создать разделы, которые будут защищены true-crypt в случае кражи сервера. Так же в дальнейшем эту папку можно запаковать в msi инсталлер для установки на все рабочие станции через Групповые Политики и использовать их же для создания Scheduled Tasks и закрытия доступа в Backup папку для юзера. Но это уже другая история.

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Microsoft закрыла 129 уязвимостей в июньском Patch Tuesday для Windows, включая уязвимость в редакторе групповых политик

Один из способов резервного копирования контейнера TrueCrypt

резервное копирование rsync-ом

Средняя зарплата в IT

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 12

Да, прошу прощения, я упустил момент фильтров. Нежелательные файлы указаны в файле /DATA/exclude, который отрабатывает вот в этом моменте —exclude-from=%FS_SRC_BCK%DATA/exclude. На данном моменте там содержатся следующие расширения:

Administrator
pagefile.sys
operator
Temporary Internet Files
Temp
cobian
$RECYCLE.BIN
System Volume Information
*.tmp
*.mp3
*.avi
*.temp
*.mpeg
*.mpg
*.wma
*.wmv
*.flac
*.ape

Да, этот момент рассматривается в данный момент с установкой SAN/NAS NexentaStor Community Edition, использовать Shared профили для пользователей и держать их на сервере

Да, Майкрософт позволяет использовать «Windows Backup» для этих целей. К сожалению, там есть ряд минусов. 1 — Нет возможности контролировать это через Групповые политики, можно только либо включить сервис, либо выключить. (Возможно это делать при помощи определенных команд, но этот вопрос дальше не разбирался), 2 — Windows Backup пишет всё в один .zip архив, который не так удобен для восстановления потерянных файлов и не позволит делать «Snapshots» по дням недели, которые мы используем сейчас на хосте, который принимает резервные копии, я это опишу в следующий раз

Этот список файлов некорректен, т.к. могут быть различного рода рабочие документации\презентации в видео формате (у нас немцы и французы любят такие документации докладывать к обычным pdf); так же можно переслать видео описание неисправности оборудования поставщику для более точного и быстрого диагноза; так же не подходит этот вариант, если у Вас в работе требуется обработка видео\звуков\картинок.

Вобще ограничение по типам файлов должно быть не на уровне железа, а на уровне человеческого сознания — сотрудник должен понимать, что он тут работает, а не живет, тогда проблем с мусором не возникает.

Что касается инструментов, которые предлагает Майкрософт:
В моем случае при приеме на работу есть политики, с которыми сотрудник должен ознакомиться, среди политик есть та, которая описывает каким образом и где пользователь должен хранить документы. В политике описывается, что если документы хранятся в правильном месте, то есть возможность самостоятельно сделать откат на любую дату в пределах последнего месяца (правой кнопокй мыши по нужному файлу —> properties —> previous version —> тадам), а так же с помощью сотрудников IT на любую дату в пределах последних 2-х лет. Достигается это простыми перемещаемыми профилями, и включенным теневым копированием нужных томов 2 раза в сутки, так же существует еженедельный и ежемесячный бэкап всего этого добра на внешние жесткие диски с ежемесячным складированием их в удаленный сейф. Причем сами бэкапы так же есть 2-х видов, 1 вид бэкапа создает только копии нужных томов с использованием теневого копирования, второй тип бэкапа создает образ живого сервера, опять же с использованием теневого копирования. Делается все автоматически, за исключением замены внешних жестких дисков, как ни крути, но приходится нажимать кнопочку для отключения диска, а потом кнопочку для включения диска — ответственный товарищ уже обучен и не ошибается. Раз в квартал делается проверка работоспособности бэкапа путем разворачивания его на отдельно стоящем компьютере.

Забудьте про Windows Backup, используйте Volume Shadow Copy Service (VSS).

Previous Versions включены и настроены на всех машинах в окружении по умолчанию, и уже не первый раз спасали пользователя, когда ему нужно было восстановить более свежий чем вчерашний бекап.

К сожалению, они не работают, когда у пользователя украли компьютер. Поэтому используется связка vshadow+rsync на хост, previous versions на рабочих станциях, + дополнительное ежедневное копирование на внешние носители, защищённые truecrypt либо bitlocker. Конечно, самая важная информация хранится на файловом сервере, который так же имеет резервные копии на том же backup сервере и внешних жёстких дисках.

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

Сгорел Hyper-V Host, на котором крутится AD, FS, WSUS, + BIND

Соответственно, FS недоступен. Как быстро вернуть его в рабочее состояние, если FS используется из трёх локаций, и необходим ежедневно? Просто!

Идём на backup хост, на котором стоит Rsync + SMB winbind krb5, и который подключен в домейн, меняем настройки самбы, делаем smb restart, и получаем полную копию FS, которая доступна по другому FQDN. Пользователи работают, все счастливы. Конечно, права получаются всем на всё. Но это лучше, чем два дня ждать новой материнской платы и блока питания, и не работать вообще. По приходу деталей — ставим сервер на место, делаем xcopy folder D:\Shares\Shared\ /S /D:D:DD-MM-2011 /Y, и получаем актуальную копию измененных файлов на родном FS.

Даунтайм — 5 минут.
Исключение головной боли — бесценно.

Резервное копирование может быть организовано у каждого по-своему. Если это сработает при восстанавлении данных из копии быстро и безопасно, минимизируя потери, спасая работу и время организации.

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

Соответственно Previous Version — функция не пользовательского компьютера, а сервера, на котором хранятся документы.

Правда если у пользователя украли копьютер, то это уже работа для СБ, т.к. его не должны украсть. С ноутбуками проще, т.к. используется шифрование с участием отпечатка пальца.

Тот вариант, который предлагается Вами был бы очень полезен в Windows 2000, т.к. начиная с 2003 и ХР актуальность такого способа вызывает очень большые сомнения.

Допустим, если Вам нужна просто актуальная копия данных на другом железе, в вашем случае это хост, на котором стоит (Rsync + SMB winbind krb5, и который подключен в домейн), то можно воспользоваться DFS с синхронизацией между 2,3,4. n серверами с ОДНОЙ общей ШАРОЙ, которая будет доступна каждому пользователю. В случае падения одного из серверов пользователь вобще ничего не заметит, у него даже адрес подключения шары не изменится, не нужно менять настройки самбы, не нужно перезапускать сервис, все просто работает.

Да, кстати, если у Вас Сгорел Hyper-V Host, на котором крутится AD, FS, WSUS, + BIND то, как минимум, Вам нужно будет поднять какой-нибудь контролер домена из того же бэкапа, иначе у Вас ни один пользователь не сможет авторизоваться. И возврат копии выывает сомнения, т.к. слетят права доступа к шарам, после чего Вам потребуется еще некоторое время потратить на восстановление прав доступа.

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

Я полностью с вами согласен. Но если мы поднимем глаза на название этого топика, то увидим, что он не называется «Лучший способ организовать пользовательские данные».

Если Domain Controller не работает, компьютер использует кешированную сессию, и юзер может зайти, проблема только будет в ДНС, но есть резервный. При возврате копии на место права получаются inherited с парента.

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

Да и данная дискуссия, как я уже говорил, иррелевантна, так мы с вами до Virtual Desktop Infrastructure дойдём