Rsync windows server настройка

Windows · September 28, 2024

Rsync is a powerful tool for synchronizing files and directories between two locations, whether on the same machine or across different machines. While it is commonly associated with Unix-like systems, it can also be configured to work on Windows. This article will provide a detailed configuration example for setting up a Windows Rsync backup server, which can be particularly useful for businesses and individuals looking to maintain data integrity and security.

Understanding Rsync

Rsync stands for “remote sync” and is widely used for backups and mirroring. It efficiently transfers and synchronizes files by only sending the differences between the source and the destination. This makes it an ideal choice for backup solutions, as it minimizes bandwidth usage and speeds up the backup process.

Prerequisites

• Windows operating system (Windows 10 or later is recommended)
• Rsync installed on the Windows machine
• Access to a command-line interface (Command Prompt or PowerShell)
• Network access to the target backup location

Installing Rsync on Windows

To use Rsync on Windows, you can install it through Cygwin or WSL (Windows Subsystem for Linux). Here, we will focus on the Cygwin method:

1. Download the Cygwin installer from the official website.
2. Run the installer and select the packages you want to install. Make sure to include the Rsync package.
3. Complete the installation process.

Configuring Rsync for Backup

Once Rsync is installed, you can configure it to act as a backup server. Below is a step-by-step guide to set up Rsync for backing up files from a local directory to a remote server.

Step 1: Create a Backup Directory

First, create a directory where you want to store your backups. For example:

mkdir C:backups

Step 2: Set Up SSH Access

Rsync typically uses SSH for secure data transfer. Ensure that you have SSH access to the remote server where you want to back up your files. You can use tools like PuTTY to generate SSH keys and configure access.

Step 3: Create a Backup Script

Create a batch file or a PowerShell script to automate the backup process. Below is an example of a simple batch script:

@echo off
setlocal

set SOURCE=C:pathtoyourdata
set DESTINATION=user@remote-server:/path/to/backup

rsync -avz --delete %SOURCE% %DESTINATION%

endlocal

This script will synchronize the contents of the specified source directory with the destination on the remote server. The options used are:

• -a: Archive mode, which preserves permissions and timestamps.
• -v: Verbose output, which provides detailed information during the transfer.
• -z: Compress file data during the transfer.
• --delete: Delete files in the destination that are no longer present in the source.

Step 4: Schedule the Backup

To automate the backup process, you can schedule the script to run at regular intervals using Windows Task Scheduler:

1. Open Task Scheduler and create a new task.
2. Set the trigger to your desired schedule (e.g., daily, weekly).
3. In the action, select “Start a program” and point it to your backup script.

Testing the Backup

Before relying on your backup solution, it is crucial to test it. Run the script manually to ensure that files are being transferred correctly and that the backup directory is populated as expected.

Conclusion

Setting up a Windows Rsync backup server can significantly enhance your data management strategy. By following the steps outlined above, you can create a reliable backup solution that minimizes data loss and ensures data integrity. For those looking for robust hosting solutions, consider exploring USA VPS Hosting options that can support your backup needs effectively.

Настройка и использование Rsync Server

Утилита rsync позволяет синхронизировать содержимое двух каталогов как для локальной системы, так и удаленных серверов. Это может использоваться как для резервного копирования, так и поддержания в актуальном состоянии нод кластера.

Использование Rsync Server позволит более тонко настроить работу утилиты и оптимизировать сам процесс синхронизации.

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

Установка и запуск

По умолчанию, утилита может быть не установлена в системе. Установка и последующий запуск выполняются следующими командами.

CentOS 8

yum install rsync rsync-daemon

CentOS 7

Ubuntu

apt-get install rsync

Открываем следующий файл:

Настройка

Открываем конфигурационный файл rsync:

И настраиваем его, примерно, следующим образом:

max connections = 10
exclude = lost+found/
dont compress = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2 *.rar *.7z *.mp3 *.jpg

[data1]
path = /data1/
comment = Public folders
read only = yes
list = yes
auth users = rsync_d1
secrets file = /etc/rsyncd.scrt
hosts allow = localhost 192.168.0.15 192.168.0.20
hosts deny = *

[data2]
uid = root
gid = root
path = /data2/
comment = Private folders
read only = yes
list = yes
auth users = rsync_d2, backup
secrets file = /etc/rsyncd.scrt
hosts allow = localhost 192.168.0.16 192.168.0.21
hosts deny = *

где первая группа параметров являются общими настройками:

а также каждый ресурс настраивается отдельно (в нашем примере data1 и data2):

Создаем файл для аутентификации:

rsync_d1:password1
rsync_d2:password2
backup:password3

* где rsync_d1:password1 — соответственно, пользователь rsync_d1 с паролем password1.

В целях безопасности, устанавливаем доступ только для владельца:

chmod 600 /etc/rsyncd.scrt

Перезапускаем сервис одной из команд:

systemctl restart rsyncd

service rsyncd restart

Добавляем порты в брандмауэр.

Запуск клиента

Проверка на локальном компьютере

Сначала выполним следующую команду на нашем сервере:

* данная команда выполнит синхронизацию нашего ресурса data1 с каталогом /tmp.

Проверка на удаленном компьютере

Устанавливаем rsync, если еще не установлен:

apt-get install rsync

* первая команда для CentOS, вторая — Ubuntu.

* где 192.168.0.5 — IP-адрес rsync сервера.

Пример готового скрипта для синхронизации папок

Скрипт довольно прост:

password_file=’/etc/rsyncd.scrt’
user=’opros’
ip=’192.168.0.15′
source=’data1′
destination=’/tmp/’

После создаем файл с паролем:

* в данном файле указываем только пароль без имени учетной записи.

