если вы счастливы сохранить копию данных на промежуточной машине, то вы можете просто написать сценарий, который обновил локальную копию, используя 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: стандартная" команда для интерпретации этого скрипта " marker
- строка 2: Запустите соединение SSH с обратным туннелем и запустите сценарий keepalive через него, чтобы сохранить его открытым. Трейлинг & сообщает bash, чтобы запустить это в фоновом режиме, так что следующие строки можно запустить, не дожидаясь его окончания
- строка 3: запустите туннель, который соединится с туннелем выше, чтобы server1 мог видеть server2, и запустите rsync для выполнения копирования / обновления по этому расположению
- строка 4: убейте сценарий keep-alive после завершения операции rsync (и так возвращается второй вызов SSH), который будет и первый сеанс ssh.
это не особо чистые, но это должен работать. Я не тестировал выше, поэтому вам может потребоваться настроить его. Создание команды rsync в одной строке сценария на server1 может помочь, уменьшая необходимость экранировать символы, такие как ' на вызывающей команде ssh.
BTW: вы говорите "Не спрашивайте", почему два сервера не могут видеть друг друга напрямую, но часто есть веская причина для этого. Мой домашний сервер и сервер его онлайн резервного копирования проводятся на не могут войти друг к другу (и имеют разные пароли + ключи для всех пользователей) - это означает, что если один из двух взломан он не может быть использован как легкий путь, чтобы взломать другие так что мой онлайн-архивам безопаснее (кто-то вредоносного удаления моих данных из текущий не может использовать свою способность для обновления резервных копий, удаление заявил резервные копии, так как он не имеет прямой возможности прикоснуться к главной резервной копии сайта). Оба сервера могут подключаться к промежуточному серверу в другом месте-живой сервер настроен на отправку своих резервных копий (через rsync) на промежуточную машину рано утром, а резервный сервер установите (некоторое время спустя, чтобы разрешить шаг один для завершения) для подключения и сбора обновлений (снова через rsyc с последующим шагом snapshotting для поддержания нескольких возрастов резервного копирования). Этот метод может быть полезен и в ваших обстоятельствах, и если это так, я бы рекомендовал его как гораздо более чистый способ делать вещи.
изменить: слияние мой хак с Аарона, чтобы избежать всех возиться с копиями /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, который перенаправляет через другой туннель на localhost server2: 22.
Edit 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, который может быть использован в качестве копии+вставить одну строку вместо сценария.
Komp
3116
