Если вы счастливы сохранить копию данных на промежуточном компьютере, вы можете просто написать сценарий, который обновил локальную копию, используя server1 в качестве ссылки, а затем обновил резервную копию на server2, используя локальную копию в качестве ссылки:
#!/bin/sh
rsync user@server1:/path/to/stuff /path/to/loca/copy -a --delete --compress
rsync /path/to/loca/copy user@server2:/path/to/where/stuff/should/go -a --delete --compress
Использование простого сценария означает, что вам нужна единственная команда, чтобы сделать все. Конечно, это может быть защита «нет-нет», если данные конфиденциальны (вы или другие сотрудники вашей компании, возможно, не захотите, чтобы копия была на вашем ноутбуке). Если server1 является локальным для вас, вы можете просто удалить локальную копию впоследствии (так как в следующий раз будет легко восстановить по локальной сети).
Построение туннеля, чтобы серверы могли более эффективно общаться друг с другом, должно быть возможно следующим образом:
- На сервере 2 сделайте копию /bin /sh как /usr /local /bin /shforkeepalive. Используйте символическую ссылку, а не копию, тогда вам не нужно обновлять ее после обновлений безопасности, исправляющих /bin /sh.
На сервере 2 создайте сценарий, который выполняет только цикл ожидания в течение нескольких секунд, а затем выводит небольшое количество текста, и использует для этого теперь "копию" sh:
#!/usr/local/bin/shforkeepalive
while [ "1" != "0" ]; do
echo Beep!
sleep 5
done
(echo вероятно, не требуется, так как сеанс не будет простаивать достаточно долго для тайм-аута, даже если SSHd настроен на игнорирование пакетов keep-alive от клиента ssh)
Теперь вы можете написать скрипт на своем ноутбуке, который запускает обратный туннель в фоновом режиме, говорит server1 использовать rsync для выполнения операции копирования, а затем убивает обратный туннель, убивая зацикленный скрипт (который закроет сеанс SSH):
#!/bin/sh
ssh user@server2 -L2222:127.0.0.1:22 /usr/local/bin/keepalivesctipt &
ssh user@server1 -R2222:127.0.0.1:2222 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
ssh user@server2 killall shforkeepalive
Как это работает:
- Строка 1: стандартная команда "использовать для интерпретации этого сценария"
- Строка 2: запустить SSH-соединение с обратным туннелем и запустить через него скрипт keepalive, чтобы он оставался открытым. Трейлинг & указывает bash запустить его в фоновом режиме, чтобы следующие строки могли выполняться, не дожидаясь его завершения
- Строка 3: запустите туннель, который будет подключаться к туннелю выше, чтобы server1 мог видеть server2, и запустите rsync, чтобы выполнить копирование / обновление по этой схеме
- Строка 4: уничтожить скрипт keep-alive после завершения операции rsync (и, таким образом, возвращается второй вызов SSH), что и первый сеанс ssh.
Это не кажется особенно чистым, но это должно работать. Я не проверял вышеизложенное, поэтому вам может понадобиться настроить его. Создание команды rsync в виде однострочного сценария на сервере server1 может помочь, уменьшив необходимость в экранировании таких символов, как 'в вызывающей команде ssh.
Кстати: вы говорите «не спрашивайте», почему два сервера не могут видеть друг друга напрямую, но для этого часто есть веская причина. Мой домашний сервер и сервер, на котором хранятся его резервные копии в онлайн-хранилище, не могут войти друг в друга (и имеют разные пароли + ключи для всех пользователей) - это означает, что если один из двух файлов взломан, он не может использоваться в качестве простого маршрута к взломайте другой, чтобы мои резервные копии в Интернете были безопаснее (кто-то, кто удаляет мои данные из живого хранилища, не может использовать его для обновления резервных копий, чтобы удалить указанные резервные копии, поскольку у него нет прямой возможности доступа к основному сайту резервного копирования). Оба сервера могут подключаться к промежуточному серверу где-либо еще - живой сервер настроен на передачу своих резервных копий (через rsync) на промежуточную машину рано утром, а резервный сервер настроен (через некоторое время, чтобы завершить первый шаг) для подключения и собирать обновления (снова через rsyc с последующим шагом моментального снимка для сохранения нескольких возрастов резервного копирования). Эта техника может быть полезна и в ваших обстоятельствах, и в этом случае я бы порекомендовал ее как более чистый способ ведения дел.
Редактировать: объединяя мой взлом с Аароном, чтобы избежать всего этого с копиями /bin /sh и отдельным скриптом keep-alive на server2, этот скрипт на вашем ноутбуке должен делать всю работу:
#!/bin/sh
ssh user@server2 -L2222:127.0.0.1:22 sleep 60 &
pid=$!
trap "kill $pid" EXIT
ssh user@server1 -R2222:127.0.0.1:2222 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
Как и в предыдущем примере, rsync подключается к localhost:2222, который переходит вниз по туннелю к localhost вашего ноутбука:2222, который пересылает через другой туннель к local2 сервера server2:22.
Редактировать 2: Если вы не возражаете против наличия у server1 ключа, который позволяет ему проходить аутентификацию на сервере server2 напрямую (даже если он не видит server2 без туннеля), вы можете еще больше упростить:
#!/bin/sh
ssh user@server1 -R2222:123.123.123:22 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
где 123.123.123.123 - это общедоступный адрес для server2, который можно использовать как однострочник копирования + вставки вместо скрипта.