После задаем права:

chmod 600 /etc/rsyncd.scrt

Автоматизировать синхронизацию можно с помощью CRON:

0 */1 * * * /scripts/syncing.sh

* где /scripts/syncing.sh — наш скрипт. В данном примере задание будет выполняться каждый час.

Ключи запуска rsync

Список и описание опций:

* самый свежий список ключей rsync можно посмотреть командой man rsync.

Rsync на Windows

Реализация rsync для Windows носит название cwRsync (не является аналогом программы — по сути, это утилита Rsync + библиотека Cygwin). Скачать ее можно на официальном сайте. Для загрузки доступны платная и бесплатная версии. Последняя не позволит поднять Rsync-сервер, получать поддержку, обновления безопасности и возможность работать в графическом интерфейсе.

Запуск в качестве сервера

Мы будем использовать бесплатную поставку для поднятия сервера. Переходим на страницу загрузки backuppc и дожидаемся скачивание архива. Создаем в корне системного диска папку, например, C:\Rsyncd, распаковываем содержимое загруженного архива в созданную папку.

Находим в корне содержимого файл rsyncd.conf и открываем его в блокноте. Добавляем следующие строки:

[data1]
path = /cygdrive/d/backup
read only = false
transfer logging = yes

[data2]
path = /cygdrive/d/Папки пользователей
read only = false
transfer logging = yes
strict modes = false
auth users = home
secrets file = /cygdrive/c/Rsyncd/rsyncd.secrets

Регистрируем rsync в качестве службы — для этого открываем командную строку от администратора и выполняем команду:

* где c:\rsyncd или /cygdrive/c/rsyncd — каталог, куда мы распаковали скачанный архив.

Теперь открываем службы Windows, и находим зарегистрированную службу RsyncServer. Кликаем по ней правой кнопкой и выбираем Запустить:

Пробуем выполнить локальную синхронизацию. В командной строке переходим в каталог установки rsync:

* данная команда синхронизирует содержимое модуля data1 (в нашей настройке это папка D:\backup) в папку C:\Temp (если ее нет, нужно создать перед выполнением команды).

Или в обратном направлении:

Запуск клиента

Процедура использования клиента cwRsync аналогична описанному выше для Linux. Скачиваем архив программы и распаковываем его. Запускаем командную строку и переходим в каталог bin (находится в папке, куда была распакована программа).

* обратите внимание на путь назначения — чтобы обратиться к диску C мы написали /cygdrive/c. Итоговое назначение — C:\temp.

Копирование с помощью SSH:

* обратите внимание, что мы пишем не ssh, а ./ssh, иначе, если мы используем 64-х битную систему и бесплатный пакет cwRsync, система не найдет путь до ssh и выдаст ошибку Failed to exec ssh: No such file or directory.

Права на папки и файлы

Rsync в Windows не умеет копировать права для файлов и папок. В результате, мы получим либо копию с неправильными ACL-правами, либо они будут назначены неправильно (права будут выданы по хаотичному алгоритму). Чтобы решить данную проблему после клонирования, можно воспользоваться утилитой robocopy — она входит в состав Windows, начиная с 7-ки.

Команда, которая позволит выполнить исправление прав:

robocopy c:\test d:\backup /MIR /SEC /SECFIX

* в данном примере мы возьмем папку c:\test в качестве источника и отзеркалируем его d:\backup. Ранее скопированные данные не будут копироваться вновь, но будут исправлены права.

Примеры использования rsync

Простая команда для синхронизации двух каталогов:

Команда для резервного копирования:

Выполнение синхронизации по SSH:

* по SSH запросы идут не через rsync server. В данном примере подключение будет выполнено по 22 порту, под учетной записью user.

Копирование файлов на удаленную машину:

Синхронизация в обе стороны (запускаем две команды по очереди):

Синхронизация файлов по маске:

* в этом примере будут синхронизированы только файлы с расширением txt.

Возможные проблемы

rsync: change_dir «/» failed: Permission denied

Причина: нет прав на синхронизируемые файлы.

Решение: задать правильного пользователя (uid) в настройках ресурса на стороне сервера.

rsync: failed to connect to x.x.x.x (x.x.x.x): No route to host (113)
rsync error: error in socket IO (code 10) at clientserver.c(122)

Причина: не доступен удаленный хост.

Решение: проверить, что хости доступен по сети. Проверить настройку брандмауэра.

Источник

cwRsync — cинхронизация файлов между Windows серверами с примерами.

В процессе создания кластера стал вопрос: чем же можно обеспечить синхронизацию файлов и папок на отдельных узлах? После недолгих поисков всевозможных готовых решений наткнулся на известную утилиту, работающую под 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 адресам:

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

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

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

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

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

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 – файл соответствия имени пользователя определённому паролю.

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

—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 и процесс в менеджере задач.

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

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

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

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

cwRsync — cинхронизация файлов между Windows серверами с примерами.: 12 комментариев

Здравствуйте, уважаемый Xetrix! У меня имеется 2 сервера, на обоих ОС Windows Server 2003. Требуется синхронизировать содержимое нужных папок с помощью cwRsync. При этом возникает проблема: для синхронизации требуется в конфигурационном файле нужны uid и gid. Что нужно указать в gid для Windows-систем, чтобы все правильно работало?

Источник

Rsync настройка бэкапа на CentOS / Debian / Ubuntu

Установка rsync на CentOS 8

Чаще всего rsync уже присутствует в базовой версии centos 8, но скорее всего без версии, работающей в качестве службы. Так что устанавливаем обоих:

Если у вас еще нет настроенной системы, то используйте мои статьи по установке и настройке centos 8. Запускаем rsyncd и добавляем в автозагрузку.

