Dlaczego ludzie nie używają rsync do tworzenia kopii zapasowych gości vmware?

13

Jeśli korzystam z nowoczesnego systemu vmware ESXi, mogę dodać statycznie połączone pliki binarne i rsync rsync do dowolnego miejsca docelowego przez SSH.

Próbuję zrozumieć, dlaczego większość (wszystkich?) Kopii zapasowych gości vmware nie jest wykonywana w ten sposób.

Jeśli maszyna wirtualna jest uruchomiona, możesz po prostu użyć „vim-cmd vmsvc / snapshot.create”, aby utworzyć migawkę, a następnie zsynchronizować ją z hostem zdalnym. (istnieje nawet opcja „wyciszenia” migawki)

LUB, jeśli chcesz mieć bardziej niezawodną kopię zapasową, możesz z wdziękiem zatrzymać maszynę wirtualną i rsync w plikach vmdk.

Więc ... wygląda na to, że jestem prostym skryptem powłoki z dala od wszystkich kopii zapasowych, które kiedykolwiek chciałem zrobić, prosto i łatwo, używając zwykłego starego rsync.

Czego tu brakuje?

— użytkownik227963
źródło

1

Ponieważ jeśli pojedynczy plik zmieni się na maszynie wirtualnej, będziesz musiał wykonać kopię zapasową całego vmdk?

— faker

Nie, rsync efektywnie zaktualizuje pojedynczy plik, wprowadzając tylko zmiany od ostatniego transferu. Z pewnością działanie VM może spowodować DUŻO więcej zmian, niż się spodziewasz, ale nie spowoduje to ponownego wysłania całego vmdk ...

— user227963

Poza faktem, że nie powinieneś używać powłoki esxi do celów innych niż konserwacja, system operacyjny esxi nie działa w ten sposób i byłbyś nieobsługiwany, myślę, że źle rozumiesz pojęcie migawki. Migawka w tym przypadku to delta. Więc jeśli zrobisz snap i skopiujesz go od razu, byłby mały i nie zawierałby prawie żadnych informacji. Myślisz o

— migawce pamięci wewnętrznej bazy

1

@Rqomey - istnieją różne rodzaje „migawek” w ESXi. Mówisz o jednym rodzaju widocznym za pośrednictwem klienta vSphere - ale korzystając z interfejsu API masz inne opcje, np .: pełny klon.

— masi

@MASI Czy masz na myśli klon, a nie migawkę? ;)

— Rqomey

33

Ponieważ prędkości przesyłania danych z konsoli ESXi są celowo ograniczone.
Ponieważ nie jest to w żaden sposób skalowalne.
Ponieważ będziesz musiał upuścić statycznie skompilowany plik binarny rsync na host ESXi.
Ponieważ maszyny wirtualne, VMDK, ich pliki ramdysku i inne składniki mogą się zmienić na tyle, aby rsync stała się propozycją przegraną ... czy naprawdę chcesz ponownie zsynchronizować maszynę wirtualną o pojemności 200 GB, która została ponownie uruchomiona i zmieniła się niewielka liczba plików?
Ze względu na wymagania dotyczące zasobów procesora / pamięci dla źródła lub miejsca docelowego. Rsync nie jest darmowy.
Ponieważ na rynku dostępne są inne produkty, zarówno dostarczane przez firmy zewnętrzne, jak i VMware. Wyszukaj zmienione śledzenie bloków .
Ponieważ ESXi NIE jest systemem operacyjnym ogólnego zastosowania.

Zobacz także: Zainstaluj rsync na serwerze VMware ESX 4.1

— ewwhite
źródło

1

Znakomita odpowiedź.

— EEAA

3

Nie są ... To znaczy, nazwa: ghettoVCB . Tam są lepsze rozwiązania. Veeam, vSphere Data Protection itp.

— ewwhite

2

Z pewnością możesz użyć metody rsync, jeśli przełączysz się na xen / kvm.

— Zoredache,

9

@ user227963 Rsync jest również raczej nieefektywny zarówno w przypadku dużej liczby plików, jak i dużych plików. I chociaż nie musi ponownie wysyłać całego pliku przez drut, będzie musiał ponownie go odczytać zarówno w źródle, jak i miejscu docelowym. CBT pomoże ci tutaj, ale rsync nic nie wie o CBT.

— the-wabbit

2

@ user227963 kopiowanie plików jest proste. Teraz zrób to szybko, a nie przechowywanie zasobów w dużych plikach z małymi stałymi zmianami. rsync jest przyzwoity, ale nigdzie nie zbliża się do wydajności niczego z informacjami poufnymi na temat tego, które bloki się zmieniły.

— JamesRyan

4

Robiłem to kilka lat temu. (edycja: z VMWare uruchomionym na hostach CentOS, nie ESXi co prawda)

Każdej nocy miałem skrypt, który zawieszałby maszynę wirtualną, synchronizował pliki z dysku na serwer kopii zapasowej, a następnie ponownie uruchamiał maszyny wirtualne. Działa całkiem dobrze, z wyjątkiem ...

Rsync nie działa zbyt dobrze z plikiem 2 GB.

