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

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

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

Для этих целей есть unix утилита Rsync, которая позволяет быстро выполнить синхронизацию новых файлов в различных директориях.

Синтаксис команд

Как правило утилита уже установлена на множестве хостингах и запускается в консоле через SSH. Команды выполняется по следующему синтаксису:

rsync -опции исходная_директория/ директория_назначения

В конце исходной директории стоит слеш, чтобы обрабатывалась сама директория и всё её содержимое.

Основные опции

Синхронизация в рамках одного хостинга

Если два сайта находятся на одном хостинге, задача упрощается т.к. файлы обеих сайтов находятся в одном дисковом пространстве. Остается только узнать полные пути до директорий и выполнить копирование новых файлов из /home/example.ru/uploads в /home/example.com/uploads

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

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

Синхронизация файлов с удаленным хостом

Для синхронизации файлов на разных хостингах, rsync должен быть установлен на обоих серверах, в команде указывается логин и адрес хоста:

rsync -опции /исходная_директория/ имя_пользователя@адрес:директория_назначения

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

Пример:

Синхронизация в обе стороны:

Синхронизация по крону

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

При работе с удалёнными хостами по SSH потребуется настроить авторизацию по ключу.

WebDAV

WebDAV (Web Distributed Authoring and Versioning) или просто DAV — набор расширений и дополнений к протоколу HTTP, поддерживающих совместную работу пользователей над редактированием файлов и управление файлами на удаленных веб-серверах. В качестве миссии рабочей группы по созданию DAV было заявлено: «разработка дополнений к протоколу HTTP, обеспечивающих свободное взаимодействие инструментов распределённой разработки веб-страниц, в соответствии с потребностями работы пользователей». Однако в процессе эксплуатации DAV нашёл себе ряд других применений, выходящих за первоначально принятые рамки коллективной работы над веб-документами. Сегодня DAV применяется в качестве сетевой файловой системы, эффективной для работы в Интернете и способной обрабатывать файлы целиком, поддерживая хорошую производительность работы в условиях окружения с высокой временной задержкой передачи информации. Кроме того, DAV широко применяется в качестве протокола для доступа через Интернет и манипулирования содержимым систем документооборота (document management system). Ещё одной важной целью DAV является поддержка работы распределённых команд по разработке программного обеспечения. В качестве резюме задачу создания DAV можно указать так: на волне повсеместного использования HTTP в качестве стандартного уровня доступа к широкому кругу хранилищ информации расширить его возможности средствами записи информации (HTTP — доступ на чтение, DAV — доступ на запись).

Содержание

Основные возможности [ править | править код ]

• Блокировка — долгосрочные блокировки на запись документа предотвращают потерю информации при одновременном редактировании документа несколькими пользователями. Учитывая характер Интернет-соединений пользователей, длительность блокировки в DAV не зависит от индивидуального сетевого соединения.
• Свойства — произвольные метаданные могут храниться в качестве свойств, описанных на языке XML. В качестве примера можно привести список авторов документа или его краткую аннотацию. Протокол DAV предоставляет средства для создания, редактирования и удаления свойств. Протокол DASL или DAV Searching and Locating предоставляет средства поиска и локализации веб-ресурсов на основе значения их свойств.
• Именованные области(Namespace) — раздел DAV, поддерживающий переименование и перемещение веб-ресурсов. Механизм реализован в протоколе с помощью коллекций, выполняющих функцию, аналогичную папкам в файловой системе.

Особенности [ править | править код ]

• Выполнение основных файловых операций над объектами на удаленном сервере;
• Выполнение расширенных файловых операций (блокировки, поддержка версий);
• Работа с любым типом объектов (не только файлы);
• Работа с метаданными;
• Поддержка одновременной работы над несколькими объектами.

Используется для совместной работы над удаленными файлами, являясь заменой для FTP и SMB.

Синхронизация через WebDAV в Яндекс.Диске

На прошлой неделе Яндекс.Диску исполнился год, и за этот год сервисом успели воспользоваться уже больше 8 000 000 пользователей.

А сейчас мы продолжаем рассказывать о том, сколько усилий понадобилось, чтобы всё это стало возможным. Недавно мы писали о том, как и почему команда Яндекс.Диска выбрала WebDAV [1] для синхронизации десктоп-клиентов с сервером и начала работу над прототипом клиента Яндекс.Диска. Сегодня, как и обещали, — о том, как всё работает с серверной стороны.

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

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

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

Перед отправкой файла на сервер клиент считает хэш. Дальше он заливает файл методом PUT, сообщая серверу этот хэш в HTTP-заголовке Etag. При получении такого запроса сервер сохраняет размер заливаемого файла и его md5 в специальную таблицу незавершённых заливок. В случае нормальной заливки всего содержимого на сервере вычислется md5 полученного файла и сравнивается с полученным от клиента — при их совпадениях файл принят верно и его можно сохранять.

