Телевизор 

Rsync примеры. Rsync — Примеры синхронизации. Правила очистки списка фильтров

Служба Microsoft Dfs предоставляет великолепную возможность обеспечить пользователям простой доступ к данным, хранящимся на удаленных компьютерах. С помощью Dfs можно просматривать папки и обращаться к ним как к отдельному множеству общих каталогов через знакомую, унифицированную иерархию даже в тех случаях, когда ресурсы расположены в различных доменах или на разных физических носителях. Тех, кто не пользуется службой Dfs, опасаясь ее сложности, хочу обрадовать: бояться нечего - настройка Dfs интуитивно понятна, а применение вызывает еще меньше затруднений. В этой статье я объясню принцип работы данной службы и познакомлю читателей с типичной настройкой. Начав использовать службу Dfs, обычно администраторы вскоре уже не могут понять, как это раньше пользователи обходились без нее.

Принцип работы Dfs

Основным элементом структуры данной службы является общий каталог, который представляет собой корень иерархии Dfs. При помощи Dfs эти сетевые каталоги формируют последовательное отдельное пространство имен. Клиентские системы используют хорошо знакомые понятия, такие как подключенный диск или путь UNC (Universal Naming Convention), для подключения к корню Dfs. После подключения клиента структура Dfs выступает в роли обычного общего каталога, содержащего подкаталоги, по которым пользователи могут перемещаться. Каждый подкаталог, доступный из корня Dfs, на самом деле представляет собой ссылку на общий каталог (источник ссылки) в любой точке сети. Dfs автоматически направляет клиента, который обращается к сетевой папке, к реальному месту расположения данных. Как показано на экране 1, папки, которые видит пользователь, представляют собой переадресацию пользователей службой Dfs к разным общим каталогам на серверах A, Б и В. В роли источника ссылки может выступать любая система, использующая сетевую файловую систему, к которой можно обратиться через путь UNC, например системы с Windows, Novell NetWare и UNIX или Linux (то есть машины с файловой системой NFS).

Служба Dfs позволяет задействовать корни двух видов: автономные и интегрированные в Active Directory (AD). Они различаются способами хранения данных Dfs. В случае автономных корней иерархия Dfs, состоящая из различных ссылок на сетевые каталоги, хранится в локальном реестре сервера Dfs. Этот способ хранения информации не предполагает возможности ее дублирования на других серверах Dfs, то есть, если единственный сервер Dfs, содержащий корень Dfs, становится недоступен, иерархия Dfs оказывается полностью недоступной для всех клиентов сети. В случае недоступности сервера Dfs клиенты по-прежнему могут обращаться к общим каталогам на серверах напрямую. Они лишь не смогут задействовать службу Dfs для доступа к ресурсам. Придется использовать автономные корни Dfs, если система не содержит службу AD или если администраторы системы Dfs не являются администраторами домена и поэтому не могут получить достаточно прав (то есть получить доступ к объекту DFS-Configuration в контейнере System раздела AD для домена) для управления системой Dfs.

Система Windows 2000 Server и более поздние версии также поддерживают корни Dfs, интегрированные с AD (известные еще как доменные корни Dfs или отказоустойчивые корни Dfs). При использовании интегрированных корней информация Dfs хранится преимущественно в AD, хотя действующие серверы Dfs тоже содержат копии данных в памяти, чтобы минимизировать количество обращений сервера Dfs к контроллерам домена (DC) и таким образом снизить нагрузку на сеть со стороны службы Dfs. Интегрированные в AD корни можно использовать только тогда, когда сервер Dfs является членом домена. Однако сервер Dfs не обязан быть контроллером домена. По существу, следует задействовать автономные корни Dfs в случае отсутствия домена AD, необходимости разместить более 5000 ссылок или же если сеть содержит унаследованные клиентские системы. Более подробная информация о различиях между автономными и интегрированными в AD корнями Dfs приведена во врезке .

После того как вы решите, какой тип корней Dfs будете использовать, необходимо настроить ссылки и источники ссылок, содержащие данные, которые система Dfs будет предоставлять клиентам. Как уже говорилось, источник ссылки - это общий ресурс, к которому Dfs направляет клиента при обращении по ссылке. Ссылка может иметь несколько источников, благодаря чему реализуется балансировка нагрузки и отказоустойчивость: если общий каталог на одном из серверов недоступен, Dfs направляет клиента к другой копии данных. Существующий источник ссылки, используемый клиентом, зависит в основном от расположения клиента. По существу, Dfs - это служба установки взаимосвязи между хостами в сети, то есть по умолчанию, если источник ссылки находится вблизи от клиента, то Dfs направляет клиента к данному источнику ссылки.

Настройка Dfs

