Jak przenieść stronę Drupal na inny serwer

Przeniesienie strony opartej na Drupal na inny serwer dla wielu administratorów oznacza stres, ryzyko przestojów i obawy o utratę danych. Odpowiednie przygotowanie oraz znajomość kluczowych kroków pozwalają jednak przeprowadzić migrację w sposób bezpieczny i przewidywalny. Poniżej znajdziesz praktyczny przewodnik, który przeprowadzi Cię przez cały proces: od analizy obecnego środowiska, przez kopię bazy i plików, aż po konfigurację na nowej maszynie i testy końcowe.

Przygotowanie do migracji strony Drupal

Analiza obecnego środowiska

Na początku warto dokładnie poznać środowisko, w którym obecnie działa Twoja strona Drupal. Sprawdź:

• wersję systemu Drupal (np. 7, 8, 9, 10), ponieważ od niej zależy sposób migracji oraz minimalne wymagania serwera,
• używaną wersję PHP, MySQL/MariaDB oraz serwera HTTP (Apache, Nginx),
• listę ważnych modułów, w tym szczególnie tych odpowiedzialnych za cache, logowanie, integracje z zewnętrznymi usługami,
• strukturę katalogów: gdzie znajdują się katalogi sites, profiles, modules, themes, a także katalog z plikami użytkowników (najczęściej sites/default/files).

Na tym etapie zanotuj wszystkie niestandardowe elementy: moduły własne, nietypowe ustawienia .htaccess, konfigurację cron oraz wszelkie dodatkowe zadania systemowe. Taka lista ułatwi kontrolę po przeniesieniu strony.

Wymagania nowego serwera

Nowy serwer musi spełniać co najmniej minimalne wymagania Drupala, ale w praktyce warto zadbać o nieco wyższe parametry. Sprawdź przede wszystkim:

• obsługiwaną wersję PHP i dostępne rozszerzenia (mysqli, gd, curl, mbstring, opcache),
• wersję MySQL/MariaDB oraz kodowanie domyślnych baz danych (utf8mb4),
• dostęp do powłoki SSH, który znacząco ułatwia przenoszenie danych oraz użycie narzędzi typu Drush,
• limity pamięci i czasu wykonywania skryptów (memory_limit, max_execution_time), istotne przy pracy z dużą bazą danych.

Jeżeli planujesz korzystać z Drush lub narzędzi CI/CD, upewnij się, że możesz je uruchamiać na nowym serwerze. W przypadku hostingu współdzielonego zwróć uwagę na ograniczenia dotyczące liczby procesów, harmonogramu zadań cron oraz możliwości tworzenia własnych kopii bezpieczeństwa.

Kopie zapasowe i plan powrotu

Przed jakąkolwiek ingerencją przygotuj pełne kopie zapasowe. Obejmują one:

• eksport bazy danych MySQL/MariaDB,
• kopię katalogu z plikami użytkowników (najczęściej sites/default/files),
• kopię całego katalogu z kodem Drupala, w szczególności katalogów modules, themes, libraries, profiles.

Najlepiej, jeśli kopie będą przechowywane na osobnym serwerze lub w chmurze. Dodatkowo przygotuj plan powrotu: jeśli migracja się nie powiedzie, musisz wiedzieć, jak przywrócić działanie strony na starym serwerze. Zanotuj, jakie rekordy DNS zostaną zmienione i ile czasu może potrwać ich propagacja.

Zaplanowanie okna serwisowego

Przeniesienie produkcyjnej strony Drupal powinno odbywać się w kontrolowanym oknie serwisowym. Określ:

• przedział czasowy o najmniejszym ruchu użytkowników,
• kiedy wyłączysz możliwość edycji treści (np. przełączenie strony w tryb konserwacji),
• kiedy wykonasz ostateczną kopię bazy i plików,
• moment przełączenia DNS lub zmiany konfiguracji wirtualnego hosta.

Dobrą praktyką jest wcześniejsze poinformowanie użytkowników o planowanych pracach. Nawet krótki komunikat na stronie lub wysłany newsletter zmniejsza liczbę zgłoszeń i nieporozumień w trakcie migracji.

Wykonanie kopii bazy danych i plików

Eksport bazy danych

Baza danych jest sercem Twojej instalacji Drupal. Zawiera treści, konfiguracje, użytkowników oraz wiele kluczowych informacji. Do eksportu możesz użyć:

• phpMyAdmin – wygodny panel webowy, często dostępny na hostingach współdzielonych,
• mysqldump – narzędzie w linii komend, idealne przy dostępie SSH,
• Drush – narzędzie dedykowane do zarządzania Drupalem (polecenia drush sql-dump, drush sql:dump).

Przy eksporcie zadbaj, aby baza została zapisana w jednym spójnym pliku SQL. Jeśli baza jest duża, warto włączyć kompresję gzip. Zapisz plik w bezpiecznym katalogu, najlepiej poza katalogiem dostępnym publicznie z poziomu przeglądarki.

