Dealownia
Menu
sprawdzono – jak sprawdzamy oferty

Migracja z hostingu współdzielonego na VPS bez przestoju

Przenosiny strony na VPS krok po kroku: inwentaryzacja, kopia plików i bazy, test przez plik hosts, obniżenie TTL, przełączenie DNS i co zrobić z pocztą.

Serwer i VPSzaktualizowano 6 min czytania

Redakcja serwisu Dealownia · ceny i fakty ze stron dostawców, jak sprawdzamy

Przeprowadzka na własny VPS bez przestoju: stary hosting obsługuje ruch do ostatniej chwili, nowy serwer jest sprawdzony przed zmianą DNS, a poczta działa bez przerwy. Opisujemy typowy przypadek – strona w PHP z bazą MySQL/MariaDB (np. WordPress) albo strona statyczna – przenoszona z hostingu z panelem (cPanel, DirectAdmin albo panel własny dostawcy) na VPS z nginx.

Czego potrzebujesz

  • VPS z Ubuntu 24.04 LTS albo Debianem 12 lub 13, przygotowany jak w poradniku od zera (użytkownik z sudo, klucz SSH, zapora, nginx).
  • Dostęp do panelu hostingu: menedżer plików lub FTP/SSH, phpMyAdmin albo eksport bazy, lista kont pocztowych.
  • Dostęp do miejsca, w którym edytujesz DNS domeny (u rejestratora albo w panelu hostingu).
  • Dwa–trzy dni zapasu: TTL trzeba obniżyć z wyprzedzeniem.

Porównanie planów: ranking VPS. Kiedy przeprowadzka w ogóle się opłaca, liczymy w poradniku o cenie po odnowieniu hostingu.

Krok 1. Inwentaryzacja

Zanim cokolwiek skopiujesz, spisz, co hosting robi za Ciebie. Najczęściej zapominane są rzeczy spoza katalogu strony:

  • Rekordy DNS – zrób zrzut całej strefy (A, AAAA, CNAME, MX, TXT, SRV). Sprawdź też, kto obsługuje DNS: dig +short NS example.pl. Jeśli serwery nazw należą do firmy hostingowej, po wypowiedzeniu usługi strefa może zniknąć razem z kontem.
  • Wersja PHP i rozszerzenia – z panelu albo z pliku phpinfo().
  • Bazy danych – nazwy, użytkownicy, kodowanie.
  • Zadania cron z panelu.
  • Reguły z .htaccess – przekierowania i przepisywanie adresów. nginx nie czyta .htaccess, każdą regułę trzeba przenieść do jego konfiguracji.
  • Poczta – skrzynki, aliasy, przekierowania, autorespondery.
  • Subdomeny i dodatkowe domeny wskazujące na ten sam katalog.

Krok 2. Obniż TTL

TTL mówi resolverom, jak długo trzymać odpowiedź w pamięci. Przy TTL 86400 (dzień) część odwiedzających trafiałaby na stary adres przez dobę po zmianie. W edytorze DNS ustaw TTL rekordów A, AAAA i www na 300 sekund co najmniej na tyle wcześniej, ile wynosi obecny TTL – zwykle dzień–dwa przed migracją. Sprawdź:

bash
dig +noall +answer example.pl A @1.1.1.1

Druga kolumna to pozostały czas w sekundach. Rekordów MX na razie nie ruszaj.

Krok 3. PHP i baza na VPS

Pakiety z repozytorium systemu dają PHP 8.3 na Ubuntu 24.04, 8.2 na Debianie 12 i 8.4 na Debianie 13. Przykład dla Ubuntu 24.04:

bash
sudo apt install -y php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-intl \
  php8.3-mbstring php8.3-xml php8.3-zip mariadb-server
sudo mysql -e "CREATE DATABASE strona CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'strona'@'localhost' IDENTIFIED BY 'mocne-haslo';
GRANT ALL PRIVILEGES ON strona.* TO 'strona'@'localhost';"

