Pourquoi les gens n'utilisent-ils pas simplement rsync pour sauvegarder les invités vmware?

12

Si j'utilise un système vmware ESXi moderne, je peux déposer des fichiers binaires et rsync liés statiquement vers n'importe quelle destination via SSH.

J'essaie de comprendre pourquoi la plupart (toutes?) De la sauvegarde des invités vmware ne se fait pas de cette façon.

Si la machine virtuelle est en cours d'exécution, vous pouvez simplement utiliser «vim-cmd vmsvc / snapshot.create» pour créer un instantané, puis rsynchroniser cet instantané vers l'hôte distant. (il y a même une option pour "suspendre" l'instantané)

OU, si vous souhaitez une sauvegarde plus robuste, vous pouvez arrêter la machine virtuelle et rsync avec élégance sur le ou les fichiers vmdk.

Donc ... il semble que je sois un simple script shell loin de toutes les sauvegardes que j'ai jamais voulu faire, simplement et facilement, en utilisant le vieux rsync.

Qu'est-ce que j'oublie ici ?

— user227963
source

1

Parce que si un seul fichier change dans la VM, vous devrez sauvegarder l'intégralité du vmdk?

— faker

Non, rsync mettra à jour un seul fichier efficacement avec juste les changements depuis le dernier transfert. Certes, les opérations de la machine virtuelle pourraient produire beaucoup plus de changements que vous ne le pensez, mais cela ne vous

— obligera

Outre le fait que vous ne devriez pas utiliser le shell esxi pour autre chose que la maintenance, le système d'exploitation esxi n'est pas conçu pour fonctionner de cette manière, et vous ne seriez pas pris en charge, je pense que vous comprenez mal le concept d'un instantané. Dans ce cas, l'instantané est un delta. Donc, si vous prenez un instantané et le copiez immédiatement, il serait minuscule et ne contiendrait presque aucune information. Vous pensez à un instantané de stockage backend, et oui, les gens sauvegardent les machines virtuelles de cette façon

— Rqomey

1

@Rqomey - il existe différents types de "clichés" dans ESXi. Vous parlez du type qui est visible via vSphere Client - mais en utilisant l'API, vous avez d'autres options, par exemple: clone complet.

— masi

@MASI Voulez-vous dire un clone alors par opposition à un instantané? ;)

— Rqomey

32

Parce que les vitesses de transfert hors de la console ESXi sont volontairement limitées.
Parce que ce n'est en aucun cas évolutif.
Parce que vous devez déposer un binaire rsync compilé statiquement sur l'hôte ESXi.
Parce que les machines virtuelles, les VMDK, leurs fichiers ramdisk et d'autres composants peuvent changer suffisamment pour faire de rsync une proposition perdante ... voulez-vous vraiment resynchroniser une machine virtuelle de 200 Go qui a été redémarrée et a eu un petit nombre de fichiers modifiés?
En raison des besoins en ressources CPU / mémoire sur la source ou la destination. Rsync n'est pas gratuit.
Parce qu'il existe d'autres produits sur le marché, fournis par des tiers et fournis par VMware. Recherchez le suivi des blocs modifiés .
Parce que ESXi n'est PAS un système d'exploitation à usage général.

Voir également: Installer rsync sur le serveur VMware ESX 4.1

— ewwhite
source

1

Réponse exceptionnelle.

— EEAA

3

Ils ne sont pas ... Je veux dire, c'est dans le nom: ghettoVCB . Il existe de meilleures solutions. Veeam, vSphere Data Protection, etc.

— ewwhite

2

Vous pouvez certainement utiliser la méthode rsync si vous passez à xen / kvm.

— Zoredache

9

@ user227963 Rsync est également plutôt inefficace sur les deux - un grand nombre de fichiers ainsi que des fichiers volumineux. Et bien qu'il ne soit pas obligé de renvoyer l'intégralité du fichier sur le fil, il devra le relire sur la source et la destination. CBT vous aidera ici, mais rsync ne sait rien de CBT.

— the-wabbit

2

@ user227963 la copie de fichiers est simple. Maintenant, faites-le rapidement et pas un porc de ressources sur les gros fichiers avec de petits changements constants. rsync est décent mais loin des performances de quoi que ce soit avec des informations d'initiés sur les blocs modifiés.

— JamesRyan

4

Je faisais cela il y a quelques années. (modifier: avec VMWare fonctionnant sur des hôtes CentOS, pas ESXi certes)

Chaque nuit, j'avais un script qui suspendait une machine virtuelle, resynchronisait les fichiers du disque vers le serveur de sauvegarde, puis redémarrait les machines virtuelles. Cela a plutôt bien fonctionné sauf ...

Rsync ne fonctionne pas très bien avec un fichier de 2 Go.

Ce n'est pas parce que rsync n'est pas brillant, mais plus que chaque fichier vmdk de 2 Go change de manière très opaque pour rsync, même de petites modifications du système de fichiers inclus produisent des changements dans le vmdk (ou tous les vmdks pour une raison quelconque) que je blâmais Windows, soit la défragmentation automatique, soit toutes les autres choses qu'il fait, peu importe si vous utilisez un vrai système, mais apparaissent lorsque vous essayez de rsynchroniser une VM!