Kopia katalogu files

Katalog sites/default/files przechowuje wszystkie przesłane pliki: obrazy, dokumenty, miniatury, pliki prywatne (jeśli nie są w innym katalogu). Bez tego katalogu strona będzie wyświetlała brakujące grafiki i błędy przy dostępie do załączników. Aby przygotować jego kopię, możesz użyć:

• FTP/SFTP – pobranie całego katalogu na lokalny komputer,
• rsync – wygodne narzędzie do synchronizacji plików pomiędzy serwerami,
• archiwizację po SSH (np. tar + gzip), a następnie ściągnięcie powstałego archiwum.

Staraj się zachować oryginalną strukturę katalogów i uprawnienia. Zwróć szczególną uwagę na pliki zdefiniowane jako prywatne w konfiguracji Drupala – często znajdują się w innym katalogu niż domyślny publiczny katalog files.

Kopia kodu Drupala

Oprócz bazy i plików użytkowników potrzebujesz kompletnego kodu Drupala: rdzenia, modułów, motywów i bibliotek. Jeśli korzystasz z systemu kontroli wersji (np. Git), przeniesienie kodu jest prostsze – wystarczy sklonować repozytorium na nowym serwerze. W innych przypadkach wykonaj archiwum:

• utwórz archiwum tar.gz lub zip obejmujące wszystkie pliki i katalogi,
• pomijaj katalogi cache oraz logi, jeśli nie są potrzebne przy starcie na nowym środowisku,
• upewnij się, że plik settings.php oraz inne pliki konfiguracyjne zostały uwzględnione.

Taka kopia pozwoli uruchomić stronę w identycznej wersji na nowym serwerze. Dzięki temu minimalizujesz ryzyko, że drobne różnice w kodzie będą powodować trudne do zdiagnozowania błędy.

Weryfikacja spójności kopii

Po wykonaniu kopii sprawdź ich spójność. Możesz:

• porównać rozmiar katalogu files na starym i nowym serwerze,
• przeliczyć sumy kontrolne (np. sha256) dla archiwów,
• zaimportować bazę danych na testową instancję i zweryfikować, czy nie występują błędy podczas importu.

Jeśli w trakcie eksportu wystąpiły błędy, lepiej je zdiagnozować teraz niż po przełączeniu ruchu użytkowników na nowy serwer. Dobrą praktyką jest także zachowanie kilku wersji kopii, wykonanych w różnych momentach przed migracją.

Konfiguracja Drupala na nowym serwerze

Przygotowanie środowiska serwerowego

Gdy kopie są gotowe, możesz przygotować nowe środowisko. Skonfiguruj:

• serwer WWW (Apache lub Nginx) – utwórz wirtualny host wskazujący na katalog, w którym znajdzie się Drupal,
• bazę danych – załóż nową bazę i użytkownika z odpowiednimi uprawnieniami (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP),
• wersję PHP – najlepiej dopasowaną do wymagań używanej wersji Drupal,
• obsługę mod_rewrite (w Apache) lub odpowiednią konfigurację przepisywania URL w Nginx.

Upewnij się, że katalogi wymagające zapisu (np. sites/default/files, katalog z tymczasowymi plikami) mają poprawne uprawnienia i są dostępne dla użytkownika, pod którym działa serwer WWW. To podstawa, aby uniknąć problemów z przesyłaniem plików i generowaniem miniatur.

Import bazy danych

Zaimportuj wcześniej wyeksportowaną bazę danych do nowo utworzonej bazy na nowym serwerze. W zależności od wielkości pliku możesz użyć:

• phpMyAdmin – wygodne przy małych i średnich bazach,
• mysql w linii komend: mysql -u użytkownik -p nazwa_bazy < plik.sql,
• Drush – np. drush sql-cli < plik.sql, jeśli masz zainstalowany Drush na nowym serwerze.

Po imporcie sprawdź, czy nie pojawiły się komunikaty o błędach, brakach tabel lub niezgodnościach wersji. Jeśli baza jest bardzo duża, możesz rozważyć import w kilku częściach lub skorzystanie z mechanizmów optymalizacji i kompresji.

Przeniesienie plików i ustawienie ścieżek

Następnie skopiuj katalog files na nowy serwer. Możesz to zrobić za pomocą:

• rsync – bezpośrednia synchronizacja pomiędzy serwerami,
• FTP/SFTP – jeśli nie masz dostępu SSH na oba serwery,
• rozpakowania wcześniej przygotowanego archiwum w odpowiednim miejscu.

Po skopiowaniu upewnij się, że ścieżki w konfiguracji Drupala są poprawne. W panelu administracyjnym lub w ustawieniach możesz znaleźć informacje o katalogu publicznych i prywatnych plików. Jeśli wcześniej korzystałeś z niestandardowych lokalizacji, muszą one być dostępne również na nowym serwerze.