Теперь, когда мы изучили важнейшие понятия системы Dfs, можно приступать к ее настройке. Первая задача - создать корень Dfs. Для этого существует два способа: использование в Microsoft Management Console (MMC) оснастки Distributed File System и запуск приложения dfsutil.exe из командной строки. В данной статье мы рассмотрим оснастки, что чуть проще для новичков по сравнению с dfsutil.exe. Ознакомившись с Dfs, вы, возможно, захотите использовать dfsutil.exe, например, в сценарии, заполняющем ссылками иерархию Dfs. Тогда нужно иметь в виду, что в системах Windows Server 2003, Standard Edition и Windows 2000 Server сервер может содержать лишь один корень Dfs. Серверы Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition могут работать с неограниченным числом корней Dfs.

Чтобы создать новый корень Dfs с помощью оснастки Distributed File System, необходимо выполнить следующие шаги:

  1. Запустить оснастку Distributed File System (пункт находится в папке Administrative Tools меню Start).
  2. Щелкнуть правой кнопкой мыши по заголовку Distributed File System в корне дерева в панели и выбрать пункт New Root (если используется система Windows 2003) или New DFS root (для Windows 2000 Server). Последующие шаги используют диалоговые окна системы Windows 2003, хотя сам процесс почти полностью повторяет процесс для оболочки Windows 2000 Server.
  3. В окне приветствия нажать кнопку Next.
  4. Выбрать тип создаваемого корня (доменный или автономный). Нажать Next.
  5. Если выбран доменный корень Dfs, потребуется ввести имя домена, который будет хранить информацию службы Dfs. Если выбран автономный корень, следует ввести имя сервера, который будет хранить соответствующую информацию. Нажмите Next.
  6. Если на шаге 4 выбран доменный корень, программа попросит выбрать сервер, который будет содержать корень Dfs. Следует указать сервер и нажать кнопку Next.
  7. Ввести имя нового корня и любые комментарии, которые помогут при его идентификации, после чего нажать Next. Введя имя корня, вы увидите, как это имя будет выглядеть в качестве имени общего каталога в формате UNC, как показано на экране 2. Например, для доменного общего каталога Dfs имя пути имеет структуру имя доменаимя каталога. Если на данный момент общего каталога не существует, нужно выбрать локальную папку на системе в качестве общего каталога. Этот каталог не содержит реальных данных; вместо этого он включает объекты-ссылки, указывающие на физическое расположение данных. Необходимо выбрать папку для использования в качестве общего каталога и щелкнуть Next.
  8. В окне подтверждения нажать кнопку Finish.
Экран 2. Указание нового корня Dfs

В этой точке клиенты могут подсоединяться к пространству имен Dfs, используя путь UNC dfstest.testshared. Им не нужно ничего знать о том, какие серверы содержат элементы Dfs. Клиенты, использующие систему Windows NT 4.0+Service Pack 6a (SP6a) или более поздние версии, могут подсоединяться к доменному пространству имен Dfs. Клиенты, использующие оболочку Windows 98, могут обращаться к автономным пространствам имен Dfs, но должны иметь установленное расширение, клиента службы AD, чтобы подключаться к пространству имен домена. Среда загрузки Microsoft Windows Preinstallation Environment (WinPE) может обращаться лишь к автономным пространствам имен Dfs.

Чтобы воспользоваться преимуществом отказоустойчивости доменного пространства имен Dfs, необходимы по крайней мере два сервера Dfs, поддерживающих одно пространство имен. Чтобы настроить второй хост-сервер Dfs, следуйте приведенным ниже инструкциям:

  1. В оснастке Distributed File System щелкните правой кнопкой по созданному корню и выберите пункт New Root Target.
  2. Введите имя сервера, который послужит дополнительным хостом Dfs для пространства имен. Имейте в виду, что имя общего каталога (например, shared), которое система Dfs будет использовать для содержания этой копии, уже задано и не может быть изменено. Нажмите Next.
  3. Если каталога с таким именем на указанном сервере не существует, система предложит выбрать папку для использования в этом качестве либо можно создать новую папку, а потом выбрать ее. Выберите папку и нажмите Next.
  4. В результирующем окне нажмите кнопку Finish.

Корень Dfs теперь будет отображать множество серверов, которые действуют как корневые объекты пространства имен, как показано на экране 3. Клиенты могут подключаться к пространству имен и направляться на один из его корневых объектов. Однако пользователи, обратившиеся к корневому объекту, увидят лишь пустую папку, так как еще не задано ни одной ссылки. Следующим шагом будет добавление нескольких ссылок и источников ссылок, которые будут направлять клиентов к нужным данным.

