Si vous êtes heureux de conserver une copie des données sur la machine intermédiaire, vous pouvez simplement écrire un script qui a mis à jour la copie locale en utilisant le serveur1 comme référence, puis a mis à jour la sauvegarde sur le serveur2 en utilisant la copie locale comme référence:
#!/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
L'utilisation d'un script simple signifie que vous avez souhaité une seule commande pour tout faire. Bien sûr, cela pourrait être un non-non de sécurité si les données sont sensibles (vous ou d'autres personnes de votre entreprise, ne voudrez peut-être pas qu'une copie flotte sur votre ordinateur portable). Si server1 est local pour vous, vous pouvez simplement supprimer la copie locale par la suite (car il sera rapide de reconstruire sur le LAN local la prochaine fois).
Construire un tunnel pour que les serveurs puissent communiquer efficacement entre eux plus directement devrait être possible comme ceci:
- Sur le serveur 2, faites une copie de / bin / sh sous / usr / local / bin / shforkeepalive. Utilisez un lien symbolique plutôt qu'une copie, alors vous n'avez pas à le mettre à jour après les mises à jour de sécurité qui corrigent / bin / sh.
Sur le serveur 2, créez un script qui ne fait rien d'autre que de dormir en boucle pendant quelques secondes puis de faire écho à une petite quantité de texte, et utilisez-le maintenant la "copie" de sh:
#!/usr/local/bin/shforkeepalive
while [ "1" != "0" ]; do
echo Beep!
sleep 5
done
(le echon'est probablement pas nécessaire, car la session ne restera pas inactive assez longtemps pour expirer même si SSHd est configuré pour ignorer les paquets persistants du client ssh)
Vous pouvez maintenant écrire un script sur votre ordinateur portable qui démarre votre tunnel inverse en arrière-plan, indique à server1 d'utiliser rsync pour effectuer l'opération de copie, puis tue le tunnel inverse en tuant le script de bouclage (qui fermera la session 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
La façon dont cela fonctionne:
- Ligne 1: marqueur "commande à utiliser pour interpréter ce script" standard
- Ligne 2: démarrez une connexion SSH avec tunnel inverse et exécutez le script keepalive via celui-ci pour le garder ouvert. Le signe de fin et indique à bash de l'exécuter en arrière-plan afin que les lignes suivantes puissent s'exécuter sans attendre la fin
- Ligne 3: démarrez un tunnel qui se connectera au tunnel ci-dessus afin que server1 puisse voir server2 et exécutez rsync pour effectuer la copie / mise à jour sur cet arrangement
- Ligne 4: tuez le script keep-alive une fois l'opération rsync terminée (et donc le deuxième appel SSH revient), qui le fera et la première session ssh.
Cela ne semble pas particulièrement propre, mais cela devrait fonctionner. Je n'ai pas testé ce qui précède, vous devrez peut-être le modifier. Faire de la commande rsync un script sur une seule ligne sur server1 peut aider en réduisant le besoin d'échapper des caractères comme le 'sur la commande ssh appelante.
BTW: vous dites "ne demandez pas" pourquoi les deux serveurs ne peuvent pas se voir directement, mais il y a souvent une bonne raison à cela. Mon serveur domestique et le serveur sur lequel ses sauvegardes en ligne sont conservées ne peuvent pas se connecter les uns aux autres (et ont des mots de passe + clés différents pour tous les utilisateurs) - cela signifie que si l'un des deux est piraté, il ne peut pas être utilisé comme un chemin facile pour pirater l'autre pour que mes sauvegardes en ligne soient plus sûres (quelqu'un malveillant supprimant mes données en direct ne peut pas utiliser sa capacité à mettre à jour les sauvegardes pour supprimer lesdites sauvegardes, car il n'a pas la capacité directe de toucher le site de sauvegarde principal). Les deux serveurs peuvent tous deux se connecter à un serveur intermédiaire ailleurs - le serveur en direct est configuré pour envoyer ses sauvegardes (via rsync) à la machine intermédiaire tôt le matin et le serveur de sauvegarde est défini (un peu plus tard pour permettre à la première étape de se terminer) de se connecter et collecter les mises à jour (à nouveau via rsyc suivi d'une étape d'instantané afin de maintenir plusieurs âges de sauvegarde). Cette technique peut également être utilisable dans votre cas, et si c'est le cas, je la recommanderais comme une façon beaucoup plus propre de faire les choses.
Edit: Fusionner mon hack avec Aaron pour éviter tout le bourdonnement avec des copies de / bin / sh et un script persistant séparé sur server2, ce script sur votre ordinateur portable devrait faire tout le travail:
#!/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'
Comme avec ce qui précède, rsync se connecte à localhost: 2222 qui transmet le tunnel vers l'hôte local de votre ordinateur portable: 2222 qui transmet à travers l'autre tunnel à l'hôte local de server2: 22.
Edit 2: Si cela ne vous dérange pas que server1 ait une clé qui lui permet de s'authentifier directement avec server2 (même s'il ne peut pas voir server2 sans tunnel), vous pouvez simplifier davantage avec:
#!/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'
où 123.123.123.123 est une adresse publique pour server2, qui pourrait être utilisée comme un + liner one-liner au lieu d'un script.