Quelles sont les meilleures techniques pour améliorer rsync sur la mise en miroir ssh entre les boîtes Unix, en supposant qu'un système aura toujours la copie principale et l'autre système aura toujours une copie récente (moins de 48 heures)
De plus, que faudrait-il faire pour faire évoluer cette approche afin de gérer des dizaines de machines pour obtenir une poussée de ces changements?
Réponses:
Si :
Vous pouvez utiliser find -ctimeou file -cnewerpour faire une liste des fichiers modifiés depuis la dernière exécution, et copier uniquement les fichiers modifiés (juste une poussée différentielle glorifiée).
Cela s'est traduit assez bien pour plusieurs hôtes: il suffit de faire un tar différentiel sur la source et de le décompresser sur tous les hôtes.
Cela vous donne quelque chose comme ça:
find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt
for HOST in host1 host2 host3 ...
do
cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done
Le script doit être affiné, mais vous avez l'idée.
En supposant que les données que vous rsynchronisez ne sont pas déjà compressées, l'activation de la compression (-z) contribuera probablement à la vitesse de transfert, au prix d'un processeur à chaque extrémité.
Si vous transférez des fichiers très volumineux avec beaucoup de changements, utilisez les options --inplace et --whole-file, je les utilise pour mes images de machine virtuelle 2 Go et cela m'a beaucoup aidé (principalement car le protocole rsync ne faisait pas grand-chose). en passant des données incrémentielles avec ces fichiers). Je ne recommande pas ces options dans la plupart des cas.
utilisez --stats pour voir dans quelle mesure vos fichiers sont transférés à l'aide du protocole incrémentiel rsync.
Une autre stratégie consiste à accélérer ssh et rsync. Si vous passez sur un réseau de confiance (lire: privé), le cryptage de la charge utile réelle n'est pas nécessaire. Vous pouvez utiliser HPN ssh . Cette version de ssh ne chiffre que l'authentification. De plus, rsync version 3 commence à transférer des fichiers lors de la création de la liste de fichiers. Bien sûr, c'est un énorme gain de temps par rapport à la version 2 de rsync. Je ne sais pas si c'est ce que vous cherchiez, mais j'espère que cela vous aidera. En outre, rsync prend en charge la multidiffusion d'une manière ou d'une autre, bien que je ne prétende pas comprendre comment.
Lorsque vous effectuez une synchronisation en tant que méthode de sauvegarde, le plus gros problème que vous rencontrerez sera si vous avez beaucoup de fichiers que vous sauvegardez. Rsync peut gérer des fichiers volumineux sans problème, mais si le nombre de fichiers que vous sauvegardez devient trop volumineux, vous remarquerez que la rsync ne se terminera pas dans un délai raisonnable. Si cela se produit, vous devrez diviser la sauvegarde en parties plus petites, puis boucler sur ces parties, par exemple
find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/
ou en tarant l'ensemble de fichiers pour réduire le nombre de fichiers.
Quant à avoir des dizaines de machines qui ont un miroir de ces changements, cela dépend de la fraîcheur de la sauvegarde. Une approche consisterait à refléter les modifications du serveur principal vers le serveur de sauvegarde, puis à demander aux autres serveurs de retirer leurs modifications du serveur de sauvegarde soit par un démon rsync sur le serveur de sauvegarde initial, soit en programmant les autres serveurs pour tirer légèrement à différents moments ou en utilisant un script, utilisez ssh sans mot de passe pour vous connecter à chacun des serveurs et dites-leur de tirer une nouvelle copie de la sauvegarde, ce qui éviterait de surcharger votre serveur de sauvegarde initial - mais le fait que vous rencontriez autant de problèmes dépendra sur le nombre d'autres machines dont vous disposez pour extraire une copie de la sauvegarde.
find /Backup/ -name '*.bak' -print0 | xargs -0 -n 1 rsync -e ssh?
rsync a un moyen de faire des copies déconnectées . En d'autres termes, rsync peut (conceptuellement) différencier une arborescence de répertoires et produire un fichier correctif que vous pourrez ensuite appliquer à n'importe quel nombre de fichiers identiques à la source d'origine.
Cela nécessite que vous appeliez rsync avec le maître et miroir avec --write-batch; il produit un fichier. Vous transférez ensuite ce fichier vers un certain nombre d'autres cibles, puis vous appliquez le lot à chacune de ces cibles à l'aide --read-batch.
Si vous conservez une copie locale du dernier état rsynced (c'est-à-dire une copie de ce à quoi ressemblent les miroirs en ce moment) sur la même machine que le maître, vous pouvez générer ce "patch" sur le maître sans même contacter aucun miroir:
Sur le maître:
rsync --write-batch=my-batch.rsync /master/data /current/mirror
Ajoutez toutes les autres options que vous souhaitez. Cela fera deux choses:
/current/mirrorchangements pour refléter/master/datamy-batch.rsyncpour une utilisation ultérieure.Transférez le my-batch.rsyncfichier du maître vers tous vos miroirs, puis sur les miroirs, appliquez le patch pour ainsi dire:
rsync --read-batch=my-batch.rsync /local/mirror
Avantages de cette approche:
--read-batchque le processeur n'est intensif que sur le miroir lui-même)