Экран 3. Просмотр источников корня Dfs

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

  1. Щелкните правой кнопкой мыши на корне Dfs и выберите пункт New Link из контекстного меню.
  2. Введите имя ссылки (то есть имя папки, которую будет видеть клиент) и имя общего каталога, в который ссылка будет направлять клиента. Это имя можно изменить или добавить позднее. Также можно ввести комментарий и определить период времени, в течение которого клиенты будут хранить информацию по источнику, до повторного обращения к серверу Dfs, как показано на экране 4.
  3. Нажмите кнопку ОК.

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

Предположим, у нас имеется папка с документами на сервере в удаленном офисе. Вместо того чтобы создавать отдельную ссылку на эту папку (например, LondonDocuments), можно добавить еще один источник к существующей ссылке. Настройка множества источников ссылки - еще один способ обеспечить отказоустойчивость. Если один из источников ссылки недоступен, система Dfs может направить пользователя к другой копии данных. Чтобы добавить дополнительный источник к существующей ссылке, следуйте приведенным ниже инструкциям.

  1. Щелкните правой кнопкой мыши по ссылке и выберите пункт New Target из контекстного меню.
  2. Укажите путь к новому каталогу, который также послужит источником для данной ссылки. Можно дополнительно включить дублирование данных, поставив флажок в поле Add this target to the replication set, как показано на экране 5. Дополнительная информация о дублировании приведена во врезке «Настройка дублирования данных на основе службы Dfs».
  3. Нажмите кнопку OK.

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

Как мы убедились, для одной ссылки может существовать множество источников. Эта возможность вызывает очевидный вопрос: не будет ли наличие разнообразных данных в различных источниках ссылки означать, что система Dfs может произвольным образом направлять клиентов к различным источникам ссылки и клиенты будут видеть различные файлы? Так как источники ссылки представляют собой разные каталоги на отдельных серверах, специального механизма для постоянной синхронизации их содержания не существует. Следовательно, вполне возможна ситуация, когда различные источники ссылки будут иметь разное содержание. В таком случае клиент обратится к папке, получит доступ к данным, но, вернувшись к той же папке позднее, возможно, будет отправлен к другому источнику ссылки и увидит совершенно другой набор данных. Однако этот сценарий маловероятен. Мои пояснения по теме приведены во врезке . К счастью, оболочка Windows 2000 Server и более поздние реализации системы Dfs содержат службу File Replication Service (FRS), которую контроллеры домена задействуют для постоянной синхронизации своих общих каталогов Sysvol. Система Dfs использует службу FRS для синхронизации источников ссылки, которые являются частью доменного пространства имен. Служба FRS предоставляет различные возможности дублирования, такие как непрерывное дублирование, которое позволяет дублировать изменения в режиме, близком к реальному времени, и дублирование в определенное время суток. Система Windows 2003 R2 будет содержать новую версию службы FRS специально для службы Dfs. Инструкции по настройке дублирования файлов на основе системы Dfs приводятся во врезке . Если используется автономный корень Dfs и требуется синхронизация, для решения этой задачи необходимо средство синхронизации файлов, такое как служба Robocopy из пакета Windows Resource Kit.

Как мы выяснили, система Dfs заметно упрощает доступ к общим ресурсам для конечных пользователей и, при действующей службе AD, предоставляет методы повышения отказоустойчивости. Для оптимальной работы системы Dfs в конкретной компании потребуется решить, какие файлы необходимо дублировать, и, если нужно, отладить механизм перенаправления. Я привел самую существенную информацию, которой следует владеть перед началом работы с Dfs. Дополнительные сведения по этой теме можно найти на Web-сайте Microsoft?s Distributed File System and File Replication Services по адресу http://www.microsoft.com//windowsserver2003/ technologies/fileandprint/file/dfs/default.mspx .

Такие разные корни

Каждый тип корня Dfs имеет свои преимущества и ограничения. Важно помнить, что, в отличие от интегрированной в Active Directory (AD) службы DNS, доменные корни Dfs не обязаны находиться на контроллерах домена (DC); они могут содержаться на любом сервере, который является членом домена и использует Windows 2000 Server или более поздние версии. При запуске и через определенные интервалы времени (по умолчанию один раз в течение часа) серверы Dfs просто обращаются к эмуляторам PDC домена, чтобы получить последние данные о пространстве имен Dfs. Эти периодические запросы могут оказаться узким местом при доступе к ресурсам. Кроме того, они накладывают ограничение в 16 копий корней при реализации Dfs, а значит, нельзя будет иметь более 16 корней для одного пространства имен, так как синхронизация между серверами Dfs становится все более сложной при каждом изменении структуры Dfs (т. е. при добавлении новой ссылки или ее источника). Исключением из этого правила является реализация Dfs в системе Windows Server 2003, которая имеет новый режим масштабирования корней, обычно позволяющий серверам Dfs обращаться к любому DC в домене, а не только к эмулятору PDC.

