Meilleure compression pour les envois/récupérations ZFS

Mon expérience est que zfs send est assez rapide, même si elle est beaucoup plus rapide (en moyenne) que l'étape de compression suivante. Ma sauvegarde insère une mise en mémoire tampon considérable après zfs send et plus encore après gzip :

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

Dans mon cas, le périphérique de sortie est connecté en USB (et non en réseau), mais la mise en mémoire tampon est importante pour une raison similaire : Le temps de sauvegarde global est plus rapide lorsque le lecteur USB est occupé à 100%. Il se peut que vous n'envoyiez pas moins d'octets dans l'ensemble (comme vous le demandez), mais vous pouvez tout de même terminer plus rapidement. La mise en mémoire tampon empêche l'étape de compression liée au CPU de devenir liée à l'IO.

Pour ce que ça vaut. Je ne ferais pas un envoi direct | compresser | décompresser | recevoir cela peut conduire à des problèmes à l'extrémité de réception si la ligne de transfert se casse et vos piscines seront hors ligne pendant un long moment pendant la réception. Nous envoyons vers un fichier local, puis nous compressons l'instantané et le transférons en utilisant rsync (avec Riverbed), puis nous recevons à partir du fichier. Le riverbed n'optimise pas le trafic, mais s'il y a un problème avec le transfert et qu'il doit être relancé, le riverbed accélère le renvoi.

Nous avons envisagé de ne pas compresser l'instantané incrémentiel, d'utiliser la compression Rsync et de n'utiliser aucune compression autre que le lit de rivière. Il est difficile de dire ce qui est le mieux, mais lorsque nous transférons des archives d'oracle avec la compression Rsync, le taux de transfert est environ deux fois supérieur à celui des fichiers ordinaires et de Riverbed (avec RSync).

Si vous disposez d'un riverbed, utilisez rsync et non ssh, car le riverbed comprend rsync et essaiera de l'optimiser et d'ajouter les données au cache (voir ci-dessus, redémarrage des transferts).

Vous pouvez choisir un chiffrement plus rapide pour ssh, peut-être blowfish-cbc, essayez aussi les commutateurs -123456789.

-1 (or --fast) to -9 (or -best)

Le "meilleur" algorithme de compression dépend du type de données que vous avez. Si vous mettez en ligne une collection de MP3, la compression ralentira probablement le processus, alors que les fichiers texte/log peuvent être considérablement compressés avec gzip -9 .

Quel est le volume de données que vous transmettez chaque jour ?

Je suppose que vous ne pouvez tout simplement pas augmenter la bande passante brute de votre site...

Il peut être avantageux de ne pas utiliser la compression sur l'hôte.

Si vous utilisez quelque chose comme un optimiseur wan, il sera capable d'optimiser le transfert beaucoup mieux si vous Ne le fais pas. compresser le fichier avant de l'envoyer, c'est-à-dire faire exactement ce que vous faites mais enlever le bzip2 du tuyau. Après quelques exécutions de votre sauvegarde, l'optimiseur wan aura mis en cache une très grande partie de ce qu'il voit dans le transfert et vous verrez d'énormes améliorations dans les vitesses de transfert.

Si vous avez un budget limité, vous pouvez mai Vous pourrez constater une amélioration similaire en utilisant rsync et en rsynchronisant l'ensemble des données. non compressé instantané, c'est-à-dire :

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

Cela serait plus rapide car rsync ne transférerait que les différences entre l'instantané d'hier et celui d'aujourd'hui. Selon la façon dont le processus d'instantanéisation fonctionne, il peut encore y avoir beaucoup de redondance entre les deux, même s'il ne s'agit pas vraiment du même fichier.

L'optimiseur wan est de loin le moyen le plus probable de résoudre ce problème (en fait, l'Ethernet métropolitain est le moyen le plus efficace). le plus Il s'agit là d'un autre moyen probable de résoudre ce problème, mais nous n'en parlerons pas). Le rsync n'est qu'un coup d'essai qui vaut la peine d'être testé (localement ; rsync vous dira combien de temps il a fait gagner par rapport à une copie directe) sur vos données locales avant de signer le gros chèque pour la fibre ou une installation sur lit de rivière.