Проверяем, слушает ли служба сетевой порт.

Все в порядке, можно приступать к настройке rsync. Если вам не нужен ipv6, то можете его отключить.

Установка rsync на CentOS 7

Добавляем в автозагрузку:

Проверяем, как запустился:

Все в порядке, можно приступать к настройке rsync.

Установка rsync на Debian/Ubuntu

Находим строку RSYNC_ENABLE=false и меняем на true:

Создаем пустой файл конфигурации /etc/rsyncd.conf, он нужен для запуска службы. Позже мы его заполним настройками.

Проверяем, что работает:

Все в порядке, можно приступать к настройке rsync.

Настройка rsync

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

Получается у нас такая картинка:

При этом подключение и работа rsync будет проходить по своему отдельному порту tcp 873. Не забудьте настроить iptables и открыть этот порт. Приступаем к реализации. В первую очередь настраиваем rsync на серверах источниках информации, с которых мы будем забирать данные для backup.

Создаем файл конфигурации rsync:

Создаем файл с учетными данными для подключения:

После настройки перезапускаем rsync. На Centos:

Теперь идем на сервер приемник, в котором будут храниться архивные копии с серверов источников. Там создаем скрипт инкрементного бэкапа c использованием rsync:

Делаем скрипт исполняемым:

Создаем файл с паролем для авторизации на сервере источнике:

Делаем права на чтение только root, иначе rsync выдаст ошибку:
ERROR: password file must not be other-accessible
Исправляем это:

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

и вот эту на сервере:

Проверьте настройки SELinux. Это он блокирует доступ к файлам. Нужно либо отключить selinux, либо настроить. В данном случае настройка простая:

Осталось добавить скрипт в cron:

Я обычно создаю несколько скриптов для каждого сервера отдельно. Потом объединяю их запуск в одном общем скрипте и уже его добавляю в cron. А потом по мере необходимости редактирую уже его, добавляю или удаляю сервера.

Копирование rsync через ssh

Rsync может работать через ssh. Это избавляет от необходимости настраивать отдельно службу и авторизацию, но при этом будут использоваться системные учетные записи. У меня есть предположение, что производительность при подключении по ssh будет ниже, но я нигде не видел подтверждения этому.

Для того, чтобы скопировать файлы с помощью rsync по ssh нет необходимости запускать службу, настраивать конфиг, создавать файл с авторизацией. Можно просто запустить примерно такую команду на передачу файлов.

Если для подключения вы используете публичный ключ или нестандартный порт ssh, указать эти параметры можно следующим образом.

Настройка исключений

Содержимое файла exclude.lst.

Это пример исключений для bitrix сайта. Все эти команды и исключения можно комбинировать и использовать в скриптах на примере того, что я привел в самом начале.

Ротация логов rsync

Мы ранее указали в настройках службы rsyncd ведение лога в файл /var/log/rsyncd.log. Необходимо настроить ротацию этого лога, чтобы он не рос до бесконечности. На больших файловых серверах он очень быстро вырастет до сотен мегабайт и более.

Для этого создаем в папке /etc/logrotate.d файл с конфигурацией ротации:

С такими настройками ротация будет происходить каждый раз, когда файл лога превысит размер в 500 кб. Храниться будут 4 версии лог файла. Эти настройки вы можете сами поменять по своему усмотрению.

Пример бэкапа windows сервера с помощью rsync

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

Создаем на windows сервере сетевую шару с информацией. Создаем пользователя и добавляем его в доступ к этой папке. Этого пользователя мы будем использовать для подключения виндовой шары к linux серверу.

Монтируем шару с информацией, которую будем бэкапить:

Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1.

Я в таких случаях создаю несколько скриптов: на монтирование шары, бэкап и размонтирование, объединяю их в один и запускаю последовательно. В итоге получается, что подключаем диск, делаем бэкап и отключаем его.

Онлайн курс «DevOps практики и инструменты»

Помогла статья? Подписывайся на telegram канал автора

Автор Zerox

132 комментария

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

@ERROR: auth failed on module data
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]
Thu 15 Apr 17:16:48 MSK 2021
Finish backup slack
Проделываю все по инструкции, почему такое выскакивает? рсинк на обеех машинах работает, фаерволов нет.

Ошибка явно говорит, что проблемы с аутентификацией. Надо в эту сторону смотреть.

Приветствую. Хочется поблагодарить за статьи, которые я уже неоднократно использовал.
Сейчас столкнулся с проблемой: нужно настроить резервное копирование раз в месяц «полный бейкап», ежедневно инкрементный бейкап (только изменения и каждый день в отдельный архив). Пример: 1 число месяца в 1:00 полный архив, 2, 3, 4, итд инкрементные архивы (в следующем месяце опять полный и на основании его инкрементные).

Это надо какой-то софт найти, где инкрементные бэкапы автоматизированы. Например, rdiff-backup или duplicity. Будет проще, чем реализовывать в rsync.

Я тоже хочу поблагодарить за статью. Добавил уже в закладки с 10-к страниц вашего сайта 🙂 Я на линуксе всего недели 3, для меня все в новинку. У меня есть вопрос. Я заказал VPS centos 7, мне сделали первоначальную настройку. Он рабочий. Я проверил, на нем уже установлен rsync version 3.1.2. Я боюсь что-нибудь настраивать, чтобы случайно не «сломать» vps, я ищу возможность сделать полный backup сервера с возможность восстановить его, в случае чего.