Dostosowanie pliku settings.php

Kluczowym elementem konfiguracji jest plik settings.php, zazwyczaj znajdujący się w katalogu sites/default. W tym pliku znajdują się informacje o połączeniu z bazą danych oraz dodatkowe ustawienia środowiska. Dostosuj w nim:

• nazwę bazy danych, użytkownika oraz hasło, aby odpowiadały nowemu serwerowi,
• nazwę hosta bazy danych (często localhost, ale na niektórych hostingach może być inny adres),
• ustawienia cache, jeśli korzystasz z zewnętrznych systemów (np. Redis, Memcached),
• środowiskowe ustawienia specyficzne dla poprzedniego serwera (np. ścieżki do tymczasowych katalogów), które teraz trzeba zaktualizować.

Po dokonaniu zmian warto czasowo zwiększyć poziom raportowania błędów, aby szybko wyłapać nieprawidłowe konfiguracje. Pamiętaj też o odpowiednich uprawnieniach pliku settings.php – nie powinien być zapisywalny przez wszystkich użytkowników systemu.

Testy, DNS i finalne przełączenie

Testowanie strony na nowym serwerze

Zanim przełączysz ruch użytkowników, dokładnie przetestuj działanie strony na nowym serwerze. W tym celu możesz:

• skorzystać z tymczasowej subdomeny lub wpisu w pliku hosts na własnym komputerze, aby wskazać domenę na nowy adres IP,
• sprawdzić logowanie użytkowników, dodawanie treści, działanie formularzy kontaktowych,
• zweryfikować generowanie miniatur obrazów, działanie wyszukiwarki oraz modułów integracyjnych (np. płatności, systemów mailingowych),
• obejrzeć raporty statusu w panelu administracyjnym i zwrócić uwagę na ostrzeżenia.

Jeśli pojawią się błędy, zdiagnozuj je na tym etapie. Bardzo pomocne bywają logi PHP, logi serwera WWW oraz wewnętrzne logi Drupala. Nie przechodź dalej, dopóki strona nie będzie działała stabilnie.

Optymalizacja pamięci podręcznej i wydajności

Przeniesienie strony jest dobrym momentem na zadbanie o wydajność. Sprawdź konfigurację:

• cache stron i bloków – upewnij się, że pamięć podręczna jest włączona i poprawnie skonfigurowana,
• agregację CSS i JS – łączenie i kompresja zasobów statycznych przyspiesza ładowanie strony,
• systemów cache zewnętrznych – jeśli korzystasz z Redis czy Memcached, upewnij się, że nowe połączenia działają i są stabilne,
• opcache w PHP – poprawia wydajność interpretacji skryptów.

Na tym etapie warto również porównać czasy odpowiedzi strony na starym i nowym serwerze. Jeśli nowa konfiguracja jest wolniejsza, przeanalizuj parametry serwera bazodanowego i HTTP, a także sprawdź, czy nie brakuje jakichś rozszerzeń PHP.

Przełączenie DNS i monitorowanie

Gdy testy zakończą się pomyślnie, możesz przełączyć ruch na nowy serwer. Najczęściej odbywa się to poprzez zmianę rekordów A lub CNAME w konfiguracji DNS Twojej domeny. Warto:

• obniżyć TTL rekordów DNS na kilka godzin lub dni przed migracją, aby przyspieszyć propagację zmian,
• wykonać ostateczną synchronizację bazy i plików, jeśli w trakcie testów użytkownicy nadal korzystali ze starej strony,
• utrzymywać oba serwery równolegle przez krótki czas, aby mieć możliwość szybkiego powrotu w razie problemów.

Po przełączeniu DNS monitoruj logi, obciążenie serwera oraz zgłoszenia od użytkowników. W pierwszych godzinach zwracaj szczególną uwagę na błędy 500, 404 oraz wszelkie nietypowe zachowania strony Drupal.

Utrzymanie i dalszy rozwój po migracji

Po udanym przeniesieniu strony na nowy serwer warto od razu wdrożyć dobre praktyki utrzymaniowe. Obejmują one:

• regularne kopie zapasowe bazy danych i plików, przechowywane poza serwerem produkcyjnym,
• aktualizację rdzenia Drupal oraz modułów, gdy tylko pojawią się poprawki bezpieczeństwa,
• monitoring dostępności i wydajności strony (np. za pomocą zewnętrznych narzędzi),
• przegląd uprawnień użytkowników oraz zbędnych modułów, które mogą obciążać serwer lub stanowić ryzyko.

Nowe środowisko daje też możliwość rozszerzenia architektury: możesz dodać systemy cache, rozdzielić bazę danych na osobny serwer, zastosować sieci dostarczania treści do plików statycznych. Przeniesienie strony Drupal to nie tylko techniczny obowiązek, ale również okazja do gruntownego uporządkowania konfiguracji i przygotowania się na dalszy rozwój projektu.