Mam Proxmoxa i na nim zainstalowanych kilka maszyn linuksowych, dużo zabawy żeby instalować wszystko od nowa, chcę to przenieść na ESXI myślałem nad taką formą żeby zrobić backup z poziomu linuxa a następnie podstawić na ESXI “świeży” system i w nim recovery z tego backupu który zrobiłem, tylko nie wiem czy to zadziala i jakiego programy do tego użyć.
Możesz użyć qemu-img do konwersji dysków wirtualnych na format używany przez VMWare. Tak będzie najprościej. Generalnie wirtualne dyski są najważniejsze w tej kwestii, bo maszynę możesz poprostu utworzyć nową. Pamiętaj tylko, że przy konwersji nie możesz mieć snapshotów, bo nie przejdzie.
Innych sposobem jest zrobienie kopii systemu plików za pomocą na przykład TAR i rozpakowanie tego na nowo utworzonych i sformatowanych partycjach. Ja na przykład tak przenosiłem fizyczny serwer do VM, to było dla mnie najszybsze rozwiązanie, zwłaszcza że nie mogłem pozwolić sobie na wyłączenie serwera w celu użycia jakiegoś narzędzia do klonowania.
To drugie rozwiązanie podoba mi się bardziej pakuje wszystko do TAR i rozpakowuje na nowym systemie, ale rozumiem że musze wpisać wszystkie katalogi którę chce skompresować i potem odtworzyć na nowym systemie. A czy nie instnieje jakis “cudowny program” taki odpowiednik z Windowsa który zrobi mi kilkoma poleceniami obraz całej partycji i odtworzę go na nowym sysytemie?
Clonezilla lub dd (obraz raw)
Proponuję metodę z dd poprzez ssh. Prostsza będzie zaproponowana powyżej metoda z qemu-img ale ta ma też swój urok, jak choćby możliwość kopiowania tylko wybranych partycji czy transfer poprzez sieć. Piszę z pamięci, więc mogę coś przekręcić.
Uruchamiamy starą i nową maszynkę z Live CD a nie z systemu, z dysku (ja używałem https://gparted.org/) . Obie maszyny muszą widzieć się w sieci, więc konfiguruję adresy IP na obu i na docelowej maszynie uruchamiam serwer SSH.
Jeżeli dysk docelowy będzie większy, to potem ostatnią partycje można rozciągnąć choćby wspomnianym gparted.
-
Zrzucenie mbr/tablicy partycji starego dysku do pliku i odtworzenie jej na dysku docelowym. Materiały do przerobienia https://www.cyberciti.biz/faq/howto-copy-mbr/ potem restart albo ponowna inicjalizacja dysku, żeby odczytać nową tablicę partycji.
-
Potem już tylko na starym systemie, dla każdej partycji:
dd if=/dev/sda1 bs=1M | ssh root@nowy 'dd of=/dev/sda1'
Aby w dd mieć informację o postępie należy dodać parametr status=progress https://www.cyberciti.biz/faq/linux-unix-dd-command-show-progress-while-coping/
Należy poeksperymentować z parametrem bs czasami więcej = wolniej.
To samo możemy zrobić nie uruchamiając serwera SSH, tj przez netcat ale transmisja nie będzie szyfrowana, co może być kiepskim pomysłem gdy przerzucamy dane po sieci.
https://www.ndchost.com/wiki/server-administration/netcat-over-ssh
Po pierwsze tar to archiwizator, nie kompresor. Po drugie, tar ma przełącznik one-file-system co pozwala Ci zrobić kopię systemu plików danej partycji bez potrzeby odmotowania systemu plików.
Dlatego tar jest lepszy, bo zrobisz kopię na działającym systemie. Przy dd musisz odmotować partycję, czyli musisz to robić z livecd.
Zgadzam się, z tar nie trzeba livecd. W przypadku dd jeżeli uda się przemontować partycję w ro to również nie trzeba. Z systemową raczej się nie da.
Zawsze miałem obawy co do kopiowania na żywym systemie bez utworzenia migawki partycji. Choćby dlatego, żeby uniknąć sytuacji gdzie jakieś pliki z wielu katalogów, stanowiące całość zostały zmienione i w archiwum po części są jeszcze przed zmianą. Albo brak spójności z bazą danych.
Oczywiście moje obawy wynikają z przesadnej dbałości w tym temacie 
Ostatecznie można na czas tarowania wyłączyć usługi piszące do plików, takie jak serwer SQL czy webowy czy nawet wymusić działanie usługi w ro. Lepsze to od restartu serwera tam gdzie na restart nie można sobie pozwolić.
Tak czy inaczej przyznam rację, że w większości sytuacji tar załatwi sprawę.
Mowa o systemie plików, który nie ulega zmianie, migracja SQL zawsze wymaga przestoju, niezależnie czy robisz cold czy hot backup (dump). Nawet przy live migration, dump to podstawa.
Co do zmian w SQL, w przypadku webserver, właśnie dlatego nie powinno się zamykać webserver i db w jednym systemie. Webserver powinien być oddzielony od db server.
Żeby jeszcze człowiek częściej w praktyce trafiał tak na tak pięknie zaprojektowane systemy 
1 polubienie
Niestety muszę sprzątać takie syfy. Najbardziej rozbrajają mnie LAMPy czy tam XAMPy na Windows Server.
To chyba nie powinno działać w produkcji. Apache.org nawet nie oferuje binarek na Windows. To tak jakby powiedzieli “nie mamy pewności co do działania tego produktu pod Windowsami”.
No jak nie jak tak 
https://apache.mirrors.tworzy.net/httpd/binaries/win32/
Pod Windows i Linux jest XAMP. CrossPlatform Apache MySQL PHP
Tylko jaki sens jest stawiać to pod Windows. Postawienie chociażby takiego CentOS nie wymaga tajemnej wiedzy brodaczy linuksowych, ale to już chyba tylko przyzwyczajenie do Windows tłumaczy takie rozwiązania.
przecież vmware też ma narzędzia do robienia takich operacji
Pewnie ma. Ja akurat mam niewielkie doświadczenie z VMWare
Panie można nawet w drugą stronę ja akurat sporo siedze w vmware no dobra siedziałem już nie grzebie w penetestach na antywirusach i hipsach.
A tu masz info jak przerobić w drugą strone virtualny system na prawdziwy i nie tylko
Ofc można też po twojemu to zrobić za pomocą zewnętrznego programu do kopi systemu.
https://www.vmware.com/support/v2p/
1 polubienie
Kurcze byłem przekonany, że jakiś czas temu na apache.org była notka, że wersja pod Windows nie jest zalecana na produkcję ale może pomyliłem z Nginx 
Fakt, AMP’y pod Windows produkcyjnie to dziwnie brzmi. No i wchodzi w grę ryzyko, że coś nie wstanie po Windows Update, a taki CentOS aktualizuje się gładko przez 10 lat.
1 polubienie
Nginx akurat nigdy nie spotkałem na Windows i nigdy nie wnikałem czy jest dostępny pod Windows
Jest https://nginx.org/en/docs/windows.html ale piszą, żeby nie oczekiwać wysokiej wydajności i traktować go raczej jako wersję beta.
Jak ktoś napisał P2V/V2V, lub utworzyć nową identyczną VM i podpiąć skonwertowany dysk. Z tego co pamiętam qemu-img konwertuje do vmdk bez problemu.