Je pense que le mécanisme rsync pour détecter les changements ne fonctionne pas très bien sur un fichier de 2 Go, alors qu'il saute assez souvent des morceaux du début du vmdk, une fois qu'il a commencé à trouver une différence, il copiera simplement le reste du fichier. Je ne sais pas si c'est un problème avec rsync ne pouvant pas détecter un bloc de données binaires déplacé, ou avec un manque de mémoire sur la boîte source, ou si le vmdk vient d'être mis à jour tout au long. Cela n'a pas d'importance car le résultat était le même - la majorité du vmdk a été copiée.

Au final, j'ai simplement copié tous les fichiers modifiés et les écrasé, toujours en utilisant rsync. J'ai également eu de meilleures performances en remplaçant simplement le fichier de sauvegarde au lieu de laisser rsync copier et remplacer ce qui était là.

Notre serveur de sauvegarde n'était pas non plus le plus rapide et il est arrivé au point où la nuit n'était pas assez longue pour sauvegarder toutes les machines virtuelles en cours d'exécution.

Cependant, lorsque nous avons eu besoin de restaurer une machine virtuelle, c'était vraiment facile et fonctionnait à merveille.

— gbjbaanb
source

D'accord, c'est très utile. Je connais un peu le fonctionnement de rsync, et je peux vous dire que cela n'a rien à voir avec la taille du fichier - mais ce que vous décrivez, c'est que le fichier change beaucoup plus que vous ne le pensez ... c'est-à-dire disons, vous exécutez la machine virtuelle pendant une journée, et vous ne faites que quelques petites choses avec elle, puis vous l'arrêtez ... mais le fichier vmdk a changé de 30 à 40% (même si vous avez fait très peu). Donc rsync ferait très bien, il a juste beaucoup de travail à faire ... plus que ce à quoi vous vous attendiez. Merci!

— user227963

1

Mais alors ... la question que cela soulève ... comment font les outils "professionnels"? Quel genre de magie font-ils qui est en quelque sorte plus optimal que ce que ferait rsync (ou scp, ou même cp)? À la fin de la journée, vous avez un environnement Unix (la console ESXi) et vous voulez déplacer un fichier dedans ou en dehors ... quels secrets pourrait-il y avoir impliqué?

— user227963

@ user227963 Les outils professionnels exploitent des fonctionnalités telles que le suivi des blocs modifiés ou ont accès à d'autres API vSphere ou ESXi.

— ewwhite

2

La resynchronisation d'un seul fichier n'est pas une solution de sauvegarde,

que faites-vous quand quelque chose est arrivé à la vm et que les fichiers ont été supprimés, mais vous ne l'avez remarqué qu'après que votre rsync a recommencé? Vous aurez écrasé la bonne «sauvegarde» de vos fichiers avec la mauvaise image maintenant.

Si vous voulez une sauvegarde, vous devez conserver les anciennes versions quelque part, ou les différences. Rsync copiera uniquement les différences pour vous, mais il ne stockera pas uniquement les différences, mais écrasera le fichier précédent.

Il peut y avoir des options pour vous ici, avec rsync, et un système de fichiers de copie sur écriture avec des informations de version, qui stockera en effet les différences à chaque exécution de votre script rsync. Ces solutions commencent déjà à devenir un peu plus compliquées, c'est pourquoi les gens ont recours à des solutions de travail connues à mon humble avis.

— Jens Timmerman
source

Il y a certainement beaucoup plus de complexité ici que je ne le pensais à l'origine, mais ce que vous mentionnez n'est pas un problème. Certes, si vous exécutiez aveuglément rsync encore et encore, vous auriez des problèmes, comme vous le suggérez, mais il existe de nombreuses façons simples de cloner / faire pivoter des sauvegardes créées par rsync (même celles à fichier unique) ... ce problème a été résolu longtemps. il y a longtemps, heureusement.

— user227963

0

Il n'y a aucune raison pour laquelle vous ne pouvez pas utiliser Rsync sur un serveur ESXi. Nous proposons ici une version compilée statiquement https://33hops.com/rsync-for-vmware-vsphere-esxi.html qui fonctionne très bien. Il y a aussi des informations sur la façon de compiler le vôtre.

Néanmoins, quiconque souhaite l'utiliser doit tenir compte du fait que Rsync et son algorithme Delta ne sont pas censés sauvegarder d'énormes fichiers épars de longueur fixe, comme les disques durs de VM, mais synchroniser des fichiers plus petits de longueur variable. Donc, cela fonctionne, mais il faut beaucoup de temps et de CPU pour calculer les données de diff. En fait, c'est juste un moyen d'échanger la bande passante par CPU. Dans tous les cas, cela reste tout à fait réalisable, surtout si vos disques virtuels sont de l'ordre de quelques dizaines de gigaoctets.

J'ai publié un article complet sur le sujet ici, détaillant tous les avantages et inconvénients https://33hops.com/blog_xsibackup-rsync-considerations.html

— Daniel J.
source