Уточните, пожалуйста, Rsync подходит для такой задачи? 🙂
Я уже читал вашу статью про Veeam Agent for Linux (https://serveradmin.ru/backup-i-perenos-linux-servera/) и не знаю точно, что мне поможет.
Мне нужно скопировать весь сервер со всеми настройками, процессами и т.д. на свой ноутбук (Lubuntu), а если я что-то сломаю, вернуть все обратно на VPS.
Хочется разобраться самостоятельно, без того, чтобы обратиться за помощью в тех поддержку, и они все настроили сами. Мне бы только научиться восстанавливать сломанную систему, а дальше обучение пойдет быстрее, надеюсь 🙂

Собственно, а чем Veeam Agent for Linux не устроил?

Спасибо в очередной раз.

Добрый день, подскажите как можно при помощи этого скрипта забэкапить сервер локально? Т.е архивы хранить локально

То есть просто в источнике (/var/www/html) и приемнике (/mnt/backup) указываете локальные папки.

Мне не нужен удаленный сервер, просто что бы он сам себя на себя бэкапил

Так я и показал, как он бэкапит в рамках одного сервера. Директории /var/www/html и /mnt/backup находятся на одном сервере.

Т. е если у меня папка для архива /backup

вот моя строчка в конф

Я же не знаю, какая у вас папка. /mnt/backup это просто пример. Если у вас бэкапы лежат в /backup, то указывайте ее.

Всё достаточно понятно, со всем можно разобраться. Но я вот столкнулся со следующей проблемой:
Есть шара на винде, которую удачно копирую через rsync, но никак не получается сохранить доменные права на файлы.
Была простая идея забрать их getfacl перед каждым бэкапом в отдельный файл, но если смотерть права на примонтированную через cifs шару, то он показывает только root:root, а не виндовые права. Подскажите, где я ошибаюсь?

А как вы виндовую шару копируете? Монтируете ее к линукс севреру? Он то ничего про доменных пользователей не знает, поэтому и права не сохраняются. Я не прорабатывал этот вопрос, но на скорую руку решал его просто. Сделал скрипт на powershell и права доступа с файлов собирал им в отдельный файл. При необходимости из него они накатывались обратно.

И сразу вторая проблема в голове, возможно встречались.

Если перенести всю помойку файловую на самбу, как будет корректно копировать? Тоже только виндой собирая ACL в файл?

Если перенести файловый сервер на самбу, будет масса других проблем. Я не рекомендую. Там права вообще иногда слетают. Мне лично не нравится вариант файловой шары на linux с AD. Я за 10-ти летнюю практику много таких историй видел и настраивал и везде, где была возможность, файловые шары оставлял на винде.

Не подскажите где взять это имя модуля и куда его прописать?

Собственно мой конфиг аналогичек как мануале:

Заранее большое спасибо за ответ.

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

# Ресурс на сервере для бэкапа
srv_dir=data

А у вас:
# Ресурс на сервере для бэкапа
srv_dir=/home/data/

Огромное спасибо за помощь.

Раз уж такое дело, может быть подскажите как быть с ошибкой:

На файле с паролем выставлены права 600. В чем еще может быть проблема?

Судя по всему у вас не запущена служба rsyncd. Ошибка явно на это указывает:

Здравствуйте. Планируете ли добавить описание установки rsync на CentOS 8?

В скрипте инкрементного бэкапа на сервере приёмнике есть строчка:

Видимо, было написано:

Надеюсь, с моим комментарием этого не произойдёт.

. произошло.
В общем, перед длинными опциями, как обычно в GNU Linux, два тире.

понять не могу почему крон эти скрипты не обрабатывает. в почту пишет мол
rsync: could not open password file /etc/rsyncdnos.scrt: Permission denied (13)
rsync error: syntax or usage error (code 1) at authenticate.c(187) [Receiver=3.1.3]
тоесть как я понимаю скрипт запускаеться а потом rsync не может открыть скрипт с паролем?
права на чтение\запись у них есть
в чем беда то?

Явно указано, что у rsync нет доступа к файлу с паролем. Он запускается под отдельным пользователем.

Так тут же прямым текстом описаны все проблемы с доступом rsync к файлам:

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

Вписывал в конфиг ( на боевом ) use chroot = false, так уже выдывало ошибку:
@ERROR chdir failed
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]
Подскажите что делать, заранее спасибо.

Добрый день!
Проверил файл на права, права стоят на 600 даже не знаю куда еще копать, прошу посмотри настройки может где нибудь ошибка а я ее не вижу.
вот настройки:
rsync.conf
port = 873
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes

# Папка источник для бэкапа
[data]
path = /mnt/net
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backuppc
secrets file = /etc/rsyncd.scrt

Сам скрипт
#!/bin/bash
date

# Папка куда будем складывать архивы
syst_dir=/sharedfolders/BACKUP/

# Имя Сервера, который архевируем
srv_name=server-backup
# Адрес сервера, который архевируем
srv_ip=127.0.0.1
# Пользователь на сервере, который архевируем
srv_user=backuppc

# Ресурс на сервере для бэкапа
srv_dir=/mnt/net

У меня виндовая шара примонтирована в /mnt/net/

Понимаю, что это некропостинг, но всё же, вдруг кому ещё поможет)

Считаю, нужно этот момент в статью добавить, а то неясно поначалу. Сам не знал об этом, пока не споткнулся и не полез разбираться.

У Barracuda, на ошибку которого вы указали, проблема не столько в синтаксисе команды, сколько в понимании того, что он делает. Посмотрите на IP его сервера. Он монтирует виндовую шару к тому же серверу, на котором создаёт бэкап. Тут вообще не нужен пароль.

Возможно, его ввёл в заблуждение предпоследний абзац:
«Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1.»

