Migracja z hostingu współdzielonego na VPS

Co zmienia się po przejściu z hostingu współdzielonego na VPS

Przejście z hostingu współdzielonego na VPS pozostawia witrynę bez zmian, ale przekazuje użytkownikowi zadania, które panel administracyjny wykonywał dotychczas w tle: obsługę wersji PHP i jego rozszerzeń, certyfikatu TLS (transport layer security) i jego odnawiania, zadań cron, kopii zapasowych, filtrowania spamu oraz skrzynek pocztowych. Kod witryny nie wymaga żadnych zmian. Zmienia się to, że każde z tych zadań ma teraz właściciela, a tym właścicielem jest użytkownik.

Bezpieczna kolejność jest prosta i sprawdzona. Należy przygotować stos na nowym serwerze. Następnie skopiować pliki i bazę danych. Nowy serwer należy przetestować za pomocą adresu IP, zanim zostanie zmieniony dowolny rekord DNS. Dzień wcześniej należy zmniejszyć wartość TTL DNS. Następnie należy zmienić rekord. Stare konto należy pozostawić uruchomione przez tydzień i w tym czasie monitorować dzienniki. Jeśli nadal rozważana jest opłacalność migracji, rzeczywisty kompromis między hostingiem współdzielonym a VPS pomoże podjąć decyzję. W tym przewodniku przyjęto, że decyzja została już podjęta.

Inwentaryzacja, której nikt nie wykonuje

cPanel i DirectAdmin ukrywają działający serwer za zestawem formularzy. Przed odtworzeniem tego serwera należy zapisać, co było konfigurowane za pomocą tych formularzy. Trzeba to zrobić, gdy stare konto jest jeszcze aktywne, ponieważ po jego usunięciu większości tych informacji nie da się odczytać.

• Wersja PHP i lista załadowanych rozszerzeń.
• Silnik bazy danych i jego wersja, a także nazwa każdej bazy danych, użytkownik i hasło.
• Każde zadanie cron: jego harmonogram i dokładny wiersz polecenia.
• Certyfikat TLS: wystawca, data wygaśnięcia oraz informacja, czy panel odnawiał go automatycznie.
• Miejsce hostowania strefy DNS oraz nameservers używane przez domenę.
• Każda skrzynka pocztowa, przekierowanie i autoresponder w domenie.
• Każdy plik .htaccess, w tym pliki w podkatalogach.
• Limity PHP ustawione przez panel: upload_max_filesize, post_max_size, memory_limit, max_execution_time.

Jeśli plan zapewnia dostęp do powłoki, większość tych informacji można zebrać podczas jednej sesji SSH na starym hoście.

php -v
php -m
crontab -l
find ~/public_html -name .htaccess
dig NS example.com +short
mysql -u olduser -p -e 'SHOW DATABASES;'

Bez dostępu do powłoki należy przesłać jednowierszowy plik, aby odczytać konfigurację PHP przez WWW.

<?php phpinfo();

Otwórz plik raz w przeglądarce, zapisz wersję PHP i ścieżkę Loaded Configuration File, a następnie usuń plik. Pozostawiona online strona phpinfo ujawnia każdemu, kto ją znajdzie, dokładną kompilację PHP i rzeczywiste ścieżki na serwerze.

Należy zwrócić uwagę na wiersz nameserver. Jeśli dig NS example.com +short zwraca nameservers używane przez dostawcę hostingu WWW, strefa DNS znajduje się na koncie przeznaczonym do anulowania. Anulowanie konta usuwa również strefę, po czym domena przestaje się rozwiązywać niezależnie od tego, jak dobrze przygotowano nowy serwer. Przed wykonaniem jakichkolwiek innych czynności należy przenieść DNS do dostawcy, który nie jest dostawcą hostingu WWW, a następnie odczekać dzień na propagację zmiany. jak resolver faktycznie znajduje rekordy wyjaśnia, co dzieje się podczas tego procesu.

Zbuduj nowy stos, zanim zmienisz DNS