Другое ограничение доменных корней Dfs заключается в том, что вся структура Dfs (в том числе ссылки, источники ссылок и корневые серверы) хранится в отдельном объекте, который необходимо дублировать на всех контроллерах домена при малейших изменениях в структуре Dfs. Вам это не напоминает дублирование членства в группе в системах Windows 2000 Server? Для корректного выполнения дублирования Microsoft рекомендует иметь максимальный размер объекта Dfs не более 5 Mбайт (около 5000 ссылок). Средняя реализация Dfs имеет около 100. Если требуется разместить более 5000 ссылок, следует обдумать варианты разделения пространства имен Dfs на множество пространств имен или использование автономных корней Dfs, для которых рекомендованный лимит составляет 50 000 ссылок. Другой способ минимизировать объем, используемый системой Dfs в AD, - ограничить число комментариев, приводимых для ссылок, так как они тоже хранятся в объекте Dfs службы AD. Тем не менее нужно помнить, что подобное пространство имен Dfs вряд ли будет часто меняться. После настройки начальной конфигурации системы Dfs она останется достаточно статичной и не будет дублироваться часто.

Настройка дублирования на основе Dfs

Если в системе имеется множество источников ссылки и предстоит осуществлять постоянную синхронизацию файлов, требуется настроить дублирование на основе Dfs. Чтобы настроить дублирование для ссылки, нужно выполнить следующие шаги:

  1. Щелкнуть правой кнопкой мыши по ссылке и выбрать пункт меню Configure Replication.
  2. На экране приветствия мастера Configure Replication Wizard нажать кнопку Next.
  3. Программа попросит выбрать источник, который станет оригиналом для дублирования. Если имеется общий каталог, содержащий данные, которые необходимо дублировать в другие папки, следует выбрать его в качестве оригинала. Нажмите кнопку Next.
  4. Необходимо будет выбрать топологию, используемую при дублировании. По умолчанию установлена кольцевая топология, которая подходит для большинства сетей. Если сетевое окружение более сложное, можно рассмотреть использование других топологических схем, таких как «издатель - подписчики», взаимная пересылка и схема, настраиваемая пользователем. Выбранная топология должна соответствовать топологии имеющейся глобальной сети; в идеале топология дублирования службы FRS должна соответствовать схеме сети. К примеру, если сеть включает один центральный офис и множество подключенных к нему филиалов, топологическая схема «издатель - подписчики» будет наилучшим выбором. Нажмите Finish.

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

Хочу кое-что пояснить относительно технологии дублирования в Dfs: она не создавалась для работы с данными, которые находятся на множестве серверов и часто обновляются, или для тех случаев, когда файл может обновляться в одно время в различных источниках ссылок. Служба FRS не соединяет все изменения в одном файле; дублируется файл, сохраненный последним. Поэтому стоит задействовать службу FRS только для дублирования статичных данных, таких как шаблоны или политики компании, либо данных, которые будут обновляться лишь в одном месте в один и тот же момент времени. Основное достоинство службы FRS заключается в том, что она предоставляет отказоустойчивый набор данных, чтобы обеспечить надежную защиту в случае сбоя отдельного сервера.

Настройка перенаправления в Dfs

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

Заданное по умолчанию поведение системы Dfs (перенаправление клиента на произвольный альтернативный источник ссылки), если она не может найти локальный источник, может быть неэффективным. Например, если система Dfs не находит локальный источник в Далласе, она может перенаправить клиента к источнику в Лондоне, хотя в Нью-Орлеане существует еще один источник, соединение с которым реализовано через более быстрый канал. Однако настройки Dfs можно регулировать, обеспечивая более эффективное перенаправление запросов пользователей. Можно настроить Dfs таким образом, что система будет направлять клиентов только к источникам ссылок, размещенным в локальном окружении пользователей. Для активизации этого режима, названного Restricted Same-site Target Selection, следует запустить команду Dfsutil и указать параметр /insite:

dfsutil /root: /insite /enable

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

С другой стороны, если на контроллерах домена и серверах Dfs используется оболочка Windows 2003, можно задействовать режим Least-Expensive Target Selection. В этом режиме, если локальный источник ссылки недоступен, система Dfs перенаправляет клиента на источник, соединение с которым даст наименьшую нагрузку на полосу пропускания; Dfs использует для этого стоимость межсайтовых соединений, описанных в AD. Режим Least-Expensive Target Selection минимизирует использование медленных соединений и позволяет клиентам быстрее получать доступ к сетевым каталогам. Чтобы активировать режим Least-Expensive Target Selection, нужно запустить команду:

/sitecosting /enable

