Solution 1 :
rsync --ignore-existing --sparse ...
Pour créer de nouveaux fichiers en mode sparse
Suivi de
rsync --inplace ...
Pour mettre à jour tous les fichiers existants (y compris les fichiers épars précédemment créés) sur place.
Solution 2 :
Rsync ne transfère que les modifications à chaque fichier et avec --inplace ne devrait réécrire que les blocs qui ont changé sans recréer le fichier. À partir de leur page de fonctionnalités.
rsync est un programme de transfert de fichiers pour les systèmes Unix. rsync utilise "l'algorithme rsync" qui fournit une méthode très rapide pour synchroniser les fichiers distants. Pour ce faire, il envoie uniquement les différences dans les fichiers via le lien, sans exiger que les deux ensembles de fichiers soient présents à l'une des extrémités du lien au préalable.
L'utilisation de --inplace devrait fonctionner pour vous. Cela vous montrera la progression, compressera le transfert (au niveau de compression par défaut), transférera le contenu du répertoire de stockage local de manière récursive (cette première barre oblique finale compte), apportera les modifications aux fichiers en place et utilisera ssh pour le transport.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
J'utilise aussi souvent le drapeau -a qui fait quelques choses de plus. Cela équivaut à -rlptgoD. Je vous laisse le comportement exact à rechercher dans la page de manuel.
Solution 3 :
Jetez un œil au projet de stockage Linux Zumastor, il implémente une sauvegarde "instantanée" en utilisant le binaire "rsync" via le ddsnap outil.
À partir de la page de manuel :
ddsnap fournit une réplication de périphérique de bloc grâce à une fonction d'instantané au niveau du bloc capable de conserver efficacement plusieurs instantanés simultanés. ddsnap peut générer une liste de blocs d'instantanés qui diffèrent entre deux instantanés, puis envoyer cette différence sur le câble. Sur un serveur en aval, écrivez les données mises à jour sur un périphérique de bloc instantané.
Solution 4 :
J'ai fini par écrire un logiciel pour faire ça :
http://www.virtsync.com
Il s'agit d'un logiciel commercial qui coûte 49 USD par serveur physique.
Je peux maintenant répliquer un fichier fragmenté de 50 Go (qui contient 3 Go de contenu) en moins de 3 minutes sur le haut débit résidentiel.
[email protected]:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
Solution 5 :
Pour synchroniser des fichiers volumineux ou des périphériques de bloc avec des différences faibles à modérées, vous pouvez soit faire une copie simple, soit utiliser bdsync, rsync n'est absolument pas adapté à ce cas particulier*.
bdsync a fonctionné pour moi, semble assez mature, son historique de bogues est encourageant (petits problèmes, résolution rapide). Lors de mes tests, sa vitesse était proche du maximum théorique que vous pouviez obtenir ** (c'est-à-dire que vous pouvez synchroniser à peu près le temps dont vous avez besoin pour lire le fichier). Enfin c'est open source et ça ne coûte rien.
bdsync lit les fichiers des deux hôtes et échange des sommes de contrôle pour les comparer et détecter les différences. Tout cela en même temps . Il crée enfin un fichier de correctif compressé sur l'hôte source. Ensuite, vous déplacez ce fichier vers l'hôte de destination et exécutez bdsync une seconde fois pour corriger le fichier de destination.
Lors de son utilisation sur une liaison assez rapide (par exemple Ethernet 100Mbit) et pour les fichiers avec de petites différences (comme c'est le plus souvent le cas sur les disques VM), cela réduit le temps de synchronisation au temps dont vous avez besoin pour lire le fichier. Sur une liaison lente, vous avez besoin d'un peu plus de temps car vous devez copier les modifications compressées d'un hôte à l'autre (il semble que vous puissiez gagner du temps en utilisant une astuce intéressante mais que vous n'avez pas testée). Pour les fichiers comportant de nombreuses modifications, le temps d'écriture du fichier de correctif sur le disque doit également être pris en compte (et vous avez besoin de suffisamment d'espace libre sur les deux hôtes pour le contenir).
Voici comment j'utilise généralement bdsync. Ces commandes sont exécutées sur $LOCAL_HOST pour "copier" $LOCAL_FILE à $REMOTE_FILE le $REMOTE_HOST . J'utilise pigz (un gzip plus rapide ) pour compresser les modifications, ssh pour exécuter bdsync sur l'hôte distant et rsync /ssh pour copier les modifications. Notez que je vérifie si le correctif a été appliqué avec succès, mais j'imprime uniquement "Mise à jour réussie" lorsque c'est le cas. Vous voudrez peut-être faire quelque chose de plus intelligent en cas d'échec.
REMOTE_HOST=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_HOST bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_HOST:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_HOST <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_HOST touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
* :rsync est extrêmement inefficace avec des fichiers volumineux. Même avec --inplace, il lira d'abord l'intégralité du fichier sur l'hôte de destination, APRÈS commencer à lire le fichier sur l'hôte source et enfin transférer les différences (exécutez simplement dstat ou similaire tout en exécutant rsync et observez). Le résultat est que même pour les fichiers avec de petites différences, il faut environ le double de temps pour lire le fichier afin de le synchroniser.
** :En supposant que vous n'ayez aucun autre moyen de savoir quelles parties des fichiers ont été modifiées. Les instantanés LVM utilisent des bitmaps pour enregistrer les blocs modifiés afin qu'ils puissent être extrêmement plus rapides (le fichier readme de lvmsync contient plus d'informations).