Zainstaluj tę samą główną wersję PHP, która działała na starym hoście. Zgodność wersji eliminuje całą klasę awarii w dniu przełączenia. PHP można zaktualizować tydzień później, gdy jedyną zmienianą rzeczą będzie wersja. Według stanu na wrzesień 2026 Ubuntu 24.04 LTS udostępnia PHP 8.3 we własnych repozytoriach. Aby użyć starszej wersji, dodaj archiwum ppa:ondrej/php i zainstaluj PHP z tego źródła.

sudo apt update
sudo apt install -y nginx mariadb-server php8.3-fpm php8.3-mysql \
  php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl
sudo mysql_secure_installation

Porównaj php -m na nowym serwerze z listą z inwentaryzacji. Brakujące rozszerzenie nie zgłasza się bezpośrednio. Usterka ujawnia się później jako niedziałająca funkcja, zwykle zmiana rozmiaru obrazu (gd) albo integracja płatności (curl).

W tym poradniku przyjęto, że serwer jest już przygotowany: istnieje konto logowania inne niż root, klucz SSH i zapora sieciowa. pierwsze dziesięć minut na nowym VPS opisuje te czynności, dlatego nie trzeba ich powtarzać na tej stronie.

Teraz należy skonfigurować samą witrynę. Zastąp deploy własną nazwą użytkownika, a example.com własną domeną.

