Na przestrzeni ostatnich kilku(nastu) tygodni, niespiesznie przenosiłem domeny (dane stron – pliki, bazy danych do nich oraz wiadomości z kont pocztowych) z serwera hostingu używanego przez stowarzyszenie znajomych, dla którego po kilku latach korzystania z niego stowarzyszenie nie planuje przedłużać usługi w firmie hostingowej (może jeszcze kiedyś popełnię wpis na temat tej firmy, bo usługi hostingowe i jakość wsparcia firma wcześniej miała rewelacyjne, a teraz spadło wszystko do takiego poziomu, że trzeba się było ruszyć z domenami i stronami gdzieś indziej). Zostało mi już niewiele do przeniesienia – pliki stron domen, dla których zdążyłem zrobić backup na dysku i mam nadzieję, że wyrobię się, zanim dostęp do serwera hostingu zostanie zablokowany. Akurat backupowanie danych to nie problem. Gorzej ze skrzynkami mailowymi, bo to samo w sobie jest upierdliwe. To samo zresztą robiłem niedawno w trybie na cito – czyli uciekałem z danymi – z innego serwera hostingu w tej samej firmie, który został zakupiony na bazie pozytywnych wrażeń z korzystania z hostingu przez stowarzyszenie znajomych.
Strony, jak to strony – z długim stażem, każda praktycznie stawiana przez kogoś innego, bazujące na silniku CMS WordPress. Stowarzyszenie prowadziło różne projekty i dla tych projektów tworzone były strony. Na konto serwera firmy hostingowej, z której obecnie trwa (e)migracja danych, trafiły w 2016 roku po kilku latach obecności na hostingu w Nazwa.pl, po drastycznym podniesieniu cen świadczonych przez Nazwę usług.
Żeby mieć działającą stronę WordPressa na nowym hostingu to potrzebujemy ze starego skopiować pliki z folderu WWW konkretnej domeny serwera (przeważnie to domena/public_html/) oraz bazę danych (w przypadku WordPressa będzie to baza typu MySQL). Przez lata testowałem różne rozwiązania służące do backupu całych instalacji stron opartych na WordPressie typu wtyczki (pluginy) pakujące całą zawartość strony do pliku ZIP i to samo robiące z bazą danych, które można potem pobrać klientem FTP z folderu backupu na serwerze. Ostatecznie jednak w moim przypadku backupowanie kończyło się kopiowaniem na żywca wszystkich plików oraz pobieraniem bazy danych z serwera hostingu. Wtyczki do robienia kopii zapasowych instalacji WordPress w teorii działają automagicznie – zrobią wszystko, co jest niezbędne i przygotują pliki do przeniesienia. Jednak wystarczy, że coś jest nie tak z serwerem hostingowym, jakieś opcje nie są w konfiguracji serwera ustawione i korzystając z takich wtyczek możemy zostać z plikami, które na nowym serwerze nie będą nadawały się do niczego. Będzie brakowało plików w archiwum, a baza danych będzie ucięta, bo serwer nie był w stanie jej całej przetworzyć i przesłać do pliku.
Jednak nie tylko wtyczki do backupu mogą zaserwować nam uszkodzone pliki. Taka sytuacja spotkała mnie, gdy z poziomu panelu hostingu jakim jest DirectAdmin (najpopularniejszy obecnie panel w firmach hostingowych do obsługi kont użytkowników na serwerach) pobrałem plik bazy danych SQL (metodą, jak na zrzucie ekranu).
Po pobraniu pliku bazy danych, przetworzeniu go – zmianie ścieżek serwera starego hostingu na ścieżki dla domeny na nowym hostingu oraz próbie wgrania tak przygotowanej bazy przez panel phpMyAdmin dostępu do baz danych, phpMyAdmin wyświetlił błąd – zawartość bazy z pliku nie może zostać załadowana. Niezłe zaskoczenie. Coś jest nie tak. Wystarczyło jednak tę samą bazę danych ze starego hostingu pobrać do pliku przez panel phpMyAdmin za pomocą funkcji Export (nawet w opcji Szybko), przerobić stare ścieżki dostępu do plików na te z nowego hostingu i tak przygotowana baza została bez problemu wgrana przez phpMyAdmin z pliku do nowej bazy na serwerze.
Tak więc nawet eksport bazy danych SQL przez panel DirectAdmin nie gwarantuje poprawności utworzenia pliku bazy. Na szczęście przez phpMyAdmina udało się poprawnie wyeksportować bazę. I tej metody będę się w przyszłości trzymał.
Krystkowy (WordPress) blog... 
Jeśli przenosisz tylko blogi wordpressa to w ostateczności wp ma swoje wbudowane narzędzie do tego. Osobiście korzystam tylko z mysqldump do przenoszenia i nigdy problemu nie miałem 😉
I tak, i nie. Narzędzia WordPress-a są dobre, gdy chcemy w postaci pliku XML wyeksportować zawartość serwisu (strony, wpisy, menu). To jest pomocne, gdy strona bazuje na jakimś frameworku (np. Elementor), a nam zależy na treściach, by wgrać je pod innym szablonem (niekoniecznie na frameworku).
U mnie było tak, że nie wystarczył zrzut bazy danych. Ponowna czysta instalacja i wgranie treści pod WordPressa również nie, a to ze względu na różne wtyczki WP. Niektóre się tak integrują (np. pluginy do zabezpieczania instalacji WordPressa przed włamaniami), że tworzą pliki w różnych miejscach w strukturze folderów i mają do nich odnośniki w bazie. Brak któregoś z plików powoduje niedziałanie strony.
Miałem też problem z jedną stroną, że nie wgrała się w całości baza danych na serwer MySQL przez phpMyAdmin. Strona zaczęła działać, ale zanim się pokapowałem to minęło trochę czasu. Najpierw była zabawa z eksportem brakujących tabel ze starej bazy, potem ich dogrywanie przez phpMyAdmin, ale cały czas coś było nie tak. Potem pałeczkę przejął administrator hostingu, który miał mi pomóc przerzucić bazę bezpośrednio ze starego serwera baz SQL do bazy na swoim hostingu. Jednak zabrał się do tego bez przekonania. Ostatecznie skorzystałem pod Windowsem z fantastycznego programu JookDB, dzięki któremu przez GUI w niewiele ponad minutę przetransferował mi 100-megabajtową bazę z jednego serwera na drugi (wiem, że mogłem zainstalować serwer MySQL i przez konsolę wgrać lokalną bazę danych z pliku na zdalny serwer, ale aż tak nie chciało mi się bawić; tę możliwość zostawiłem na moment, gdy wszystkie inne metody by zawiodły). Potem jeszcze musiałem zrobić „Znajdź i zamień”, by zmienić w bazie danych ścieżki do folderów domeny na te, z nowego serwera. To już zrobiłem z poziomu phpMyAdmina. No i ponownie wgrywałem wszystkie pliki ze starej instalacji, bo w międzyczasie na nowym serwerze nastąpiła aktualizacja WordPressa. Jedyna wada JookDB jest taka, że obsługa typu baz MariaDB dla MySQL jest wyłącznie w płatnej wersji. Na szczęście po uruchomieniu trial programu ważny jest przez 20 dni, bez ograniczeń funkcjonalnych.
Niedawno potrzebowałem (do eksperymentów) zrobić sobie kopię żywej strony WordPress na lokalnym kompie, w sposób powtarzalny (tj. z możliwością zassania bieżącej wersji żywej strony w dowolnym momencie). Sam download zasadniczo udało mi się zredukować do dwóch poleceń Basha (z poziomu WSL2 – używam Windows 10): jedno to mysqldump przepuszczopny przez gzipa i przekierowany lokalnie do folderu z kopią zapasową, a drugi to rsync ściągający zawartość folderu /var/www/html na żywca na lokalnego kompa. I syćko śmigo, gro i bucy.
Nigdy jakoś mi nie przychodziło do głowy pobieranie SQL z wykorzystaniem jakiegoś panelu administracyjnego. Zawsze to był albo phpmyadmin albo ssh i sqldump.