Вероятно, Владимир имел ввиду «использовать в качестве источника». Но не суть. Мне кажется, в этом случае вообще не нужен конфиг rsync.conf. Как и сам демон rsyncd. Хватит самой команды rsync, которая работает тут аналогом команды cp, только лучше: умеет копировать права доступа, ссылки-симлинки, главное, не будет тянуть те файлы, которые не изменились.

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

Я хорошо прорабатывал статьи. У них хорошие поведенческие факторы и много комментариев, поэтому и позиции высокие. Но устал уже, давно ничего хорошего не писал. Нет времени.

Добрый день!
Статья понравилась, как раз для моего случая мне тоже надо забэкапить с сервера Windows, настроил все по инструкции но при запуске файла ошибка:
root@angar13:

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

The —password-file option may only be used when accessing an rsync daemon

Доступ к файлу с паролем должен быть только у root, если rsync от него работает. Права на файл 600 должны быть.

Здравствуйте! А как настроить бэкап если на у файлов есть ACL?

В общую копилочку, на офф вики samba есть руководство по репликации sysvol, в нем и xattr и acls в rsync используются.
пруф: https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround

все заработало, извиняюсь за беспокойство

да действительно первый раз не понял,теперь вот это выпрыгивает
rsync error: error starting client-server protocol (code 5) at main.c(1648) [Receiver=3.1.2]

windows7
сама папка с windows монтируется,все норм.

Так если вы папку примонтировали к серверу с rsync, зачем вы пытаетесь подключиться к серверу windows с ip 192.168.1.3, если там rsync нет вообще? Походу вы не поняли принцип бэкапа виндовых машин. Прочитайте еще раз внимательно на эту тему. Надо монтировать шару и бэкапить через rsync с примонтированной шары в локальную директорию.

centos7 ip 192.168.1.8, на нем стоит rsync и на нем же примонтирована папка от windows.
windows 7 ip 192.168.1.3 на этой системе шара.
Что именно я не так сделал?)

Ребят как это победить? при попытке сделать бэкап виндовой шары выскакивает это

Start backup server1
rsync: failed to connect to 192.168.1.3 (192.168.1.3): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]
Вс май 26 19:28:05 +04 2019

А что на 192.168.1.3? Кто должен ответить на запрос rsync?

Так в чем конкретно проблема, если на qnap работает rsync?

[DATA]
path = /mnt/d/
list = yes
read only = yes
auth users = backup
secrets file = /etc/rsyncd.scrt
hosts allow = localhost 192.168.1.1
hosts deny = *

[var/log/rsync]
name lookup failed for 192.168.1.1: Name or service not known
connect from UNKNOWN (192.168.1.1)
rsync on DATA/NAS_HOME_1.hbk from backup@UNKNOWN (192.168.1.1)
building file list
rsync: link_stat «/NAS_HOME_1.hbk» (in DATA) failed: No such file or directory (2)
sent 101 bytes received 26 bytes total size 0

Это похоже на проблемы с настройкой rsync на qnap. Вы пытаетесь скопировать файл NAS_HOME_1.hbk, которого нету в директории /mnt/d/, которую вы указали в конфиге rsync.

Какую-то проверку надо сделать перед бэкапом. Например вот так:

Если вывод от df по имени SHARE равен 0 (т.е. сетевой ресурс присутсвует), то все в порядке, выходим, иначе запускается скрипт мотирования шары.

Это просто пример, я не отлаживал, но примерно так обычно делаю.

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

Народ, нужна помощь. Разобрался с косяками запустил новый сервер резервирования. Но размер бэкапа очень маленький по сравнению с оригиналом. Долго разбирался и выяснил что во время копирования данных с основного сервера (под Win 2008R2) выходит ошибка: rsync transfer failed: File name too long (36).

Попросив пользователей переименовать файлы, оказалось некоторые пользователи целые стихи вбивают в название файла (средняя длина имени 180-200 байт), на что получил категорический отказ мотивированный тем что таких файлов море, да и им тогда не понятно что за файл. Как теперь я понимаю ошибка о повреждении и невозможности восстановить копии на старой системе связанна как раз с тем что под win 2008r2 у файлов длина пути превышает 255 байт.
Решить через служебную с разъяснением почему надо писать короткие имена, а так же что надо переименовать старый, не удалось. Директор вставил в тык за то что саботирую работу сотрудников и вообще мешаю им работать и лишь создаю видимость свой работы.

В общем прошу подсказать как можно обойти данную проблему. На Centos использую систему ext4 и судя из https://en.wikipedia.org/wiki/Comparison_of_file_systems помочь может только переход на Reiser4 или ReiserFS, которые не поддерживаются Centos

Ограничение на длину пути файла это проблема windows. Я с ней сталкивался много раз, но мне всегда удавалось объяснить, что это техническое ограничение. Ведь это так и есть. А так да, тоже в свое время до конфликтов доходило. Тут мне нечего посоветовать. Обойти это ограничение я не знаю как. Нужно учиться объяснять и отстаивать свою правоту. А то тут один человек просил помочь с тем, что места для почты нет на сервере, а с него требуют, чтобы появилось, но без удаления писем. Уступите сейчас, потом будете место силой мысли на серверах освобождать. Есть объективные технические ограничения, их нужно учитывать, а не искать костыли.

Я не селен в настройках логов. Но у меня в логе только одно сообщение, о том что rsync запущен и какой порт использует. как настроит более детальный лог, что бы хотя бы писал во сколько начал и во сколько закончил резервирование?

После обращения к серверу, в логе /var/log/rsyncd.log будет вся информация, в том числе о переданных файлах.

не знаю. у меня в логе только:
sent 0 bytes received 0 bytes total size 0
rsyncd version 3.1.2 starting, listening on port 873

и то только после ручного запуска.
все сделано как и у вас.