Jeśli strona wymaga starszej wersji PHP niż ta z systemu, najpierw sprawdź na hostingu, czy działa na nowszej – to tańsze niż utrzymywanie starego PHP na nowym serwerze.

Krok 4. Kopia plików

Kopiujesz na VPS jako deploy, więc najpierw utwórz katalog strony i oddaj go temu użytkownikowi (inaczej rsync i lftp skończą się błędem „Permission denied”):

bash
sudo mkdir -p /var/www/example.pl
sudo chown deploy:deploy /var/www/example.pl

Jeśli hosting daje SSH, użyj rsync – przy drugim przebiegu przeniesie tylko zmiany:

bash
rsync -az --info=progress2 uzytkownik@serwer-hostingu:public_html/ /var/www/example.pl/

Bez SSH zostaje FTP. lftp umie skopiować cały katalog:

bash
sudo apt install -y lftp
lftp -u uzytkownik ftps://serwer-hostingu -e "mirror --parallel=4 public_html /var/www/example.pl; quit"

Potem ustaw właściciela: sudo chown -R www-data:www-data /var/www/example.pl (dla WordPressa, który sam zapisuje pliki) albo deploy:deploy dla strony tylko do odczytu. Jeśli przed zmianą DNS chcesz zrobić drugi przebieg rsync, zrób go przed tym chown albo uruchom go przez sudo.

Krok 5. Kopia bazy

Przez SSH na hostingu:

bash
mysqldump --single-transaction --default-character-set=utf8mb4 -u uzytkownik -p nazwa_bazy > baza.sql

Bez SSH – eksport w phpMyAdmin (format SQL) zapisany na Twoim komputerze. Plik baza.sql musi trafić na VPS. Jeśli zrzut powstał na hostingu, pobierz go stamtąd prosto na VPS (polecenie wykonujesz na VPS-ie); jeśli masz go na swoim komputerze, wyślij go z komputera:

bash
# na VPS-ie, gdy plik leży na hostingu z SSH:
scp uzytkownik@serwer-hostingu:baza.sql ~/baza.sql
# na swoim komputerze, gdy plik pobrałeś z phpMyAdmina:
scp baza.sql deploy@203.0.113.10:~/baza.sql

Import na VPS (w katalogu domowym deploy) i usunięcie pliku, bo zawiera całą bazę:

bash
sudo mariadb strona < ~/baza.sql
rm ~/baza.sql

Zaktualizuj dane połączenia w konfiguracji aplikacji (w WordPressie DB_NAME, DB_USER, DB_PASSWORD, DB_HOST w wp-config.php; DB_HOST zwykle localhost).

Krok 6. nginx dla PHP

/etc/nginx/sites-available/example.pl (Ubuntu 24.04, PHP 8.3):

nginx
server {
    listen 80;
    listen [::]:80;
    server_name example.pl www.example.pl;
    root /var/www/example.pl;
    index index.php index.html;

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

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

    location ~ /\.(?!well-known) {
        deny all;
    }
}

try_files … /index.php?$args zastępuje typowe reguły „ładnych adresów” z .htaccess WordPressa. Ostatni blok blokuje dostęp do plików ukrytych (.env, .git, .htaccess). Na Debianie zmień numer wersji w ścieżce gniazda.

bash
sudo ln -s /etc/nginx/sites-available/example.pl /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Krok 7. Test przez plik hosts

Teraz sprawdzasz nowy serwer pod prawdziwą domeną, zanim zobaczy go ktokolwiek inny. Dopisz na swoim komputerze linię z adresem VPS:

tekst
203.0.113.10  example.pl www.example.pl

Plik to /etc/hosts na Linuksie i macOS oraz C:\Windows\System32\drivers\etc\hosts na Windowsie (edycja jako administrator). Bez zmiany pliku sprawdzisz to samo z curl:

