В процессе создания кластера стал вопрос: чем же можно обеспечить синхронизацию файлов и папок на отдельных узлах? После недолгих поисков всевозможных готовых решений наткнулся на известную утилиту, работающую под Unix – Rsync. У многих администраторов появилась необходимость синхронизировать каталоги между Unix-Windows серверами. Так получил жизнь проект cwRsynс. Суть этого проекта в том, что утилита Rsync запускается под Windows с помощью библиотеки cygwin.
В моем случае возможность взаимодействия с Unix серверами в перспективе очень радовала. Также отзывы админов о работе Rsync под Unix были очень положительными, и я решил попробовать.
В этой статье мы рассмотрим каким образом настраивается синхронизация жесткого диска с помощью cwRsynс.
В процессе создания кластера стал вопрос: чем же можно обеспечить синхронизацию файлов и папок на отдельных узлах? После недолгих поисков всевозможных готовых решений наткнулся на известную утилиту, работающую под Unix – Rsync. У многих администраторов появилась необходимость синхронизировать каталоги между Unix-Windows серверами. Так получил жизнь проект cwRsynс. Суть этого проекта в том, что утилита Rsync запускается по Windows с помощью библиотеки cygwin.
В моем случае возможность взаимодействия с Unix серверами в перспективе очень радовала. Также отзывы админов о работе Rsync под Unix были очень положительными, и я решил попробовать.
В этой статье мы рассмотрим каким образом настраивается синхронизация жесткого диска с помощью cwRsynс. Русскоязычных статей по работе с cwRsync я не нашел – все дружно копируют четыре шага по установке, и не касаются работы и настройки. Основную массу информации я черпал из http://rsync.samba.org, ведь параметры запуска для Rsync и cwRsync остаются одинаковыми.
Принцип синхронизации с помощью cwRsync состоит в следующем: на главном сервере (в нашем случае Сервер№1) запускается демон cwRsync при старте системы. В конфиге указывается к каким ресурсам будет даваться доступ. Клиент конфигурируется на втором сервере (Сервер№2). С определенной периодичностью на втором сервере запускается клиент, который соединяется с сокетом первого сервера, после чего происходит синхронизация. Взаимодействие происходит по локальным IP адресам:
1. Установка cwRsync.
Для начала необходимо скачать и установить утилиту cwRsync. Установщик можно скачать отсюда.
Нужно выбрать последнюю версию. Перед установкой стоит убедиться, что совместима с конфигами старой версии.
Нам необходимо установить его на все узлы кластера. Процесс установки совсем прост: все значения можно оставить по умолчанию. cwRsync установиться в c:\Program Files\cwRsync\.
После установки можно выполнить следующие рекомендации:
Панель управления -> Система -> Дополнительно -> Переменные окружения
• Решите проблему с не-ascii символами. Т.е. нужно с www.okisoft.co.jp/esc/utf8-cygwin/ скачать файл cygwin.dll и заменить им тот, что идет в комплекте с cwRsync.
• Для того чтобы файлы с не-ascii смволами в имене нормально передавались, добавте —iconv=. в опции при вызове rsync.
У меня после установки проблем с кодировкой либо работой не наблюдалось. Также далее при конфигурировании я использовал прямые пути. Поэтому рекомендации можно не выполнять.
2. Работа с cwRsync на Сервер№1:
Для начала необходимо создать конфиг. файл. Создадим в c:\Program Files\cwRsync\bin\ папки conf и log. В папке conf создадим файл rsyncd.conf следующего содержания:
#### rsyncd.conf file ####
uid = user_id
gid = user_id
use chroot = false # Даём разрешение использовать все диски а не только C. Если мы
# установим в true, то rsync сможет обращатся только к диску С.
hosts allow = 192.168.1.6 # Разрешаем обращаться только с Сервер№2
[drive_c] # Метка диска С
path = /cygdrive/c/
comment = this is system drive
read only = true
[drive_d] #Метка диска Д
path = /cygdrive/d/
comment = this is date drive
read only = true
#transfer logging = yes
#### End of configuration file ####
use chroot = yes – запуск rsync в chroot, для пущей безопасности;
[drive_с] – название модуля;
uid – должен соответствовать id владельца каталога, в который мы собираемся записывать;
path – полный путь до каталога, в который будем записывать;
list = no – не показывать секцию [push] в листинге;
comment – комментарий;
read only = false – открыть секцию на запись;
hosts allow – разрешить доступ к секции push только для определённых адресов;
auth users = push – разрешить доступ только пользователю push;
secrets file – файл соответствия имени пользователя определённому паролю.
Примечание:
2009/01/06 13:27:35 [3748] name lookup failed for 127.0.0.1: Unknown server error
2009/01/06 13:27:35 [3748] connect from UNKNOWN (127.0.0.1)
2009/01/06 13:27:35 [3748] rsync: chdir / failed
: No such file or directory (2)
Зато когда указываешь имя папки в параметрах клиента, то всё работает.
Далее создадим bat файлы для запуска демона: создадим в папке conf файл rsync_server_start.bat с таким содержимым:
«C:\Program Files\cwRsync\bin\rsync.exe» —config «C:\Program Files\cwRsync\bin\conf\rsyncd.conf» —daemon —log-file «C:\Program Files\cwRsync\bin\log\rsyncservice.log» —address 192.168.1.5
—config rsyncd.conf – указываем, где находится файл конфигурации.
—daemon – запуск демона
—log-file – включение ведения лога
—address – указываем , какой адрес слушать
Полный перечень возможных параметров:
—daemon run as an rsync daemon
—address=ADDRESS bind to the specified address
—bwlimit=KBPS limit I/O bandwidth; KBytes per second
—config=FILE specify alternate rsyncd.conf file
—no-detach do not detach from the parent
—port=PORT listen on alternate port number
—log-file=FILE override the «log file» setting
—log-file-format=FMT override the «log format» setting
—sockopts=OPTIONS specify custom TCP options
-v, —verbose increase verbosity
-4, —ipv4 prefer IPv4
-6, —ipv6 prefer IPv6
-h, —help show this help (if used after —daemon)
После запуска демона появится окно Windows Firewall и процесс в менеджере задач.
Необходима нажать Unblock. Если всё работает нормально, то нужно добавить запуск bat файла в Планировщик Задач:
Таким образом, сервер cwRsync будет запускаться при старте узла.
3. Работа с cwRsync на Сервер№2:
Установим cwRsync на Сервер№2. Создадим в c:\Program Files\cwRsync\bin\ папки bat и log. В папке bat создадим следующий файл с именем sync_all.bat. В этом файле создадим записи для синхронизации каждой необходимой папки. Следует включать исключения для папок с логами и статистикой. Вот общий вид строки.
«C:\Program Files\cwRsync\bin\rsync.exe» -av —delete —exclude ‘/logs/’ [email protected]::drive_c/Folder1/ «/cygdrive/c/Folder1/»>»C:\Program Files\cwRsync\bin\log\Folder1.log»
Необходимо сформировать подобные строки для каждой папки, и указывать их одна за одной в этом файле.
Примечание:
Каждая запись состоит из следующих частей
-a равносильно –rlptgoD
r — рекурсивный режим
l — пересоздание symlinks, это значит, что символические ссылки будут так же переноситься
p – перенос прав
t — передача времени модификации и его обновление на удаленной системе. Этот ключ должен быть установлен для точной синхронизации
g — установить группу конечного файла таким же, как и у исходного
o — установить владельца конечного файла таким же, как и у исходного
v — verbose. Вывод сообщений в терминал.
—delete — удаляет файлы, которых нет в источнике.
—exclude – указываем то, что синхронизировать не нужно.
user_id – uid, описанный на сервере
@192.168.1.5 – IP адрес сервера
::drive_d /Folder_sync1/ – Метка сервера и путь
«/cygdrive/d/Folder_sync1/» — куда
>»C:\Program Files\cwRsync\bin\log\Folder_sync1.log» — весь вывод в файл
Обратите внимание на последний слеши в путях, так как они имеют значение для rsync. Если на конце исходной директории стоит «/», то это означает копирование содержимого директории; отсутствие слеша означает копирование директории и ее содержимого.
Если не указать /, то на клиент в папке создастся папка с файлами. Иначе просто её содержимое.
При первом запуске синхронизации на Cервер№2, также появится сообщения от брандмауэра Windows о блокировании Rsync. Необходимо нажать Unblock.
Вот список всех допустимых параметров:
-v, —verbose increase verbosity
-q, —quiet suppress non-error messages
—no-motd suppress daemon-mode MOTD (see caveat)
-c, —checksum skip based on checksum, not mod-time & size
-a, —archive archive mode; equals -rlptgoD (no -H,-A,-X)
—no-OPTION turn off an implied OPTION (e.g. —no-D)
-r, —recursive recurse into directories
-R, —relative use relative path names
—no-implied-dirs don’t send implied dirs with —relative
-b, —backup make backups (see —suffix & —backup-dir)
—backup-dir=DIR make backups into hierarchy based in DIR
—suffix=SUFFIX backup suffix (default ~ w/o —backup-dir)
-u, —update skip files that are newer on the receiver
—inplace update destination files in-place
—append append data onto shorter files
—append-verify —append w/old data in file checksum
-d, —dirs transfer directories without recursing
-l, —links copy symlinks as symlinks
-L, —copy-links transform symlink into referent file/dir
—copy-unsafe-links only «unsafe» symlinks are transformed
—safe-links ignore symlinks that point outside the tree
-k, —copy-dirlinks transform symlink to dir into referent dir
-K, —keep-dirlinks treat symlinked dir on receiver as dir
-H, —hard-links preserve hard links
-p, —perms preserve permissions
-E, —executability preserve executability
—chmod=CHMOD affect file and/or directory permissions
-A, —acls preserve ACLs (implies -p)
-X, —xattrs preserve extended attributes
-o, —owner preserve owner (super-user only)
-g, —group preserve group
—devices preserve device files (super-user only)
—specials preserve special files
-D same as —devices —specials
-t, —times preserve modification times
-O, —omit-dir-times omit directories from —times
—super receiver attempts super-user activities
—fake-super store/recover privileged attrs using xattrs
-S, —sparse handle sparse files efficiently
-n, —dry-run perform a trial run with no changes made
-W, —whole-file copy files whole (w/o delta-xfer algorithm)
-x, —one-file-system don’t cross filesystem boundaries
-B, —block-size=SIZE force a fixed checksum block-size
-e, —rsh=COMMAND specify the remote shell to use
—rsync-path=PROGRAM specify the rsync to run on remote machine
—existing skip creating new files on receiver
—ignore-existing skip updating files that exist on receiver
—remove-source-files sender removes synchronized files (non-dir)
—del an alias for —delete-during
—delete delete extraneous files from dest dirs
—delete-before receiver deletes before transfer (default)
—delete-during receiver deletes during xfer, not before
—delete-delay find deletions during, delete after
—delete-after receiver deletes after transfer, not before
—delete-excluded also delete excluded files from dest dirs
—ignore-errors delete even if there are I/O errors
—force force deletion of dirs even if not empty
—max-delete=NUM don’t delete more than NUM files
—max-size=SIZE don’t transfer any file larger than SIZE
—min-size=SIZE don’t transfer any file smaller than SIZE
—partial keep partially transferred files
—partial-dir=DIR put a partially transferred file into DIR
—delay-updates put all updated files into place at end
-m, —prune-empty-dirs prune empty directory chains from file-list
—numeric-ids don’t map uid/gid values by user/group name
—timeout=SECONDS set I/O timeout in seconds
—contimeout=SECONDS set daemon connection timeout in seconds
-I, —ignore-times don’t skip files that match size and time
—size-only skip files that match in size
—modify-window=NUM compare mod-times with reduced accuracy
-T, —temp-dir=DIR create temporary files in directory DIR
-y, —fuzzy find similar file for basis if no dest file
—compare-dest=DIR also compare received files relative to DIR
—copy-dest=DIR … and include copies of unchanged files
—link-dest=DIR hardlink to files in DIR when unchanged
-z, —compress compress file data during the transfer
—compress-level=NUM explicitly set compression level
—skip-compress=LIST skip compressing files with suffix in LIST
-C, —cvs-exclude auto-ignore files in the same way CVS does
-f, —filter=RULE add a file-filtering RULE
-F same as —filter=’dir-merge /.rsync-filter’
repeated: —filter=’- .rsync-filter’
—exclude=PATTERN exclude files matching PATTERN
—exclude-from=FILE read exclude patterns from FILE
—include=PATTERN don’t exclude files matching PATTERN
—include-from=FILE read include patterns from FILE
—files-from=FILE read list of source-file names from FILE
-0, —from0 all *from/filter files are delimited by 0s
-s, —protect-args no space-splitting; wildcard chars only
—address=ADDRESS bind address for outgoing socket to daemon
—port=PORT specify double-colon alternate port number
—sockopts=OPTIONS specify custom TCP options
—blocking-io use blocking I/O for the remote shell
—stats give some file-transfer stats
-8, —8-bit-output leave high-bit chars unescaped in output
-h, —human-readable output numbers in a human-readable format
—progress show progress during transfer
-P same as —partial —progress
-i, —itemize-changes output a change-summary for all updates
—out-format=FORMAT output updates using the specified FORMAT
—log-file=FILE log what we’re doing to the specified FILE
—log-file-format=FMT log updates using the specified FMT
—password-file=FILE read daemon-access password from FILE
—list-only list the files instead of copying them
—bwlimit=KBPS limit I/O bandwidth; KBytes per second
—write-batch=FILE write a batched update to FILE
—only-write-batch=FILE like —write-batch but w/o updating dest
—read-batch=FILE read a batched update from FILE
—protocol=NUM force an older protocol version to be used
—iconv=CONVERT_SPEC request charset conversion of filenames
—checksum-seed=NUM set block/file checksum seed (advanced)
-4, —ipv4 prefer IPv4
-6, —ipv6 prefer IPv6
—version print version number
(-h) —help show this help (see below for -h comment)
После этого необходимо добавить бат файл в Планировщик Задач с запуском через каждые 10-20 минут либо другой, необходимый промежуток времени.
Глупый вопрос
Здравствуйте, уважаемый Xetrix! У меня имеется 2 сервера, на обоих ОС Windows Server 2003. Требуется синхронизировать содержимое нужных папок с помощью cwRsync. При этом возникает проблема: для синхронизации требуется в конфигурационном файле нужны uid и gid. Что нужно указать в gid для Windows-систем, чтобы все правильно работало?
uid — имеется в виду «user id», а gid — «group id». У себя везде я их указываю одинаковыми. после их установки при работе сервера будут допускаться только клиенты, у которых будет в конфиге указан соответствующий «user id».
Например в конфиге сервера:
при запуске клиента:
ну гдето так…отвечу на любые вопросы..:)
Все-таки, наверное, глупый вопрос:)
Что такое gid и uid вроде знаю, так как синхронизацию между Windows и Linux настроил, однако там демон RSync’а запускался на Linux. В cwRsync же демон запускается на Windows, для которого понятие gid и uid немного не подходят…
В общем, делал так: на сервере TESTSERV1 под пользователем Administrator запускаем сервер cwRsync, в конфиге прописывалось
uid=Administrator
gid=Administrator
Тогда при запуске с клиента возникает ошибка:
C:\Documents and Settings\Administrator>»C:\Program Files\cwRsync\bin\rsync.exe»
-av -n [email protected].1::mod/ «/cygdrive/c/Folder1/»
@ERROR: invalid gid Administrator
rsync error: error starting client-server protocol (code 5) at main.c(1506) [Receiver=3.0.7]
Если же на сервере оставляем пользователя Administrator, и чуть-чуть меняем конфиг
uid=test
gid=test
то вполне ожидаемо получаем ошибку соединения:
C:\Documents and Settings\Administrator>»C:\Program Files\cwRsync\bin\rsync.exe»
-R -n -av -v «/cygdrive/c/Folder1/» [email protected].1::mod/
opening tcp connection to 192.168.231.1 port 873
rsync: failed to connect to 192.168.231.1: Connection timed out (116)
rsync error: error in socket IO (code 10) at clientserver.c(122) [sender=3.0.7]
Что я сделал не так?
re2: совсем не глупый вопрос… :))
ну сразу оговорюсь: под линуксе не бум-бум…слыхал что есть возможность синхронизации Windows — Linux и всё…Сам же этого не пробовал ещё…
Может это из за того, что у тебя в [email protected].1::mod две буквы t стоит? ;)))
Я посмотрел конфиги для RSync у админов, так у них указано в uid и gid на демоне существующий пользователь и группа, а не как я — от фонаря написал… Клиент вообще без указания пользователя запускается в виде «»C:\Program Files\cwRsync\bin\rsync.exe» -av -n 192.168.231.1::mod/ …»
Т.е. при запуске демона в uid и gid мы указываем пользователя, от чьего имени запускается демон. а клиенту побоку кто там запускается..он обращается и берёт всё что просит..Это мне так наш админ рассказал..
Хорошо бы увидеть весь твой конфиг демона. Да и я немного не понял: Демон у тебя под Linux запущен, а клиент на Windows? тогда по идее нужно uid и gid указать существующих на Linux пользователя и группу (причём у них права должны быть в папку синхронизации), а при запуске клиента попробовать либо ничего не указать либо пользователя из uid..
Решение найдено
Как оказалось, все просто: при запуске сервера cwRsync для windows-систем в качестве параметров в конфиге необходимо указать в качестве uid — имя пользователя, под которым запускается демон, в качестве gid — 0.
uid=Administrator
gid=0
Также проходит такая связка:
uid=0
gid=0
Ну и запускать синхронизацию на клиенте можно так:
«C:\Program Files\cwRsync\bin\rsync.exe» -av -n 192.168.231.1::mod/ «/cygdrive/c/Folder1/»
или вот так:
«C:\Program Files\cwRsync\bin\rsync.exe» -av -n [email protected].1::mod/ «/cygdrive/c/Folder1/»
Наткнулся на свою же ошибку в конфиге сервера cwRsync…
С недавнего времени у себя на работе использую cwRsync для бекапирования проектов с тестового сервера. На этом сервере у нас хранятся полные копии проектов, все правки я сначала делаю на нём, а потом переношу на публичный сервер. Хотя у тестового сервера и рейд есть и он регулярно бекапится сам, подумал, будет нелишне закачивать все наработки ежедневно себе локально.
Недавно столкнулся с тем, что заветных бекапов последнего дня не было…Файлы старые очень были. Залез на сервер в логи, а там:
И этим весь лог забит. Проверил конфиг, записи о разрешении всех моих IP адресов были в таком виде (так НЕПРАВИЛЬНО ):
Я иногда прыгаю на разные IP адреса и просмотрев логи rSync заметил что иногда синхронизация проходит, когда я сижу на 192.168.1.124.
Потом залез в документацию по rSync и поржал с своей необразованности — ПРАВИЛЬНО перечислять хоcты так:
После перезагрузки демона с сохранением нового конфига синхронизация пошла как по маслу..
Проблемы с русскими буквами
Указанная вами ссылка на патч http://www.okisoft.co.jp/esc/utf8-cygwin/ файл cygwin.dll недоступна, далее вы пишете что можно использовать прямые пути но далее ни где эти пути не упоминаются.
Как решить проблему с русскими именами файлов?
«Также далее при конфигурировании я использовал прямые пути. Поэтому рекомендации можно не выполнять.» — это относится к рекомендации » • Добавте $CYGWIN_INSTALL_PATH/bin/ в переменную окружения PATH» …т.е. я без переменной PATH обошелся.
По поводу «http://www.okisoft.co.jp/esc/utf8-cygwin/ недоступна» — так и есть…Нашел ту dll, которую качал когда-то, качать тут:
https://itnotes.org.ua/files/download/cygwin1-dll-20-11-18.tar.bz2
Единственное — не проверял её пока, как появится минутка — проверю, отпишусь.
Но учтите — древняя версия. Ну и к тому же пока я проблем с тем cygwin, который при установке ставится, не замечал.
Проверил..
только что проверил на «rsync Updated: 28 Dec 2008». Синхронизация файлов между серверами Windows. Стандартный cygwin.dll при синхронизации названия русские не портит — нормально отрабатывает. Я заменил его на тот cygwin1.dll, что выложил для скачки — никаких изменений, всё также превосходно работает.
Ну проблемы обычно возникают при синхронизации между серверами Windows — Linux. Кто попробует — отпишитесь, работает ли?
Пара советов
также на форумах советуют в случае синхронизации Windows — Linux для решения проблемы с русскими названиями:
«В rsyncd.conf на сервере включить опцию
charset = _локальная_кодировка_
А с Windows-машины в команде использовать
опцию —iconv=CP1251,UTF-8 (в моём случае на
сервере Linux юникод-кодировка)»
Но я сам не проверял…
Простите за глупый вопрос, но
Простите за глупый вопрос, но «drive_c/Folder1/» равнозначно «C:/Folder1», а «/cygdrive/» = «C:\Program Files\cwRsync\bin» ? или как это воспринимать?! Заранее спасибо!
Нет, вы всё перепутали 🙂
«drive_c» — в нашем случае это псевдоним на сервере для диска C:\, ну а путь «drive_c/Folder1/» является «C:\Folder1\» для Windows.
/cygdrive/ — тут сложнее…Насколько я понял, это корень диска, который сделан под windows для доступа к дискам на манер Linux. Я могу и ошибаться, но очень похоже. Куда он ссылается по умолчанию не знаю. Но к разделам диска Windows можно добраться только через cygdrive. Т.е. «/cygdrive/с/» является диском «C:/».
Тут важно понимать, что cwRsync это старый добрый Rsync под Linux, который заставили работать под Windows, поэтому пути в конфигах и командной строке задаются немного непривычно для Windows пользователей..