Информация должна появиться в логе, когда кто-то подключится и заберет файлы.

А если у меня сервер на себя же копирует документы, которые смонтированы с сетевого хранилища и win сервера?
rsyncd.conf у меня такой:

pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes
syslog facility = local5

# папка источник для бэкапа
[data]
path = /docs #точка монтирования сервера с документами
uid = root
read only = yes
list = yes

Спасибо!! Практически то что надо, в таком виде многовато перебирать, но меня устроит)

Ключ progress можно убрать. Он нужен, только если в консоли сам смотришь за процессом. В лог эту информацию нет смысла отправлять.

вот так выглядит rsyncd.conf:

gid = users
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid

[IT]
path = /dom/otlde/it
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backup
secrets file = /etc/rsyncd.scrt

а вот так мой скрипт:

date
#Папкв, куда складываются архивы
syst_dir=/disbackup/otdel

#Имя сервер, который архивируем
srv_name=servotdel

#Адрес сервера, который архивируем
srv_ip=127.0.0.1

#Пользователь из подкоторого выполняется скрипт
srv_user=backup

#Ресурс для резервирования
srv_dir=/dom/otdel/IT

в общем где у меня косяк?

Сделал все по вашей инструкции и столкнулся с проблемой. Копирование папки происходит в директорию current, которая лежит в корне, а не туда куда я хотел бы положить. В документации не увидел ключа по которому можно это реализовать. Ключ path как я понял применим только когда говорим о пути до источника резервирования или я ошибаюсь? В общем подскажите как изменить директорию для полной копии

А какова глубина резервирования: 1 раз в месяц полная и каждый день в течение него инкрементные с последующей перезаписью, и все? или каждый месяц одна полная и в течении него инкрементные?

«Теперь приступаем к настройке. Логика наших бэкапов будет следующая. При первом запуске мы делаем полный бэкап интересующей нас информации в папку current. Потом раз в сутки мы сверяем имеющийся архив с источником и делаем его вновь актуальным, перезаписывая все изменившиеся файлы, но при этом не удаляем их, а складываем в папку increment, где каждый день создается папка с именем в виде даты, в которую складываются все измененные файлы за текущий день. Таким образом, у нас всегда будет полный архив, актуальный на момент последней синхронизации, плюс набор папок за каждый день с изменившимися в этот день файлами. Сколько дней хранить можно выбрать по необходимости.»

» Таким образом, у нас всегда будет полный архив, актуальный на момент последней синхронизации» вот эта фраза как раз и вызывает вопрос о частоте получения полной копии

У вас полная копия будет каждый день после синхронизации. Не знаю, как еще понятнее объяснить. Вы один раз делаете полную копию, а потом сравниваете изменения за день и актуализируете каждый день эту полную копию. А изменившиеся файлы складываете в отдельную папку.

Это не похоже на инкрементные копии, к примеру, veeam, так как он хранит данные не в открытом виде, а в своем формате. Здесь же у вас будут сырые данные, таком виде, как они есть на источнике.

Вот честно я в тупике) Исходя из сказанного я так понимаю что каждый день делается полная копия с актуальными данными, при этом мы файлы которые изменились складываем еще и отдельно. В таком случае возникает вопрос, а зачем «инкримент нужен», ведь подобный архив будет жрать место.

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

я не до конца понял. ты на Unix сервера бэкапишь или сами сервера?

Я у автора спрашал))) Может ты тогда подскажешь. Из статьи я вижу что данные не архивируются. а тупа копируются. Это так?

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

Бэкаплю любые данные на unix сервер.

Подскажи пожалуйста. Пробую сделать как выше описано и не могу разобраться в одной мелочи. У меня есть сервер на котором штук 15 шар на разных дисках, которые надо резервировать, точно так же в разные шары, которые физически находятся на отдельно стоящем сервер. Я их отдельно цепляю к серваку. Вопрос как правильно их писать в конфиге. Я делаю так

[data1]
path = /data1
.
[data3]
path = /data3
.
[data3]
path = /data3

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

Автору большое спасибо за статью, все клево работает )

Маленькое дополнение, для тех кто любит окошки будет полезен гуй для rsync — grsync.

Хочу перенастроить выделенный sys сервер ovh.
Не поможете

secrets file = /etc/rsyncd.scrt

Можно указать в основной секции а не в модуле.

И по ssh раз в час примерно связь отрубается, теряется соединение и ничего не поделаешь, а в rsync можно чтобы он если связь оборвалась до копировал недостающие файлы в папке?

При повторном запуске он продолжит синхронизацию.

Да, rsync работает быстрее всех известных мне способов передачи информации. Всегда его использую при возможности.

«Никак не могу разобраться чтобы команда работала наоборот, чтобы в current лежал полный архив, например, за 20 мая, а в increment складывались изменения за 21 мая, за 22 мая.»
А это вообще возможно или нет?

Вроде все порты слушает, только с одного ip пробивает telnet, остальные отбой дают. Пожалуйста помогите.

Не понял вопрос про восстановление. Файлы же в открытом виде лежат. Можно просто зайти в папку и скопировать куда хочется.

А автоматически, командой rsync, с сервера где лежит резервная копия? Например если резервная копия более 100 Гб, а сервер удаленный. Не слишком удобно копировать обратно посредством, допустим ftp-сервера.

А можно просто настроить все то же самое, что описано в статье, только в обратную сторону. Поменять местами источник и приемник.

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

Если файлов 100 Гб, то очевидно, их лучше сжать сначала архиватором перед отправкой.

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

У меня именно два двоеточия в скриптах, так и работает. Уже не помню почему и зачем их два 🙂 По ssh ключу тоже иногда настраиваю, если он есть. Тут субъективно, кому как больше нравится.