В случае проблем с соединением — если оно было закрыто или при длительном таймауте — на сервере необходимо было сохранить в таблице реально принятый размер и залогировать в access.log неудачно завершённый запрос. Мы использовали в качестве фреймворка веб-сервера mochiweb [2] и в процессе обработки проблем с обрывами соединений встретились с его особенностями. На любые ошибки библиотека реагировала вызовом ‘exit(normal)`, что означает «тихое» завершение процесса. Это нормально, если перед нами стоит nginx для логирования запросов и если при подобном завершении соединения ничего делать не надо. Конечно, можно перехватить такое исключение. Но понять, какая именно из возможных проблем случилась, мы в таком случае можем разве что по наличию известных функций в стектрейсе. Нормальным этот метод не назовёшь, поэтому пришлось править библиотеку на предмет выдачи более вменяемых ошибок.

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

Кроме просто докачки файлов, мы захотели накладывать бинарные патчи файлов — дельта-обновления, — так, как это делается в rsync, но минимизируя нагрузку от этих операций на сервере. Мы разбиваем файл на блоки, по которым считаются быстрые и стойкие сигнатуры. Метод вычисления быстрых сигнатур — rolling checksum — мы позаимствовали из rsync [3] . Сигнатуры блоков используются для поиска совпадающих частей файла, которые пересылать по сети не требуется. Комбинацию из размера блока, сигнатур и md5-файла мы называем дайджестом файла. Для того чтобы клиент смог определить, какие части обновлённого файла ему необходимо скачать или отправить на сервер, ему необходимо получить дайджест файла, хранящегося на сервере. Для этого опять пришлось расширить протокол — на этот раз методом получения дайджеста.

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

Для начала мы попробовали считать дайджесты во время стриминга файлов в Erlang. Казалось, это уменьшит накладные расходы: порция данных уже лежит в памяти и передать её в модуль расчёта дайджеста выглядело дешёвым решением. К сожалению, из-за специфики работы с памятью в Erlang, это оказалось не так: данные копировались в драйвер, считавший хэши, промежуточные результаты копировались обратно в процесс-обработчик, а затем всё опять отправлялось в драйвер. Это оказалось чересчур ресурсоёмким. Разрабатывать специализиованный драйвер, который хранил бы всё промежуточное состояние внутри и не передавал бы его обратно в Erlang, не хотелось. Альтернативным решением стало складывать файл на диск как обычно, а дайджест считать после полного получения файла отдельной программой, написанной на C и запускаемой из Erlang как порт. Мы использовали этот подход и сократили время на расчёт дайджеста в 10 раз.

Для дельта-обновлений на сервере был расширен стандартный метод PUT, который принимает бинарный дифф и накладывает его на исходный файл. В таком диффе определены лишь две команды: скопировать часть исходного файла и вставить часть, пришедшую от клиента. Сервер занимается лишь простыми операциями, а весь тяжёлый анализ изменений в файлах находится на стороне клиента.

Для случаев, когда файл обновился на сервере, применяется тот же алгоритм поиска одинаковых частей. Клиенту могут потребоваться и несколько частей одного файла, поэтому мы поддержали запросы с указанием множества Range-ей, когда ответ приходит в виде multipart/byteranges, чтобы снизить количество обращений к метаданным файла.

Ещё один метод, который нужен для синхронизации — получить диффы дерева файлов, чтобы клиент мог определить, какие файлы успели обновиться на сервере. Эта задача отличается от обычного версионирования, поэтому методы, предлагаемые стандартом, нам не подошли, и пришлось ещё раз расширить протокол. Когда клиент хочет обновить файлы, он вызывает этот новый метод, указывая идентификатор имеющейся у него синхронизированной версии. А сервер отвечает идентификатором последней версии и списком изменений, произошедших в файловой структуре (не в самих файлах) с момента последнего обновления. Для этого мы храним историю всех изменений в файловой структуре для каждого пользователя.

Пожалуй, за исключением некоторых мелочей, это всё, чем занимается WebDAV-сервер в Яндекс.Диске. Мы довольны тем, что выбрали именно этот протокол. С одной стороны, он практически «из коробки» отвечал нашим нуждам и не требовал существенных доработок, а с другой — благодаря нему с Яндекс.Диском легко интегрировать многие утилиты и приложения.

GoodSync — больше чем просто синхронизация

Я уже писал о хорошей и надежной программе для синхронизации FreeSync , которая с недавнего времени начала предлагать платные функции (например, уже официальным способом нельзя установить портативную версию) . Сегодня хочется поговорить о другой программе для синхронизации и резервного копирования — GoodSync . Начиная с 10 версии программа обзавелась новыми возможностями и изменила к лучшему (по моему мнению ) свой интерфейс. Стало возможным объединять задачи синхронизации в группы — весьма полезная функция, которой не хватало. При нескольких задачах группы действительно не нужны, а вот когда задач уже более десятка — их хочется объединить в группы для удобного управления .

Программа действительно уникальная и найти ей аналог , возможно и не получится. Поддерживается синхронизация между дисками, внешними носителями , по FTP , между различными сервисами ( ЯднексДиск , OneDrive , Google drive и другими), между устройствами .

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

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

Следующим этапом будет запуск сервера на компьютере. Он необходим для синхронизации между компьютером и мобильными устройствами ( телефонами , планшетами ) . Для этого выбираем « Да , соединить мои компьютеры с использованием GoodSync Connect».

Нажимаем «Далее» и попадаем в окно , в котором нужно создать учетную запись (при условии, если ее у вас еще нет ) . Поэтому выбираем «Создать учетную запись GoodSync Connect » и заполняем поля :

Нажимаем «Далее» и вводим пароль входа в аккаунт Windows.

Еще раз «Далее» и применить «Apply».

Открываем программу и создаем новую группу , нажав на значок + , называем ее .

Добавим к нашей группе задание , нажав на значок + , назовем его .

На следующем этапе нужно выбрать данные (папки ) для синхронизации между левой ( указываем папку для левой стороны) и правой ( указываем папку для правой стороны ).

Рассмотрим синхронизацию между папками , которые находятся на компьютере , флешке или съемном диске. Выберем на левой стороне «Мой Компьютер ».

Далее диск и папку на диске.

В результате получим пути к папкам :

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

Нажав на «Опции» мы попадем в настройки нашей задачи синхронизации. Можно выбрать в « Основных настройках » будет ли это синхронизация или просто резервное копирование с правой на левую или с левой на правую сторону и другие нужные параметры .

Можно воспользоваться фильтрами. На вкладке «Авто » задать способ синхронизации , например при старте программы .

Отдельные настройки можно задать для левой и правой сторон . Например , можно не создавать папку gsdata . Этой опцией можно воспользоваться если на диске мало места ( в папку gsdata копируются все удаленные в процессе синхронизации файлы). Именно с нее их и можно восстановить в случае «неправильной» синхронизации .

Отдельно хочется сказать о фильтрах . Можно в опциях на вкладке «Фильтры » вписывать имена папок или файлов вручную , а можно проще добавить к фильтру тот или иной файл/ папку. Для этого после анализа изменений просто вызываем контекстное меню на нужном файле или папке и выбираем « Исключить файл» (если файл нужно исключить из синхронизации. Если его нужно включить, то выбираем соответственно опцию включить ) → «название файла ». Кроме того можно работать с расширенными фильтрами , например, выбрав исключить из синхронизации все файлы '*.exe' — мы исключим все файлы , которые имеют расширение .exe.

После таких действий исключенные / включенные в синхронизацию файлы можно увидеть в «Фильтрах» зайдя в «Опции» .

Нажимаем «Синхронизация» для начала синхронизации.

Смотрим на результат.

Для примера я удалил один файл. Программа сразу предлагает внести изменения с противоположной стороны. GoodSync сразу же показывает изменения и действие , которое будет выполнено при нажатии кнопки « Синхронизация » .

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

Рассмотрим синхронизацию между телефоном и компьютером . Для этого создадим новую категорию и задачу.

На телефон нужно установить бесплатный GoodSync Server for Android, ввести логин и пароль от учетной записи, которую мы создали в начале установки программы GoodSync.

И запустить его.

Выбираем на правой стороне «GoodSync Connect».

И папку в памяти телефона или на карте SD.

Нажимаем « Анализ » и « Синхронизация ». Далее все так же , как описано выше в статье .

Для синхронизации между компьютером и облачным хранилищем в качестве левой папки указываем папку на ПК , а в качестве правой — выбираем свой облачный сервис (например google drive ) , вводим свой логин и пароль. Откроется окно для подтверждения своих действий — нажимаем «Разрешить » и проводим синхронизацию .

Программа очень полезна для ручной и автоматической синхронизации, поскольку перед синхронизацией можно увидеть, не будут ли удалятся важные данные. А вот резервное копирование такими программами как, например, Acronis True Image и ей подобными может в случае сбоя жесткого диска привести к плачевным последствиям. Как раз у меня, так и произошло. Программа архивировала важные данные в папку DropBox, а они с нее соответственно попадали в облако. Произошел сбой диска и все файлы стали иметь размер 0 байт. Соответственно с таким размером они попали в архив, который создала программа Acronis True Image. Таким образом, пропали файлы на диске и в архиве. Этого не произошло бы, если бы я выполнял ручную синхронизацию с помощью GoodSync. Потому что нулевой размер файлов не трудно было бы заметить.

Бесплатная версия программы имеет ограничения в 100 файлов . Кто убедилися в замечательных возможностях программы может приобрести платную версию . Магазин лицензионного ПО Украина или Россия .