Специалист по продуктам Microsoft в компании Geniant. Имеет сертификат MCSE и звание MVP.

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

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

  • В механизме работы DFS нет способа определить какая реплика файла является правильной.
  • При наличие нескольких реплик в одном сайте, DFS сама выбирает куда отправить пользовательский запрос, на реплику А или на реплику Б, ориентируясь при этом, судя по всему по загруженности сервера-хранилища. (Есть некоторые настройки порядка выбора реплики, но сути они не меняют: если в пределах сайта несколько реплик, то выбор конкретной из них может быть непредсказуем.
  • Эти нюансы позволяют смоделировать ситуацию, когда пользователь А обратится на реплику А и будет работать там с данными, а пользователь Б обратится на реплику Б и будет там работать с данными. В результате будут образованы ДВЕ ветки измененных данных, и DFS не будет знать какие данные правильные, а просто выберет те, которые последние по времени изменения. Можете себе представить что будет твориться в этой ситуации с файловым хранилищем, или того хуже, с базами данных
  • Ну и стоит отметить то, что репликация открытых файлов может задерживаться на неопределенное время. Самый простой пример - это пользователи, которые не закрывают офисные документы уходя домой.
Все вышеописанное позволяет сказать что DFS лучше всего подходит для передачи данных в филиалы, синхронизации редкоизменяемых данных (приказы, рапоряжения, архивы) и подобных задач. Однако можно поступить чуть хитрее и задействовать DFS, возможно не совсем обычным, но тем не менее полезным способом.

Можно построить на базе DFS своего рода онлайн-реплику, которая не будет работать основное время (а значит бОльшая часть проблем с синхронизацией данных не проявится), и которую можно будет включить, в случае отказа основной реплики.
Выглядеть это может например вот так:
Здесь (на примере папки Department) создано две реплики одной папки, настроена группа репликации и задания репликации (все это делается мастером настройки и не вызовет у вас никаких проблем). Самый смак идеи в том, что одна из ссылок на сервера хранилища - отключена, т.е. реплика есть, репликация между серверами проходит как задано, но пользователи, обращающиеся через DFS в эту папку будут перенаправляться исключительно на первый, активный сервер.

Второй сервер будет реплицировать данные по мере возможности, и будет как бы «на подхвате». В случае какой-то нештатной ситуации, можно будет произвести рокировку и включить линк уже на второй сервер, а линк на первый - выключить и пользователи снова попадут к своим родным данным, которые будут настолько актуальны, насколько DFS-репликация была способна сделать (на практике это от полной актуальности, т.е. состояния 0,5-2 сек давности, до 2-3 дней в случае с открытыми файлами, которые не реплицируются пока не будут закрыты, т.е. разблокированы приложением).

Казалось бы здорово! Срочно побежали делать эту супер-систему! Но кроме всех хороших моментов, есть и не очень хорошие:

  • Потребуется минимум двукратный запас по месту на каждом томе для скрытой папки DfsrPrivate (служебная папка для репликации данных). Учитывая двойные расходы на хранение данных (на обоих серверах хранится одно и то же, причем в один момент времени работают только с одним) это уже не выглядит столь заманчивым, т.к. места под такую отказоустойчивость нужно отвести минимум в 4 раза больше чем самих данных
  • У пользователей иногда могут наблюдаться тормоза в момент работы с DFS. Точных причин мне понять так и не удалось, но всегда это было следствием наличия нескольких реплик, и ненулевой нагрузки на сеть. Как только реплика оставалась одна - тормоза становились исчезающе малы. Это совершенно точно не было связано с работающей репликацией, очень было похоже на какие-то проблемы с резолвингом DFS-имен.
  • Чтобы пользователи увидели новую реплику, на которую вы их переключили в «час Х», им скорее всего придется перегрузить компьютеры, в противном случае они будут пытаться идти по старому пути.
  • Автоматическое переключение на работающую реплику - я не сделал, т.к. стандартных методов для этого нет, а писать чудо-скрипт в ситуации когда сама технология имеет столько минусов, показалось мне безрассудством.
Как видите в описанном примере кроме довольно весомых плюсов. есть также и немаленькие минусы, поэтому расставляйте приоритеты, взвешивайте ЗА и ПРОТИВ, и решайте сами как поступать в вашей конкретной ситуации.

Кстати, по словам знающих, в среде Windows Server 2008 (R2) DFS (и особенно ее служба репликации) была кардинально улучшена, и, возможно, часть проблем была успешно решена. Попробуйте - может быть там предложенная схема будет работать куда лучше.

Продолжение следует.

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

Rsync примеры синхронизации: основное использование

Давайте создадим две директории внутри / tmp, называемые «foo» и «bar», и создадим большое количество фиктивных файлов внутри / tmp / foo

mkdir /tmp/foo /tmp/bar
for i in `seq 1 100`;do touch /tmp/foo/file$i;done

Теперь у нас есть 100 файлов в / tmp / foo; / Tmp / bar все равно не должно быть. Мы можем использовать rsync для копирования всех файлов из / tmp / foo в / tmp / bar:

rsync /tmp/foo/* /tmp/bar

Используя базовое файловое расширение, мы можем захватить все файлы и скопировать их в другой каталог. Что делать, если есть каталог внутри / tmp / foo? Он не будет передан. Нам нужно будет использовать флаг -r (-рекурсивный), чтобы пройти по каталогу, передав каждый файл внутри:

rsync -r /tmp/foo/ /tmp/bar

Это очень простой пример и даже не затрагивает реальную силу команды rsync. Существуют флаги для сохранения разрешений, владельцев, групп, символических ссылок и т. Д. Поскольку эти флаги так часто используются, флаг -a (-archive) действует как псевдоним, чтобы включить их все, включая -r.

Очистите / tmp / bar, создайте символическую ссылку на один файл в / tmp / foo и используйте rsync для рекурсивной копирования всех файлов:

find /tmp/bar -delete
ln -s /tmp/foo/file100 /tmp/foo/file101
rsync -r /tmp/foo/ /tmp/bar

Мы видим, что rsync опустил символическую ссылку, которую мы создали. Снова очистите / tmp / bar, и давайте попробуем еще раз, на этот раз с использованием флага -a:

find /tmp/bar -delete
rsync -a /tmp/foo/ /tmp/bar

Используйте chown для изменения права собственности на файл в / tmp / foo другому пользователю и скопируйте файлы, используя -a to / tmp / bar. Запустите ls -l и обратите внимание, что право собственности перемещено вместе с файлом. Удобный материал!

ПРИМЕЧАНИЕ . Существует разница между включением косой черты (/) в конце пути источника и ее отсутствием; Первый передаст все файлы ВНУТРИ указанного каталога, в то время как последний передаст сам каталог со всеми файлами внутри.

The -a Flag

Как мы и говорили ранее, в этой статье мы разберем Rsync примеры синхронизации и команды. Но для того чтобы их выполнять, нужно знать основы для набора флагов.
Ранее мы упоминали, что флаг -a (-archive) является псевдонимом для набора других флагов -rltpgoD. Сломанный, каждый флаг выполняет следующие действия:

R — Рекурсивный

L — Перенести любые обнаруженные символические ссылки

T — Сохранять метки времени

P — Сохранять разрешения

G — Сохранять группы

O — Сохранять право собственности

D — Сохранение блоков и символьных устройств

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

H — Удобный для чтения формат файлов

Все любят отзывы

Флаг -v (–verbose) даст вам больше информации о состоянии передачи, включая краткое изложение в конце, которое будет выглядеть примерно так:

$ rsync -av foo/ bar
building file list … done
sent 1040 bytes received 20 bytes 2120.00 bytes/sec
total size is 7 speedup is 0.01

Если вы хотите получить больше статистики, запустите rsync с флагом -stats. Это даст вам подробный список общего количества файлов, переданных файлов, контрольных показателей и даже усредненной скорости передачи. С другой стороны, -q (-quiet) будет подавлять весь вывод, который может использоваться для скриптов, когда обратная связь не требуется.

Удаленные передачи сделаны просто

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

rsync @:

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

rsync -avh /tmp/foo/ root@host2:/tmp/bar

Обратите внимание на: (двоеточие) между удаленным сервером и удаленным путем; Это необходимо.

Больше вариантов

Rsync поставляется с большим списком доступных опций, слишком много, чтобы переходить в одну статью. Последними флагами, которые мы рассмотрим, являются флаги -exclude, -exclude-from, -update и -delete

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

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

Обновлять файлы в месте назначения ТОЛЬКО, если исходная копия была изменена совсем недавно

Удалите файлы в месте назначения ТОЛЬКО, если исходная копия больше не существует.

Альтернативные порты SSH

Если вы изменили порт SSH на своем сервере, вам нужно будет указать rsync использовать новый номер порта.

Пример с обычным портом SSH:
rsync -azh /local/path/file [email protected]:/remote/path/file

Пример с альтернативным портом SSH (22334):
rsync -azh /local/path/file -e ‘ssh -p 22334’ [email protected]:/remote/path/file

Удаленные передачи без пароля

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

Если у Вас остались вопросы по теме «Rsync примеры синхронизации» - пишите их в комментарии. Обязательно укажите какую версию операционной системы вы используете, чтобы мы могли помочь с вашим вопросом.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

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

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

Зачем нужен rsync?

Зачем пользоваться rsync если есть привычные cp и scp , спросите вы.

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

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

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

Принцип применения

Если мы говорим о простом копировании файлов, то первым делом всегда стоит сделать пробный прогон (ключ -n) в режиме с показом подробностей (-v):

rsync -avn source example.com:destination

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

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

rsync -av source example.com:destination

В этой команде ключ -a подразумевает рекурсивное копирование всех файлов и каталогов включая их атрибуты, такие как дата создания и дата изменения. Ключ -v даст вам подробный отчет о работе по мере выполнения и по окончании.

Правила копирования каталогов

С одной стороны правила очень простые.

    Если в конце пути до именованного источника нет слеша, то скопируется сам каталог.

    $ rsync -avn path/to/source example.com:destination sending incremental file list source/ source/example.html ...

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

    $ rsync -avn path/to/source/ example.com:destination ^^^ sending incremental file list example.html ... # Что эквивалентно такой команде: $ cd path/to/source; rsync -avn . example.com:destination

С другой стороны вполне можно в пылу забыть что и как, скопировав содержимое каталога вместо самого каталога , получив кучу хлопот с удалением лишних файлов, появившихся из ниоткуда с датами в прошлом (ключик -a , помните?).

Потому лучше всегда следовать обычному сценарию с предварительной проверкой операции.

Некоторые полезные ключи

Сначала поговорим об опциях которые вам будет здорово знать без шпор и шпаргалок.

    Ключ -P включает сразу несколько опций. С этим ключем rsync и покажет процесс копирования отдельных файлов, и продолжит копирование если оно было прервано. Особо эта опция пригождается при копировании больших файлов. Ключ -P нужно указывать каждый раз, иначе rsync удалит файлы которые не успели полностью закачаться.

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

    Если вам хочется знать сколько всего, по мнению rsync, осталось работать, вам нужен ключ --info=progress2 . Если вы копируете целую файловую систему, то этот ключ, будучи использован сам по себе, вас разочарует: информация об итоговом объёме будет постоянно обновляться. Это происходит потому что rsync не пытается считать всю файловую систему до того как начнёт копирование, а делает обе задачи сразу.

    Но не отчаивайтесь! Если вы хотите знать точно сколько осталось работать с самого начала, то можно отключить последовательное сканирование ключём --no-inc-recursive или, короче, --no-i-r .

    $ rsync -ah --partial --info=progress2 --no-i-r source example.com:destination 623.38M 0% 82.23MB/s 0:11:10

    Ключи выше есть начиная с версии 3.1.0, то есть уже работают в Debian stable.

    Если требуется не просто скопировать файлы, а полностью синхронизировать содержимое каталогов, удалив лишние файлы, при этом вам почему-то не с руки синхронизировать файлы с помощью Git , то пригодится ключ --delete (или эквивалентный ему --del).

    С этим ключём rsync удалит лишние файлы из каталого-назначения.

    $ rsync -avn --delete source example.com:destination sending incremental file list deleting source/bad.txt source/ source/test.txt

    Ключ -n в команде выше был оставлен намеренно.

О сжатии замолвим слово

Вопреки популярному заблуждению от использования сжатия внутри rsync (ключ -z) больше вреда, чем пользы. Дело в том что всюду используемый OpenSSH уже с версии конца 2005 года по-умолчанию использует сжатие передаваемых данных. Сами понимаете, сжатие уже сжатых данных только лишь использует ресурсы процессора, не уменьшая объем передаваемых данных.

В том, что при соединении с вашим сервером уже используется сжатие, можно убедиться так:

$ ssh -v [email protected] false 2>&1 | grep compression debug1: Enabling compression at level 6.

Если эта команда не покажет , в числе прочих, такую строчку про включение сжатия как выше, то может быть вам стоит использовать сжатие. Стоит проверить что от сжатия есть толк. Особенно это касается маломощных устройств с быстрым соединением: вашему NAS может быть быстрее скопировать что-то по гигабитному линку без сжатия, чем пытаться обогнать гигабитную сеть маломощным процессором.

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

Копируем частично

Наверняка вам когда-нибудь понадобится чтобы rsync пропускал некоторые файлы при копировании.

В самом простейшем случае вам нужно чтобы rsync не копировал файлы разных систем контроля версий, включая каталог вроде.svn и.git . В этой задаче вам не нужно ничего кроме ключа -C (или --cvs-exclude в полной форме). Так файлы большинства популярных VCS будут проигнорированы будто их нет. Не забываем использовать -n при первом запуске.

rsync -nC example.com:source destination

Может получиться так что вы, по ошибке, скопируете кучу таких файлов от VCS. В этом случае для получения чистой копии вам пригодится ключ --delete-excluded , с которым все исключенные файлы будут удалены.

rsync -nC --delete-excluded example.com:source destination

Исключаем через.rsync-filter

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

$ cat source/.rsync-filter - test.bin - *.tmp - /.cache - /example/ - /**/Trash/ - /.mozilla/firefox/*/Cache/ + Projects/**/Trash/

Для исключения чего-либо из списка на перенос нужно добавить в этот файл строчку с правилом (- или + в начале строки).

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

    # никакой файл test.bin не будет скопирован - test.bin # все файлы.tmp будут пропущены - *.tmp

    Если нужно исключить файл или каталог относительно каталога в котором находится.rsync-filter , то укажем со слешем в начале:

    # не будет скопирован каталог или файл.cache, но будут скопированы foo/.cache и foo/bar/.cache - /.cache # не будет скопирован каталог example, но будет скопирован файл example - /example/

    В правилах звездочка соответствует любым символам кроме слеша, а две звездочки соответствуют вообще любым символам:

    # будут пропущены каталоги.local/share/Trash/ и Documents/example/Trash/ - /**/Trash/ # не будет пропущен каталог.mozilla/firefox/abcd.profile/ext/Cache/ # но будет пропущен каталог.mozilla/firefox/abcd.profile/Cache/ - /.mozilla/firefox/*/Cache/

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

    # каталог Projects/Example/layout/Trash/ будет скопирован + Projects/**/Trash/

Файлы.rsync-filter команда rsync умеет искать по всей структуре каталогов будучи запущена с ключём -F .

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

$ rsync -avFFn source example.com:destination sending incremental file list source/ source/example.html source/tmp/ source/tmp/foo.bin sent 174 bytes received 30 bytes 408.00 bytes/sec total size is 18,400 speedup is 90.20 (DRY RUN)

Как видите, лишние файлы не скопировались:

$ ls source/.rsync-filter source/foo.tmp source/foo.tmp source/.rsync-filter $ cat source/.rsync-filter - *.tmp

Ограничим rsync по ssh

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

Например, вы хотите чтобы можно было скопировать файлы на сервер backup.example.com только с хоста server.example.com , только и только в каталог backup-example , и только с этими опциями:

$ rsync -aW --del source/ backup.example.com:destination/backup-example/

То сначала нужно получить команду, которую rsync выполняет при вызове ssh на удаленном хосте:

$ rsync -e "ssh -t -v" -aW --del source/ backup.example.com:destination/backup-example/ 2>&1 | grep command debug1: Sending command: rsync --server -lWogDtpre.iLsfxC --delete-during . destination/backup-example/

Соответственно, в ~/.ssh/authorized_keys на example.com следует добавить для известного ssh ключа запуск этой команды по-умолчанию при подключении:

from="server.example.com",command="rsync --server -lWogDtpre.iLsfxC --delete-during . destination/backup-example/",no-pty,no-port-forwarding ssh-rsa AAAA... # дальше ваш ключ

Таким образом, даже если при запуске rsync будут указаны какие-то другие опции, на сервере-назначении всё равно выполнится команда rsync соответствующая исходным, заданным вами, опциям и настройкам.

Если нужно чтобы ваш бекап нельзя было перезаписать или удалить на сервере назначения, то опцию --del следует заменить на --ignore-existing .

Машина времени

Те пользователи macOS и OS X, что делают бэкап, наверняка оценили работу Time Machine . Эта программа позволяет буквально в два клика вернуться к прошлой версии любого файла. Не смотря на все красивости, Time Machine не делает ничего такого чего мы не можем сделать с помощью rsync .

#!/bin/bash set -o nounset -o errexit cd $(dirname " $0 " ) date = $(date --iso-8601 = seconds) test -L latest || ln -s " $date " latest rsync --delete-excluded --prune-empty-dirs --archive -F --link-dest = ../latest " $@ " "./ $date " rm latest ln -s " $date " latest

Скрипт следует положить в корень того диска или каталога, куда следует делать бэкапы.

Запускать с указанием единственного аргумента: каталога с исходными файлами. Например, так.

/mnt/backups/backup /home

После нескольких запусков получается такая структура каталога:

2017-02-08T22:05:04+09:00 2017-02-08T22:10:05+09:00 2017-02-08T22:15:05+09:00 2017-02-08T22:20:06+09:00 2017-02-08T22:25:05+09:00 2017-02-08T22:30:04+09:00 latest -> 2017-02-08T22:30:04+09:00

При этом latest указывает на самый последний бэкап.

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

$ du -sh /mnt/backups 4,5M /mnt/backups $ du -sh /home 3,8M /home

Всё множество копий занимает лишь немного больше места чем исходный каталог. Место уходит на изменившиеся файлы.

Если ничего не менялось, то место всё равно расходуется на создание каталогов, которые нельзя хранить как жесткие ссылки .

$ du -hs 2017-02-08T22:20:06+09:00 2017-02-08T22:25:05+09:00 2017-02-08T22:30:04+09:00 3,8M 2017-02-08T22:20:06+09:00 136K 2017-02-08T22:25:05+09:00 136K 2017-02-08T22:30:04+09:00

Такая существенная экономия возможна благодаря упомянутым жестким ссылкам, которые rsync делает для файлов, не изменившихся с последнего копирования.

$ stat -c "%i" 2017-02-08*/example.txt | uniq 31819810

У одинаковых, не менявшихся, файлов будет один и тот же inode.

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