Nie dlatego, że rsync nie jest genialny, a bardziej, że każdy plik vmdk 2GB zmienia się w sposób, który jest bardzo nieprzejrzysty dla rsync, nawet niewielkie zmiany w zamkniętym systemie plików powodują zmiany w vmdk (lub z jakiegoś powodu wszystkich vmdks), na które obwiniałem Windows automatycznie defragmentuje lub wykonuje inne czynności, które nie mają znaczenia, jeśli używasz prawdziwego systemu, ale pokazują się, gdy próbujesz synchronizować maszynę wirtualną!

Myślę, że mechanizm rsync do wykrywania zmian nie działa zbyt dobrze na pliku 2 GB, podczas gdy dość często pomijał fragmenty początku vmdk, gdy tylko zaczął znajdować różnicę, po prostu kopiował resztę pliku. Nie wiem, czy to jest problem z tym, że rsync nie jest w stanie wykryć przeniesionego fragmentu danych binarnych, czy z brakiem pamięci w polu źródłowym, czy też vmdk właśnie został zaktualizowany do końca. To nie ma znaczenia, ponieważ wynik był taki sam - większość vmdk została skopiowana.

Na koniec po prostu skopiowałem zmienione pliki i nadpisałem je, nadal używając rsync. Miałem także lepszą wydajność, po prostu nadpisując plik kopii zapasowej, zamiast pozwalać rsync kopiować i zamieniać to, co tam było.

Nasz serwer kopii zapasowych również nie był najszybszy i do tego stopnia, że noc nie była wystarczająco długa, aby wykonać kopię zapasową wszystkich działających maszyn wirtualnych.

Kiedy jednak musieliśmy przywrócić maszynę wirtualną, było to naprawdę łatwe i działało pięknie.

— gbjbaanb
źródło

Ok, to bardzo pomocne. Wiem trochę o tym, jak działa rsync i mogę powiedzieć, że nie ma to nic wspólnego z rozmiarem pliku - ale opisujesz, że znacznie więcej zmian w pliku niż się spodziewasz ... to znaczy powiedzmy, uruchamiasz maszynę wirtualną na jeden dzień i robisz z nią tylko kilka drobiazgów, a potem ją zatrzymujesz ... ale plik vmdk zmienił się o 30-40% (mimo że zrobiłeś bardzo mało). Więc rsync poradziłby sobie dobrze, ma po prostu dużo pracy do zrobienia ... więcej niż się spodziewałeś. Dzięki!

— user227963

1

Ale potem ... powstaje pytanie ... w jaki sposób robią to „profesjonalne” narzędzia? Jaką magię robią, która jest w jakiś sposób bardziej optymalna niż to, co zrobiliby rsync (lub scp, a nawet cp)? Na koniec masz środowisko unixowe (konsola ESXi) i chcesz przenieść plik do niego lub z niego ... jakie sekrety mogą być z tym związane?

— user227963

@ user227963 Funkcje profesjonalnych narzędzi, takie jak śledzenie zmienionych bloków lub dostęp do innych interfejsów API vSphere lub ESXi.

— ewwhite

2

Rsynchronizacja pojedynczego pliku nie jest rozwiązaniem kopii zapasowej,

co robisz, gdy coś się stało z VM i pliki zostały usunięte, ale zauważyłeś to dopiero po ponownym uruchomieniu rsync? Teraz zastąpisz dobrą „kopię zapasową” plików złym obrazem.

Jeśli chcesz wykonać kopię zapasową, musisz gdzieś przechowywać stare wersje lub dyferencje. Rsync skopiuje tylko różnicę dla ciebie, ale nie zapisze tylko różnic, ale zastąpi poprzedni plik.

Mogą tu być dostępne opcje z rsync i systemem plików kopiowania przy zapisie z informacjami o wersjach, które w efekcie przechowują różnice przy każdym uruchomieniu skryptu rsync. Rozwiązania te stają się już nieco bardziej skomplikowane, dlatego ludzie uciekają się do znanych imho działających rozwiązań.

— Jens Timmerman
źródło

Z pewnością wiąże się to z większą złożonością, niż początkowo myślałem, ale to, o czym wspominasz, nie stanowi problemu. Oczywiście, jeśli ślepo uruchamiałeś rsync w kółko, miałbyś kłopoty, jak sugerujesz, ale istnieje wiele prostych sposobów klonowania / obracania kopii zapasowych utworzonych przez rsync (nawet pojedynczych plików) ... problem został rozwiązany długo dawno temu, na szczęście.

— user227963

0

Nie ma żadnego powodu, dla którego nie można używać Rsync na serwerze ESXi. Oferujemy tutaj statycznie skompilowaną wersję https://33hops.com/rsync-for-vmware-vsphere-esxi.html, która działa bardzo dobrze. Są też informacje, jak skompilować własne.

Niemniej jednak każdy, kto chce go użyć, musi wziąć pod uwagę, że nie sądzono, że Rsync i jego algorytm Delta wykonują kopie zapasowe ogromnych rzadkich plików o stałej długości, takich jak dyski twarde VM, ale synchronizują mniejsze pliki o zmiennej długości. Więc działa, ale zajmuje dużo czasu i procesora, aby obliczyć dane różnicowe. W rzeczywistości jest to tylko sposób na zamianę przepustowości przez procesor. W każdym razie nadal jest to całkiem wykonalne, szczególnie jeśli twoje wirtualne dyski są rzędu kilkudziesięciu gigabajtów.

Opublikowałem tutaj pełny post na ten temat, szczegółowo opisując wszystkie zalety i wady https://33hops.com/blog_xsibackup-rsync-considerations.html

— Daniel J.
źródło