Спасибо за статью!
Возник вопрос, в чем преимущества/недостатки отдельного rsync-сервера на отдельном порту по сравнению с ssh.

Я не проверял специально, но думаю, что по ssh будет меньше скорость, чем напрямую через rsync. Узнав пароль пользователя rsync, можно получить данные, к которым есть доступ только через rsync, а не ко всем данным сервера. А с учетом того, что доступ на чтение файла с паролем есть только у рута, узнать пароль сможет только тот, кто получил рут доступ. В общем, как мне видится, какого-то принципиального отличия в безопасности я не вижу.

Даже более того, если будет скомпрометирован сервер с бэкапами, злоумышленник получит рут доступ ко всем серверам, с которых по ssh забирались данные через учетку рута. А тут будет только ограниченный доступ к каталогам с бэкапом.

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

Добрый день. Воспользовался вашей статьей, сам в первые пользуюсь линуксом, юзаю Ubuntu server 14.04. Есть необходимость подключать виндовс шару, бекапить ее на линукс сервер. Скрипт заработал у меня в следующем виде:

Судя по тому, что данные из current улетают в increment, во время бэкапа папка с данными не подмонтирована, либо она по какой-то причине пустая. Rsync считает, что в папке пусто и все, что было ранее, перемещает в папку increment. Это его нормальное поведение при пустом источнике файлов. Копай в эту сторону.

Источник

Posted on October 20, 2013

10-21-2013 Update:  Corrected a few errors in the write-up and fixed the template configuration files.

Introduction

I remotely manage the computers & networks for various family members (parents, siblings, and grandparents).  To this end, I currently have router-to-router VPN links consistently established between home networks at five distinct geographic locations.  (These links are maintained using OpenVPN running on my OpenWrt-based gateway routers.)

As administrator of this geographically-diverse home network, I need to consistently back up my family’s data in case disaster strikes.  While there are many reputable cloud-backup solutions available, I prefer to trust my own skills to manage and protect my (and my family’s) data.

As we all know, a key backup strategy is to have off-site backups.  Fortunately, because my VPN spans multiple geographic locations, the off-site backup problem is easy – provided I can periodically synchronize files between computers at different locations.  Unfortunately, my VPN links are limited to approximately 300 KB/s due to the limited uplink bandwidth.  For me, this is where rsync comes in.

What is Rsync?

Rsync is a tool for *NIX.  From the rsync man page, “rsync … [is] … a fast, versatile, remote (and local) file-copying tool.” For me, attractive capabilities of rsync include:

• Delta-transfer algorithm – Only sends the differences between the “old” and “new” versions of the file when synchronizing over a network
• Supports compression of file data when sent via network
• Supports various modes for determining which files need to be transferred
  • “Quick check” comparison (file size & timestamp)
  • Checksum comparison (MD5)
• Transactional behavior (supports a mode where changes are not “committed” unless entire transfer was successful)
• Ability to resume partially-completed file synchronizations (without starting over)

Using “rsync”, the process of synchronizing files over slow VPN links can be made much less painful. The remainder of this entry documents installing and setting up rsync on Windows systems.

Installing Cygwin

I’m a Windows guy. Rsync is not (natively) a Windows tool.  While there are many ways to get rsync for Windows, the easiest way (in my opinion) is to install Cygwin.

(Honestly, even if you don’t care about running rsync, if you don’t have Cygwin installed on your Windows box, you probably should rectify that situation immediately.  Go do it now.  And yes, for those who are diehard Windows fans, I checked whether rsync can run on Subsystem for UNIX-based applications, and it doesn’t sound like it…bummer.)

Tips for Installing Cygwin so that it’s “rsync-ready”:

1. Download the Cygwin installer.
2. Verify the integrity of the Cygwin installer using GPG or whatever PGP tool you use.  For reference, Cygwin’s current public key’s is as follows:
   1. DSA key ID:  676041BA
   2. Fingerprint: 1169 DF9F 2273 4F74 3AA5  9232 A9A2 62FF 6760 41BA
3. Run the installer.  When you get to the point of selecting packages, be sure to install both the “rsync” and “cygrunsrv” packages.  You may also want “nano” if you’re not a “vi” person.
4. After installation, if your Windows user account contains spaces, eliminate those spaces from your Cygwin account and your home folder.  Do this by:
   1. Editing /etc/passwd to change the home directory and user name
   2. Renaming your home directory in /home
   3. (Re-)starting the Cygwin shell

Perform the above steps on *both* the rsync client and the rsync server.

Understanding Rsync Modes of Operation

Rsync can access files on a remote host using two different methods.  From the man pages, “There are two different ways for rsync to contact a remote system: using a remote-shell program as the transport (such as ssh or rsh) or contacting an rsync daemon directly via TCP.”

Of course, the advantages of using the remote-shell approach are obvious – no need to open additional ports and encryption of transmitted information.  However, in my case, I had no need of encryption (due to my VPNs) and I would have to open up ports regardless (my Windows boxes were not running any remote-shell daemon).  I therefore decided to get rsync working as a daemon on the server.

Installing Rsync as a Windows Service (Server-Side Only)

The equivalence to “daemons” in the Windows world are “services.” To install Rsync as a Windows service, a few steps are necessary and not exactly obvious.  In researching the problem, I found an online tutorial that provided instructions; however, some steps didn’t seem quite right to me from a security standpoint.  With some experimentation, I came up with a procedure that worked (on Windows 7, at least):

1. Create a new Windows user account called “rsync” with a random password & remember it for later.  This account will be used to run the rsync service.  Use the following settings:
   1. User cannot change password
   2. Password never expires
   3. No group memberships (i.e. remove the default “users” group).
