Случай простого бекапирования с помощью знаменитого RSYNC

King аватар

Знаменитый RSYNC имеет множество полезных применений. Часто используется полная схема взаимодействия (RSYNC-сервер <===> RSYNS-клиент), но это вовсе не обязательно.

Например, в случае бекапирования данных с локального сервера source.king.org (т.е. где запускается команда rsync) на удалённый сервер target.king.org достаточно использовать лишь RSYNC-клиент.


1. В данном примере мы "толкаем" контент с локального сервера на удалённый:
Сервер-Источник = source.king.org
Сервер-Получатель = target.king.org

  1.  [source.king.org ~]$ rsync -e ssh -avHP    /home   root@target.king.org:/mnt/backup/

-e ssh - копировать по протоколу SSH (этот параметр может быть не обязателен, копирование и так пойдёт по SSH).
Слеш в конце пути получателя обязателен.


2. В данном примере мы "тащим" контент с удалённого сервера на локальный, при этом команду выполняем на локальном:
Сервер-Источник = source.king.org
Сервер-Получатель = target.king.org

  1. rsync -e "ssh -p 30022" -avH   root@target.king.org:/home      /mnt/backup/

Обратите внимание, что в пути источника после каталога /home слеш намеренно не поставлен.
Благодаря этому каталог home на получателе создаётся автоматически.

Но вот что самое интересное - во втором случае клиент rsync должен быть проинсталлирован не только на локальном сервере, что вполне понятно, но и на удалённом сервере, иначе при выполнении данной команды будет выполняться ошибка

  1. bash: rsync: команда не найдена
  2. rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
  3. rsync error: remote command not found (code 127) at io.c(600) [receiver=3.0.6]

Оказывается, что при работе Rsync по протоколу SSH последний запускает на удаленном компьютере копию Rsync с ключом --server , т.е. в режиме сервера.
Следовательно, здесь работа идет так, как если бы на удаленном компьютере запускался Rsync-демон, поэтому и здесь также достигается максимальная производительность, свойственная технологии "клиент-сервер".

Но ни один дятел, описывающий применение rsync, не упомянул этот важный момент.

Ваша оценка: Ничего Средняя оценка: 8.2 (5 votes)

А что значат твой флаги?
я вот использую
ssh -urv /path/ host:/path/
-u - обновить
-r - рекусивно
-v - отобразить процесс

Artur аватар

А добавлю свою инструкцию, она проще, имхо:


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

Пример копирования удалённого каталога на локальную машину:

  1. $ rsync -avz --delete -e ssh логин@удалённый.хост:путь/откуда/ путь/куда

Пример выкладывания локального каталог на удалённую машину:

  1. $ rsync -avz --delete -e ssh путь/откуда/ логин@удалённый.хост:путь/куда

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

  1.    rsync -a /dir1/dir2 /dir3 - будет создана иерархия /dir3/dir2/файлы
  2.    rsync -a /dir1/dir2/ /dir3 - будет создана иерархия /dir3/файлы

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

Можно еще использовать ключ --delete-after, который удаляет исходные файлы только после полного завершения синхронизации.
Этот ключ делает синхронизацию безопаснее, предотвращая возможную потерю данных при обрывах коннекта.
Недостаток — требуется много места для копируемых данных.

Но ни один дятел, описывающий применение rsync, не упомянул этот важный момент.


Точно!
Сегодня тоже столкнулся - с полчаса тупил, потом догадался.

RSS-материал