server {
    listen 80;
    server_name example.com www.example.com;
    root /srv/example.com/public;
    index index.php;

    client_max_body_size 64m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Zapisz konfigurację jako /etc/nginx/sites-available/example.com, utwórz do niej dowiązanie w sites-enabled, a następnie uruchom sudo nginx -t i sudo systemctl reload nginx. Polecenie nginx -t wyświetlające syntax is ok i test is successful służy do sprawdzenia konfiguracji. Przeładowanie usługi z błędną konfiguracją pozostawia aktywną poprzednią konfigurację. Dlatego witryna, która przestaje reagować na wprowadzone zmiany, zwykle oznacza pominięcie testu.

.htaccess jest plikiem Apache, a nginx go nie odczytuje. Każda reguła przepisywania adresów i kontroli dostępu, którą stary host stosował za pośrednictwem .htaccess, przestaje obowiązywać natychmiast po rozpoczęciu obsługi witryny przez nginx. Wiersz try_files powyżej zastępuje standardowy blok reguł przepisywania WordPressa. Wszystkie pozostałe wpisy w tych plikach, takie jak ochrona przed hotlinkingiem lub blokady adresów IP, trzeba przepisać jako dyrektywy nginx. Jeżeli witryna zawiera długi wygenerowany plik .htaccess, którego nie można odczytać, zainstaluj apache2 za pomocą libapache2-mod-php8.3, a następnie ustaw AllowOverride All dla tego katalogu. Reguły będą wtedy działać bez zmian. W przypadku witryny tej wielkości ma to większe znaczenie niż przewaga nginx pod względem przepustowości.

Kopiowanie plików

sudo install -d -o deploy -g www-data /srv/example.com/public
rsync -avzn olduser@oldhost.example.com:public_html/ /srv/example.com/public/
rsync -avz  olduser@oldhost.example.com:public_html/ /srv/example.com/public/

Pierwsze polecenie z -n wykonuje próbę bez wprowadzania zmian: wyświetla pliki, które zostałyby przeniesione, ale niczego nie kopiuje. Należy uruchomić je raz i sprawdzić liczbę plików, a następnie usunąć -n. Końcowy ukośnik w ścieżce źródłowej ma znaczenie. public_html/ kopiuje zawartość tego katalogu. public_html bez ukośnika kopiuje sam katalog do katalogu docelowego. W rezultacie witryna znajduje się o jeden poziom za głęboko, a nginx zwraca błąd 403.

Na hostingu współdzielonym PHP działał jako użytkownik konta i był właścicielem wszystkich plików, dlatego uprawnienia rzadko stanowiły problem. Na VPS serwer WWW działa jako www-data, a użytkownik logowania jest inny. Oznacza to, że własność plików decyduje teraz o tym, co serwer WWW może odczytywać i zapisywać.

sudo chown -R deploy:www-data /srv/example.com/public
sudo find /srv/example.com/public -type d -exec chmod 750 {} +
sudo find /srv/example.com/public -type f -exec chmod 640 {} +
sudo chmod -R g+w /srv/example.com/public/wp-content/uploads

Zapewnia to www-data dostęp do odczytu w całym drzewie katalogów, a dostęp do zapisu tylko w miejscach przeznaczonych na przesyłane pliki. Nie należy upraszczać konfiguracji za pomocą chmod -R 777 ani przyznawać www-data dostępu do zapisu w całym drzewie. Błąd we wtyczce, który umożliwia zapisanie pliku .php w katalogu obsługiwanym również przez serwer WWW, oznacza uzyskanie powłoki na serwerze. To różnica między zmienioną treścią strony a koniecznością ponownego zbudowania serwera.

Przeniesienie bazy danych

Wykonaj zrzut na starym hoście, przenieś go, a następnie załaduj.

mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u olduser -p olddb > site.sql

--single-transaction wykonuje spójny zrzut tabel InnoDB bez blokowania działającej witryny. Nie obejmuje tabel MyISAM. Jeśli na starej stronie nadal znajdują się takie tabele (SHOW TABLE STATUS podaje silnik dla każdej tabeli), przed wykonaniem zrzutu włącz tryb konserwacji albo zaakceptuj możliwość utraty zapisu wykonanego w tym czasie.

CREATE DATABASE sitedb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'siteuser'@'localhost' IDENTIFIED BY 'a long random password';
GRANT ALL PRIVILEGES ON sitedb.* TO 'siteuser'@'localhost';
FLUSH PRIVILEGES;

mysql -u root -p sitedb < site.sql
mysql -u root -p -e 'SELECT COUNT(*) FROM sitedb.wp_posts;'

Porównaj tę liczbę wierszy z wynikiem tego samego zapytania na starym hoście. Zgodne liczby oznaczają, że ładowanie zostało ukończone. Jeśli ładowanie zatrzymało się w połowie, baza danych nadal zawiera wiele tabel, więc sama obecność tabel niczego nie potwierdza.

Prawdopodobnie wystąpi jeden z następujących błędów: zrzut wykonany z MySQL 8 załadowany do MariaDB kończy się komunikatem ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci'. To domyślne sortowanie w MySQL 8, którego MariaDB nie obsługuje, dlatego instrukcja CREATE TABLE zostaje odrzucona. Przed ładowaniem zmień ją w zrzucie za pomocą sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' site.sql, a następnie ponownie załaduj zrzut do nowo utworzonej bazy danych.

Na końcu skieruj aplikację do nowej bazy danych. W WordPress są to DB_NAME, DB_USER, DB_PASSWORD i DB_HOST w wp-config.php, a DB_HOST należy ustawić na localhost. Ponieważ domena się nie zmienia, nie trzeba wykonywać operacji wyszukiwania i zamiany w całej bazie danych. Należy pozostawić tę konfigurację bez zmian. Zmiana domeny i serwera w tym samym kroku uniemożliwi ustalenie, która zmiana spowodowała awarię witryny.

Testowanie nowego adresu IP za pomocą wpisu w pliku hosts

Można skonfigurować komputer tak, aby rozpoznawał domenę jako nowy serwer, podczas gdy reszta użytkowników nadal będzie kierowana do starego serwera. Należy dodać ten wiersz do /etc/hosts w systemie Linux lub macOS albo do C:\Windows\System32\drivers\etc\hosts w systemie Windows, otwierając plik jako administrator. Należy użyć rzeczywistego adresu IP serwera.

203.0.113.10 example.com www.example.com

Aby sprawdzić konfigurację bez żadnych zmian w plikach, można użyć curl do wymuszenia rozpoznawania adresu dla pojedynczego żądania.

curl -sI --resolve example.com:80:203.0.113.10 http://example.com/

HTTP/1.1 200 OK oznacza oczekiwany wynik. Każdy błąd ma jedną przyczynę. 502 Bad Gateway oznacza, że nginx nie może połączyć się z PHP-FPM, dlatego należy porównać ścieżkę gniazda fastcgi_pass z ls /run/php/. Polecenie pokaże php8.3-fpm.sock, jeśli wersja w konfiguracji jest nieprawidłowa. 404 na każdej stronie z wyjątkiem strony głównej oznacza problem .htaccess: nginx nie ma reguły przepisywania, dlatego /about/ nigdy nie dociera do index.php. 413 Request Entity Too Large podczas przesyłania pliku oznacza client_max_body_size nginx, którego domyślna wartość wynosi 1 megabajt. Jest to ustawienie niezależne od własnej wartości upload_max_filesize PHP.

Po dodaniu wpisu do pliku hosts należy normalnie korzystać z witryny. Należy zalogować się do panelu administracyjnego, otworzyć stronę z obrazami, wysłać formularz, przesłać plik i złożyć testowe zamówienie. Jest to próba wdrożenia i nic nie kosztuje, ponieważ działająca witryna nie została jeszcze przeniesiona. Po zakończeniu należy usunąć wpis z pliku hosts. W przeciwnym razie w przyszłym miesiącu można przez godzinę zastanawiać się, dlaczego przeglądarka wyświetla inną witrynę niż pozostałym użytkownikom.

Pobierz certyfikat przed przełączeniem

Wyzwanie HTTP-01, którego certbot używa domyślnie, wymaga od urzędu certyfikacji pobrania pliku przez port 80 pod rzeczywistą nazwą domeny. Działa to dopiero wtedy, gdy DNS wskazuje już nowy serwer. Występuje więc okres, w którym użytkownicy trafiają na serwer bez certyfikatu i otrzymują ostrzeżenie w przeglądarce.

Istnieją dwa poprawne sposoby rozwiązania tego problemu. Certyfikat można wystawić przed przełączeniem, używając wyzwania DNS-01. Potwierdza ono kontrolę nad domeną przez opublikowanie rekordu TXT zamiast udostępniania pliku: wystawianie certyfikatu z użyciem wyzwania DNS-01 opisuje działanie wtyczek dostawców. Można też zaakceptować krótki okres przerwy, przełączyć ruch i uruchomić certbot w ciągu jednej lub dwóch minut. Przekierowanie HTTP do HTTPS powinno pozostać wyłączone do czasu uzyskania certyfikatu.

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run
systemctl list-timers 'certbot*'

Odnawianie certyfikatu jest dokładnie takim zadaniem, które panel wykonywał bez informowania o tym użytkownika. Dwa sprawdzenia potwierdzają, że będzie ono nadal wykonywane: uruchomienie testowe zakończone wynikiem Congratulations, all simulated renewals succeeded oraz obecność certbot.timer w systemctl list-timers wraz z datą następnego uruchomienia. Certyfikat wygasający 89 dni po migracji jest jednym z najczęstszych powodów niepowodzenia takich zmian. Do tego czasu nikt zwykle nie łączy już przerwy w działaniu z migracją.

Obniż TTL DNS dzień przed przełączeniem

TTL (time to live) rekordu A informuje każdy resolver w Internecie, jak długo może przechowywać istniejącą odpowiedź. Jeśli TTL wynosi 86400 sekund, resolver, który odpytał o nazwę minutę przed zmianą, może podawać stary adres IP jeszcze przez 24 godziny. W tym czasie użytkownik zapisuje komentarze i zamówienia w starej bazie danych, podczas gdy obserwowany jest spokojny dziennik na nowym serwerze.

Należy odpytać autorytatywny serwer nazw, ponieważ zwykłe dig pokazuje zawartość pozostałą w pamięci podręcznej.

dig @$(dig +short NS example.com | head -1) example.com A +noall +answer

Liczba w czwartej kolumnie oznacza TTL w sekundach. Należy ustawić wartość 300 co najmniej na jeden pełny okres poprzedniego TTL przed przełączeniem, czyli 24 godziny wcześniej, jeśli TTL wynosił dzień. Obniżona wartość musi się rozpropagować, zanim zacznie działać. Kilka dni po przeniesieniu należy ponownie zwiększyć ją do około 3600. Stały TTL wynoszący 300 sekund powoduje, że każdy resolver na świecie odpytuje serwery nazw co pięć minut. Spowalnia to pierwszą wizytę użytkownika z pustą pamięcią podręczną.

Przełączenie, krok po kroku

1. Przełącz starą witrynę w tryb konserwacji lub tylko do odczytu, jeśli przyjmuje zamówienia, komentarze albo rejestracje. Zapisy, które po tym momencie trafią do starej bazy danych, zostaną utracone.
2. Uruchom ponownie rsync, tym razem z opcją --delete, aby uwzględnić zmiany wprowadzone od czasu pierwszej kopii oraz usunąć elementy przypadkowo usunięte po nowej stronie.
3. Ponownie zrzuć bazę danych i odtwórz ją. To właśnie ten drugi zrzut zostanie użyty w środowisku produkcyjnym.
4. Zmień rekord A na nowy adres IP. Zmień również rekord AAAA, jeśli jest używany. Rekordów MX nie zmieniaj.
5. Monitoruj zastosowanie zmiany za pomocą dig example.com +short z maszyny, która nie ma w pamięci podręcznej starej odpowiedzi, albo z telefonu korzystającego z komórkowej transmisji danych.
6. Otwórz witrynę bez wpisu hosts, kliknij ikonę kłódki i potwierdź, że certyfikat obejmuje zarówno domenę główną, jak i nazwę www.

Druga kopia jest szybka, ponieważ pierwsza przeniosła większość danych. To jest jedyny powód wykonywania kopii dwukrotnie. Dzięki temu zamrożenie zapisów trwa kilka minut zamiast kilku godzin.

Nie ulegaj pokusie dostrajania czegokolwiek w dniu przełączenia. Najpierw uruchom witrynę dokładnie tak, jak działała wcześniej. Dopiero potem zmieniaj po jednym elemencie naraz. Prace nad wydajnością należy zaplanować na osobny tydzień. Wtedy wolna strona może mieć tylko jedną nową przyczynę: pamięć podręczna obiektów Redis dla WordPress to dobry pierwszy etap po zakończeniu samej migracji.

Poczta to osobny projekt i większość czytelników powinna go pominąć

Przeniesienie witryny jest rutynowym zadaniem, którego awarie są widoczne. Przeniesienie skrzynek pocztowych to inny projekt, a jego awaria pozostaje niezauważona. Wiadomość nie wraca z czerwonym komunikatem o błędzie. Trafia do folderów spamu innych osób, a informacja o problemie dociera dopiero trzy tygodnie później od klienta, który twierdzi, że odpowiedział, ale nie otrzymał żadnej wiadomości.

Prowadzenie własnego serwera pocztowego oznacza odpowiedzialność za rekordy SPF, DKIM i DMARC, odwrotny DNS dla adresu IP VPS, filtr spamu działający w obu kierunkach, miejsce na skrzynki pocztowe oraz reputację wysyłkową nowego adresu IP, która początkowo wynosi zero. Wielu dostawców VPS blokuje również domyślnie wychodzący port 25, więc pierwsza wiadomość w ogóle nie opuszcza serwera. czy samodzielne hostowanie poczty nadal ma sens w 2026 omawia ten temat bez upiększeń. W przypadku migracji witryny odpowiedź jest prostsza: poczta nie powinna być przenoszona tego samego dnia co witryna, a w przypadku większości czytelników nie powinna być przenoszona w ogóle.

Dlatego rekordy MX należy pozostawić dokładnie tam, gdzie są. Jeśli skrzynki pocztowe znajdują się na hostingu współdzielonym, należy zachować tam niewielki plan przeznaczony wyłącznie do obsługi poczty albo przenieść je do dedykowanego dostawcy poczty według całkowicie odrębnego harmonogramu. Dwie zmiany jednocześnie oznaczają problem ze skrzynką odbiorczą i problem z witryną, których nie można od siebie odróżnić.

Witryna nadal musi jednak wysyłać wiadomości, na przykład do resetowania haseł i potwierdzania zamówień. Na hostingu współdzielonym PHP mail() działało, ponieważ na tym samym komputerze działał już serwer pocztowy. Nowy VPS go nie ma, dlatego mail() zwraca false, a WordPress zgłasza The email could not be sent. Possible reason: your host may have disabled the mail() function.. Nie należy rozwiązywać tego problemu przez instalowanie serwera pocztowego. Należy korzystać z uwierzytelnionego przekaźnika SMTP, czyli usługi submission dostawcy poczty na porcie 587, skonfigurowanej za pomocą wtyczki SMTP w WordPressie albo przez ustawienie msmtp jako systemowego sendmail. Następnie należy sprawdzić, czy ten przekaźnik znajduje się w rekordzie SPF domeny, ponieważ wiadomość wysłana z hosta nieuwzględnionego w rekordzie SPF jest dokładnie tym, co serwery odbiorcze klasyfikują jako spam.

Monitoruj dzienniki przez tydzień przed anulowaniem starego konta

Stare konto hostingowe pozostaw aktywne przez co najmniej tydzień po przełączeniu. To najtańsza metoda wycofania zmiany. Jeśli okaże się, że coś działa nieprawidłowo, skieruj rekord A z powrotem na stary serwer. Usługa nadal będzie działać, a TTL wynoszący pięć minut przyspieszy powrót.

sudo tail -f /var/log/nginx/error.log
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Lista błędów 404 pozwala wykryć rzeczywiste problemy. Pokazuje ścieżki, które obsługiwał stary serwer, ale których nie obsługuje nowy. Prawie zawsze oznacza to brak przetłumaczonej reguły .htaccess rewrite albo pominięty katalog rsync, ponieważ znajdował się poza public_html.

Błędy krytyczne PHP nie pojawią się w przeglądarce, ponieważ display_errors jest wyłączone w produkcyjnym php.ini Ubuntu. Przez FastCGI trafiają do dziennika błędów nginx jako wiersze zaczynające się od FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Call to undefined function ...". Tak z zewnątrz wygląda przejście z PHP 7.4 na 8.3: pusta strona albo HTTP 500, a rzeczywista przyczyna jest widoczna wyłącznie w dzienniku.

Zadania cron nie przenoszą się automatycznie. Odtwórz każde zadanie na podstawie inwentaryzacji. Użyj bezwzględnych ścieżek zarówno do interpretera, jak i do skryptu, ponieważ cron działa z minimalnym PATH i bez profilu powłoki.

sudo crontab -u www-data -e
# */5 * * * * /usr/bin/php /srv/example.com/public/wp-cron.php >/dev/null 2>&1
journalctl -u cron --since today

journalctl pokazujący wiersz CMD co pięć minut oznacza, że harmonogram działa. W przypadku WordPress ten wpis cron zacznie działać dopiero po wyłączeniu wbudowanego harmonogramu. Wyjaśniono to w zastąpieniu WP-Cron rzeczywistym zadaniem cron systemu: domyślny mechanizm uruchamia się podczas wyświetlania stron i przestaje działać w nieaktywnej witrynie.

Co panel wcześniej przejmował na siebie, a teraz kosztuje to Ciebie

Opłata za hosting współdzielony obejmowała zarówno pracę, jak i przestrzeń dyskową. Ta praca nie zniknęła po przeprowadzce. Zmienił się tylko właściciel obowiązków.

• Aktualizacje. sudo apt update && sudo apt upgrade zgodnie z harmonogramem, którego rzeczywiście przestrzegasz, oraz unattended-upgrades, aby aktualizacje zabezpieczeń instalowały się bez Twojego udziału. Niezałatany VPS jest najczęstszą przyczyną przejęcia małej witryny, a nic na serwerze nie przypomni o konieczności instalacji aktualizacji.
• Kopie zapasowe. Migawka dostawcy to obraz dysku przechowywany przez tego samego dostawcę na tym samym koncie. Należy traktować ją jako wygodne rozwiązanie, a nie kopię zapasową. Wykonuj mysqldump oraz archiwum plików i przechowuj je w innym miejscu, a następnie odtwórz jedną z kopii w katalogu roboczym, zanim będzie potrzebna. Nieprzetestowana kopia zapasowa jest tylko przypuszczeniem.
• Monitorowanie. Nic nie poinformuje o awarii witryny. Zewnętrzny test dostępności oraz alert dotyczący wolnego miejsca na dysku obejmują dwie awarie, które po cichu wyłączają witryny, ponieważ pełny dysk uniemożliwia MariaDB zapis, a witryna zwraca błędy, mimo że sam serwer wygląda na sprawny.

Jeżeli potrzebny jest powrót do obsługi znanej z panelu na własnym sprzęcie, można zainstalować taki panel: panele sterowania warte uruchomienia na VPS porównują dostępne opcje. Panel ogranicza liczbę codziennych operacji wykonywanych ręcznie. Nie zwalnia jednak z odpowiedzialności za maszynę i staje się kolejnym elementem wymagającym aktualizacji.

Po zakończeniu tej migracji kolejna jest znacznie krótsza. Migracja z serwera na serwer pomija cały etap inwentaryzacji, ponieważ konfiguracja została przygotowana samodzielnie i znajduje się w czytelnych plikach: przenoszenie działającego serwera na nowy VPS to skrócona wersja tego procesu w takim przypadku.

FAQ

Jak długo zmiana DNS dociera do wszystkich użytkowników?

Zależy to wyłącznie od wartości TTL, która była ustawiona dla rekordu A przed jego edycją, a nie od momentu wprowadzenia zmiany. Resolver, który zachował starą odpowiedź w pamięci podręcznej, nadal ją zwraca do czasu wygaśnięcia TTL. Dlatego rekord opublikowany z TTL wynoszącym 24 godziny może kierować użytkowników do starego serwera przez cały dzień. Zmniejsz TTL do 300 sekund co najmniej jeden dotychczasowy okres TTL przed planowaną zmianą. Następnie przełączenie zostanie zakończone u niemal wszystkich użytkowników w ciągu pięciu minut. Sprawdź, co jest faktycznie publikowane, za pomocą dig @$(dig +short NS example.com | head -1) example.com A +noall +answer.

Czy należy przenieść pocztę na VPS jednocześnie ze stroną?

Nie. Pozostaw rekordy MX skierowane do obecnego miejsca i przenieś wyłącznie stronę internetową. Samodzielnie hostowana poczta wymaga konfiguracji SPF, DKIM, DMARC, odwrotnego DNS oraz zbudowania nowej reputacji nadawcy. Jej awaria objawia się cichym umieszczaniem wiadomości w folderach spamu, a nie widocznym błędem. Pozostaw skrzynki pocztowe w planie przeznaczonym wyłącznie do obsługi poczty u dotychczasowego hostera albo u dedykowanego dostawcy poczty. Strona nadal może wysyłać wiadomości do resetowania haseł przez uwierzytelniony relay SMTP na porcie 587. Serwer pocztowy na VPS nie jest wtedy potrzebny.

Dlaczego po przeniesieniu wszystkie strony oprócz strony głównej zwracają 404?

Ponieważ reguły przepisywania znajdowały się w .htaccess, a nginx w ogóle nie odczytuje plików .htaccess. W Apache reguły te kierowały każdą ścieżkę bez odpowiadającego pliku do index.php. Tak działają przyjazne adresy permalinków. W nginx żądanie dotyczące /about/ szuka rzeczywistego pliku, nie znajduje go i zwraca 404. Dodaj try_files $uri $uri/ /index.php?$args; do bloku location /, uruchom sudo nginx -t, a następnie przeładuj konfigurację. Jeśli strona korzysta z wielu innych reguł .htaccess, których nie można łatwo przetłumaczyć, zainstaluj Apache z AllowOverride All. Reguły będą wtedy nadal działać bez zmian.

Czy można wrócić do poprzedniego serwera, jeśli nowy okaże się niesprawny?

Tak, pod warunkiem że stare konto nadal działa, a TTL ma niską wartość. Skieruj rekord A z powrotem na stary adres IP. Ruch wróci wtedy w czasie określonym przez TTL. Ograniczeniem są dane, a nie DNS. Wszystko, co zostanie zapisane na nowym serwerze po przełączeniu — nowe zamówienia, nowe komentarze i nowe przesłane pliki — nie będzie dostępne na starym serwerze. Wycofanie zmiany spowoduje ich utratę. Z tego powodu podczas przełączania należy zablokować operacje zapisu i sprawdzić stronę w ciągu kilku minut, a nie dopiero po kilku dniach. Po około tygodniu bezbłędnej pracy i czystych dziennikach wycofanie zmiany przestaje być realistyczne. Wtedy można anulować stary plan.