bash
curl -sI --resolve example.pl:80:203.0.113.10 http://example.pl/ | head -1

Przejdź stronę jak użytkownik: logowanie do panelu, formularz kontaktowy, wyszukiwarka, wysyłka maila z formularza. Strona przez chwilę działa na HTTP, bo certyfikat HTTP-01 wystawisz dopiero po zmianie DNS. Jeśli nie chcesz ani minuty bez HTTPS, wystaw certyfikat wcześniej walidacją DNS-01 – opis w poradniku o certbocie. Po teście usuń wpis z hosts.

Krok 8. Zamrożenie treści i ostatnia synchronizacja

Przy stronie, w której ktoś pisze do bazy (komentarze, zamówienia), w dniu migracji wstrzymaj zmiany na starym hostingu: tryb konserwacji albo prośba do redakcji o przerwę na godzinę. Potem jeszcze raz rsync z kroku 4 (przeniesie tylko zmiany) i świeży zrzut bazy z kroku 5. Stronę statyczną wystarczy skopiować raz.

Krok 9. Przełączenie DNS i certyfikat

Zmień rekordy A (i AAAA, jeśli VPS ma IPv6) dla example.pl i www na adres VPS. Nie zmieniaj serwerów nazw ani rekordów MX. Gdy nowy adres jest widoczny:

bash
dig +short example.pl A @1.1.1.1
dig +short example.pl A @8.8.8.8
sudo certbot --nginx -d example.pl -d www.example.pl

Przez czas równy staremu TTL część ruchu wciąż trafia na stary hosting – dlatego treść była zamrożona. Obserwuj logi na VPS: sudo tail -f /var/log/nginx/access.log.

Krok 10. Poczta

Dopóki MX wskazuje na hosting, poczta działa tam jak dotąd. Problem zaczyna się przy wypowiedzeniu hostingu: znika skrzynka, a często też strefa DNS. Kolejność:

  1. Załóż skrzynki u nowego dostawcy poczty i przenieś zawartość (IMAP).
  2. Zmień MX, SPF, DKIM i DMARC – szczegóły w poradniku o poczcie we własnej domenie.
  3. Jeśli DNS obsługiwał hosting, przenieś strefę do rejestratora (wszystkie rekordy z kroku 1), a potem zmień serwery nazw.
  4. Wypowiedz hosting po tygodniu–dwóch, gdy w logach starego serwera nie ma już ruchu.

Najczęstsze problemy

  • Strona główna działa, podstrony zwracają 404. Reguły z .htaccess nie zostały przeniesione do nginx. Sprawdź try_files i przekierowania.
  • Po przełączeniu WordPress przekierowuje na stary adres albo na http://. Adres strony siedzi w bazie (siteurl, home w tabeli opcji). Przy zmianie domeny lub protokołu użyj wp search-replace z WP-CLI, bo zwykłe zastąpienie tekstu psuje zserializowane dane.
  • Krzaki zamiast polskich znaków. Zrzut zrobiony w innym kodowaniu niż baza. Powtórz eksport z --default-character-set=utf8mb4 i sprawdź kodowanie bazy docelowej.
  • Formularz kontaktowy przestał wysyłać maile. Na hostingu działała lokalna funkcja mail(), na VPS-ie nie ma serwera pocztowego, a wielu dostawców VPS blokuje wychodzący port 25. Ustaw w aplikacji wysyłkę przez SMTP dostawcy poczty.
  • Po wypowiedzeniu hostingu przestała działać domena. Strefa DNS była u hostingodawcy. Odtwórz rekordy u rejestratora ze zrzutu z kroku 1.

Co dalej

Na VPS-ie odpowiadasz za rzeczy, które robił hosting: zabezpieczenia, kopie zapasowe i monitoring. Ustaw je w pierwszym tygodniu, zanim wypowiesz stary hosting.

Powiązane poradniki