Réponses:
Copie de la source vers la cible où sshd s'exécute:
dd if=/dev/sda | gzip | ssh root@target 'gzip -d | dd of=/dev/sda'
Copie de la source vers la cible via sshd_host lorsque la cible n'exécute pas sshd.
nc -l -p 62222 | dd of=/dev/sda bs=$((16 * 1024 * 1024))
ssh -L 62222:target:62222 sshd_host &
La source: dd if=/dev/sda | nc -w 3 localhost 62222
dd - si = est la source, de = est la destination, bs = est la taille du bloc. Différentes tailles de blocs peuvent améliorer les performances. 16 est généralement un point de départ assez raisonnable. Vous pouvez également utiliser count = pour indiquer le nombre de blocs à copier.
nc - -p indique le port à utiliser pour les services. -l est utilisé pour démarrer un service. -w définit le temps d'attente des données dans la colonne avant de quitter.
ssh - -L configure le tunnel sur l'hôte distant. Le format de l'argument est local_port:target_host:target_port
. Votre programme local (nc) se connecte au local_port, cette connexion est tunnelée et connectée à target_port sur le target_host.
Les options définies ne sont que celles utilisées pour cela. Consultez les pages de manuel pour plus de détails.
Quelques notes:
source machine dd -> nc -> ssh -> ssh tunnel -> sshd server -> nc on target -> dd
Si vous voulez utiliser netcat sans ssh. Je suppose que c'est le moyen le plus rapide et non le plus sécurisé, vous pouvez copier et restaurer le disque entier comme ceci:
Sur l'ordinateur A avec IP 192.168.0.1
cat /dev/hdb | nc -p 9000
Sur l'ordinateur B
nc -l 192.168.0.1 9000 > /dev/hdb
N'oubliez pas que selon man nc, l'option -l est:
-l Utilisé pour spécifier que nc doit écouter une connexion entrante plutôt que d'initier une connexion à un hôte distant. C'est une erreur d'utiliser cette option conjointement avec les options -p, -s ou -z.
netcat n'est pas nécessaire.
sur l'exécution de la machine src:
dd if=/dev/sdX bs=1M | ssh root@dstMachine " dd of=/dev/sdY bs=1M"
je suppose qu'aucune des partitions sur sdX et sdY n'est montée. vous pouvez démarrer les deux boîtes avec knoppix ou une autre distribution live similaire.
dd - prend des données à partir si [si non fourni - il faut partir stdin], envoie des données à des [si non fourni - les données sont envoyées à stdout]. bs - taille de bloc ... accélérera les choses.
ssh - exécute la commande fournie entre guillemets sur la boîte distante, toutes les données pompées vers stdin de ssh seront tunnellisées vers la machine distante et fournies sous forme de stdin pour la commande qui y sera exécutée.
L'hôte A est celui à l'image, l'hôte B est celui sur lequel l'image sera stockée:
root@A# dd if=/dev/sda | ssh root@B "dd of=/some/file"
La restauration sur disque ne ferait qu'échanger ces deux-là.
La copie de base avec netcat est décrite ici .
Si vous avez besoin de faire participer SSH à cela, vous pouvez utiliser la redirection de port par-dessus,
-R [bind_address:]port:host:hostport
Mais, dans l'ensemble, vous pouvez simplement faire le transfert SSH en premier lieu (sans netcat).
Tant que les systèmes de fichiers sont tous deux démontés, dd fonctionne bien.
(from server1) dd if=/dev/sda bs=32k | ssh <server2> dd of=/dev/sda bs=32k
Vous aurez besoin d'une configuration d'authentification par clé hôte à l'avance, sinon l'invite de mot de passe entraînera l'échec de la copie.
Faire cela sur un volume monté produira de mauvais résultats.
Ou, vous pouvez utiliser clonezilla et "monter" votre stockage distant via sshfs.
J'ai essayé une combinaison des options fournies ci-dessus et je partage les résultats avec vous. du plus rapide au plus lent en utilisant des combinaisons de taille de bloc dd, gzip et algorithme de compression gzip.
Comme vous pouvez le voir, gzip ne m'a apporté qu'une amélioration lors de l'utilisation de l'algorithme rapide en conjonction avec une taille de bloc de 1M.
time dd bs=1M if=/dev/HypGroup00/stage-snapshot | gzip --fast | ssh hyp5 'gzip -d | dd bs=1M of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 326.045 s, 39.5 MB/s
time dd if=/dev/HypGroup00/stage-snapshot | gzip --fast | ssh hyp5 'gzip -d | dd of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 370.158 s, 34.8 MB/s
time dd if=/dev/HypGroup00/stage-snapshot | ssh hyp5 dd of=/dev/HypGroup00/stage
12884901888 bytes (13 GB) copied, 370.274 s, 34.8 MB/s
time dd bs=1M if=/dev/HypGroup00/stage-snapshot | ssh hyp5 dd bs=1M of=/dev/HypGroup00/stage
12884901888 bytes (13 GB) copied, 372.906 s, 34.6 MB/s
time dd bs=1M if=/dev/HypGroup00/stage-snapshot | gzip | ssh hyp5 'gzip -d | dd bs=1M of=/dev/HypGroup00/stage'
12884901888 bytes (13 GB) copied, 520.116 s, 24.8 MB/s
Deux serveurs rapides ont été utilisés connectés à GigE via un commutateur Enterprise GigE utilisant des disques locaux via LVM.
On dirait que vous utilisez un marteau pour casser une noix ici - ou peut-être une meilleure analogie est d'essayer de couper votre pelouse avec des ciseaux :)
Je vous suggère fortement de regarder certains des outils disponibles pour faire un travail comme celui-ci, sauf si vous avez de bonnes raisons de le faire en interne.
Trinity Rescue Kit est un liveCD gratuit qui prend en charge les lecteurs d'imagerie par multidiffusion et peut faire ce que vous voulez (ou même toute autre personne qui pense sur la même ligne), sans passer par des systèmes d'imagerie à passage intégral.