2. Use secpol.msc –> Local Policies –> User Rights Assignment to configure the user privileges for the “rsync” user:
   1. Deny rsync “log on locally”
   2. Deny rsync “access computer from network”
   3. Deny rsync “log on through remote desktop services”
   4. Allow rsync “log on as a service”
   5. Note:  Not all Windows editions support secpol.msc.  There are ways to set these configuration settings using other mmc snap-ins, but doing so is outside the scope of this blog.
3. Using Windows Explorer’s file permission editor, grant the Windows rsync account FULL CONTROL rights to any folder that will be synchronized remotely via rsync.
4. From the Cygwin shell as root, run ‘mkpasswd > /etc/passwd’ to update the password file with the latest MS Windows user account list.
   1. Note:  If you had to manually update the /etc/passwd file to remove spaces within your Cygwin username, execute ‘mkpasswd >> /etc/passwd’ instead and then manually edit the file to remove the duplicate information added.  This way you won’t overwrite your previous changes.
5. Generate the rsyncd.conf configuration file:
   1. Download the above template file.
   2. Edit the template configuration file to add the folders you wish to make available via the rsync daemon.  Note that your “c:\” drive is mounted under the /cygdrive/c/ Cygwin path.
   3. Copy the file to the Cygwin path /etc/rsyncd.conf
   4. Use chmod to set the file permissions to 644 (rw- r– r–).
6. Generate the rsyncd.secrets file:
   1. Download the above template file.
   2. Edit the file to set the rsync daemon password.  Since we’re using plaintext communication (not counting any VPN) don’t use a password you use anywhere else.
   3. Copy the file to the Cygwin path /etc/rsyncd.secrets
   4. Use chown to change the owner of this file to “rsync”
   5. Use chgrp to change the group of this file to “root”
   6. Use chmod to set the permissions to 660 (rw- rw- —).
7. Install the Windows service using the following command within an administrator command prompt:
   C:\cygwin\bin\cygrunsrv.exe -I "rsync" -p /cygdrive/c/cygwin/bin/rsync.exe -a "--config=/cygdrive/c/cygwin/etc/rsyncd.conf --daemon --no-detach" -f "Rsync daemon service"
   1. Note: This assumes you’ve installed Cygwin to C:\cygwin. You should adjust the paths above if you installed Cygwin somewhere else.
8. Use services.msc to:
   1. Configure the now-installed rsync service to run under the “rsync” account.  You’ll need the random password you typed in earlier.
   2. Configure service autostart settings as desired.
   3. Start the rsync service.
9. Edit your firewall settings to allow inbound port TCP 873 for rsync.exe.

Rsync on the Client

At this point, we have Cygwin installed on both the client and the server machines.  We also have rsync running as a daemon on the server machine as a Windows service.  So, all we need to do now is run rsync on the client machine.

There are, however, some complications.  First and foremost, there are a boatload of rsync options available, many of which we’d like to invoke during each and every rsync operation.  Secondly, due to the /etc/rsyncd.secrets file, we will need to provide a password during every rsync connection, which may be undesirable.  Finally, for lengthy transfers, a network glitch may interrupt rsync, and we may wish to have it automatically restarted for us after a brief period of waiting.

Fortunately, we can automate all of the above (and more) by writing a few simple shell scripts:

(IMPORTANT: Read the cautionary note below before attempting to use any of these scripts.)

• rsync.sh – Calls rsync with a set of default options (specified at the start of the script file). If run in “remote” mode, automatically loads the rsync password for the remote host from a file (named hostnamehere.rsyncpw) in the home directory. The script also implements a –loop option for auto-retrying failed synchronizations.
  Usage: ./rsync.sh local|remote [--loop] [additional rsync options] source dest
  1. Note: For the script to work, when specifying the remote host, use the format “username@remotehostname::FoldernameHere/”

  Example:
  ./rsync.sh remote --dry-run /cygdrive/c/myfiles/ aaron@desktop::myfiles/

• rsync_local.sh – Provides a short cut for calling the above “rsync.sh” script; always provides the “local” option to the script.  This allows for a syntax such as:
  ./rsync_local.sh --dry-run /cygdrive/c/myfiles/ /cygdrive/c/myfiles2/
• rsync_remote.sh – Provides a short cut for calling the above “rsync.sh” script; always provides the “remote” option to the script. This allows for a syntax such as:
  ./rsync_remote.sh --dry-run /cygdrive/c/myfiles/ aaron@desktop::myfiles/
• rsync_batch.sh – Automates the execution of multiple separate rsync operations using a separate file containing a list of synchronizations to perform.
  Usage: ./rsync_batch.sh check|sync timestamp|checksum rules_file [additional rsync options]
  • check|sync – Option “check” runs the batch set of rsync commands with the –dry-run option to prevent any changes from being made. Option “sync” actually performs the synchronization.
  • timestamp|checksum – Option “timestamp” uses timestamps and file sizes (the default mode) for file comparison. Option “checksum” uses the MD5 checksum for file comparison.
  • rules_file – Specifies the rules file to use for the batch synchronization. See the example.

For ease of use, after downloading the scripts, drop them in your Cygwin home directory, and use chmod +x to mark them executable.

CAREFUL: Being a file synchronization program, if used incorrectly, rsync can easily damage/destroy large amounts of your data. So, be VERY careful when running rsync with or without the above scripts. I AM NOT RESPONSIBLE for any damage to your computer and/or files through the use of the scripts provided above!

I highly recommend that you always first invoke rsync with the –dry-run option to view the likely results of the synchronization without actually changing anything.

Conclusion

I hope this guide helps anyone setting up rsync on their Windows systems.