Przeniesienie serwera

Migracja serwera bez niespodzianek – co musisz sprawdzić zanim ruszysz

Dlaczego temat przenoszenia serwera to nie tylko kopiuj-wklej?

Zmiana serwera nie polega wyłącznie na przetransportowaniu plików z punktu A do punktu B. To proces, który wymaga całościowego spojrzenia na obecne środowisko IT, jego zależności i potrzeby. Dobrze przeprowadzona migracja serwera przez doświadczonych Administratorów i DevOps Linux pozwala uniknąć nieplanowanych przestojów, utraty danych, a nawet kosztownych przetasowań w aplikacjach klienta.

Jeśli potrzebujesz przeniesienia danych i aplikacji na nowy serwer – chętnie zrobimy do dla Ciebie!

Audyt środowiska przed migracją

Co tak naprawdę działa na obecnym serwerze?

Zanim podejmiesz pierwsze kroki, przygotuj kompletny wykaz działających aplikacji i usług. To nie tylko Metabase, ale też:

• backendowe API powiązane z adresami IP,
• usługi Redis, PostgreSQL, MongoDB, MySQL,
• serwery SMTP i IMAP,
• panele administracyjne (np. Cockpit, Webmin),
• lokalne procesy wsadowe i aplikacje CLI.

Zidentyfikuj, które z tych komponentów muszą działać 24/7, a które mogą być chwilowo wyłączone.

Zaplanuj dla ludzi, nie dla maszyn

Porozmawiaj z działem deweloperskim klienta. Jakie mają oczekiwania? W jakich godzinach aplikacje muszą działać? Czy prowadzą testy automatyczne? Jakie wersje baz danych i bibliotek są wymagane?

Nie zapomnij o sprawdzeniu:

• stref czasowych użytych w systemie,
• polityk bezpieczeństwa,
• adresów IP, które muszą mieć dostęp do systemu,
• metod autoryzacji i SSO (Single Sign-On).

Dane, crony i kopie zapasowe

Crontab nie przenosi się sam

Zadbaj o eksport całych konfiguracji crontaba (zarówno dla root, jak i użytkowników). Skrypt kopiujący dane z SFTP codziennie o 2:00 rano może nie zostać zauważony, ale jego brak w nowym środowisku będzie bolesny.

Backup: czy mamy do czego wracać?

Przed jakąkolwiek zmianą wykonaj kompletne kopie zapasowe:

• bazy danych (mysqldump, pg_dump),
• katalogi aplikacyjne (zachowując prawa i własności),
• pliki konfiguracyjne systemu i aplikacji,
• certyfikaty SSL/TLS,
• skrypty i jednostki systemd.

Upewnij się, że posiadasz plany przywracania tych zasobów.

Architektura nowego serwera

Predykcja zasobów – nie celuj w dolną granicę

Dobierz zasoby nowego serwera z uwzględnieniem:

• obciążenia CPU i RAM w ostatnich miesiącach,
• zużycia dysku (z zapasem x2),
• wzrostu liczby użytkowników w nadchodzących 12 miesiącach,
• wymaganych przestrzeni na logi i backupy.

Zastanów się nad wyborem RAID, podziałem na partycje i ewentualnym przeniesieniem na konteneryzacje (Docker, Podman) czy orkiestrację (Kubernetes, Nomad).

Czy nowy serwer posiada:

• publiczny i prywatny adres IP,
• odpowiednio skonfigurowany firewall,
• możliwość konfiguracji VPN,
• system monitoringu (np. Prometheus, Zabbix, Uptime Kuma),
• wsparcie dla kopii migawkowych lub snapshotów.

Bezpieczeństwo i certyfikaty

SSL/TLS – nie tylko Let’s Encrypt

Zidentyfikuj, które aplikacje korzystają z certyfikatów i kto je wystawił. Przenieś pliki .crt i .key lub zaplanuj reemisję. Upewnij się, że cron lub systemd odnawia certyfikaty automatycznie. Dla niektórych aplikacji (jak Jenkins, Metabase) certyfikat może być zdefiniowany wewnętrz aplikacji, nie w serwerze www.

Testy po migracji

Checklista po stronie administratora

1. Czy DNS został zaktualizowany?
2. Czy wszystkie aplikacje uruchomiły się bez błędów?
3. Czy API działają z oczekiwanych adresów?
4. Czy monitoring nie pokazuje anomalii?
5. Czy harmonogramy crona działają zgodnie z planem?
6. Czy backupy są wykonywane i testowane?

Komunikacja z zespołem

Nie zapomnij o przeprowadzeniu sesji testowej z zespołem klienta. Pozwól im sprawdzić, czy aplikacje funkcjonują tak, jak przed migracją. Wdroż iteracyjny pozwoli lepiej kontrolować ewentualne błędy i dostosowania.

Nieoczywiste pułapki migracji

Prawa dostępu i UID/GID

Po przeniesieniu plików może okazać się, że identyfikatory użytkowników (UID) lub grup (GID) są inne, a tym samym aplikacje nie mogą zapisać plików. Rozważ synchronizację ID z poprzedniego serwera lub rekursywną zmianę własności.

Skrypty startowe i usługi systemowe

Nie wszystkie aplikacje są uruchamiane przez systemd. Niektóre mogą mieć niestandardowe skrypty w /etc/init.d, które trzeba ręcznie przenieść i dostosować.