„Czy możecie przenieść nasze Odoo na nowy serwer, nie tracąc niczego?" to jedna z najczęstszych - i najbardziej uzasadnionych - obaw założyciela. Migracja Odoo na nowy serwer dotyka wszystkiego naraz: bazy danych, filestore, niestandardowych modułów, konfiguracji. A najgorszy scenariusz jest cichy: garstka wierszy, która po cichu się nie przeniosła, odkryta tygodnie później, gdy raport się nie zgadza. Oto jak sprawić, by ten ruch był nudny zamiast przerażającego.

Dlaczego migracje słusznie straszą

Migracja straszy, bo w odbiorze jest wszystko-albo-nic, a w rzeczywistości jest częściowa. Naiwne podejście - wyeksportuj kopię zapasową, przywróć na nowej maszynie, przekieruj DNS, miej nadzieję - działa przez większość czasu, co czyni je właśnie niebezpiecznym. Kiedy nie działa, często nie da się tego od razu stwierdzić. Filestore, który nie skopiował się w pełni, oznacza załączniki wyrzucające 404 później. Sekwencja, która się zresetowała, oznacza kolizję numerów faktur. Niestandardowy moduł, który nie został przeniesiony, oznacza, że menu po prostu zniknęło. Stawka jest wysoka, a informacja zwrotna opóźniona - to najgorsza kombinacja dla pewności siebie.

Sprawdź, zanim przeniesiesz

Pierwszym krokiem bezpiecznej migracji Odoo na nowy serwer nie jest przenoszenie - to inspekcja. Zanim cokolwiek się ruszy, mierzycie dokładnie, co jest na źródle: ile baz danych, jaka wersja Odoo, jaka wersja PostgreSQL, rozmiar i kształt filestore oraz każdy niestandardowy lub zewnętrzny moduł w ścieżce dodatków. Nie da się zwalidować ruchu, którego nigdy nie zmierzyliście, a większość katastrof migracyjnych wywodzi się z niespodzianki, którą inspekcja by wychwyciła - nieudokumentowany moduł, niedopasowanie wersji, filestore leżący gdzieś niestandardowo.

Inspekcja mówi też, czy to zwykłe przeniesienie, czy przeniesienie-plus-aktualizacja. Jeśli cel wymaga nowszej wersji Odoo, to inne zadanie z własną próbą generalną - zobacz aktualizacje bez paniki. Trzymanie tych dwóch spraw osobno to część tego, co utrzymuje migrację czystą: najpierw przenieś, potem aktualizuj, nigdy jedno i drugie na ślepo naraz.

Przenieś, potem to udowodnij

Samo przeniesienie odbywa się bezpośrednio serwer-serwer, a nie kruchym tańcem eksport/import przez laptopa. Baza danych przechodzi przez pg_dump i przywrócenie, filestore jest kopiowany w całości, a dodatki i konfiguracja idą razem z nim, więc nowa maszyna jest wierną kopią, nie przybliżeniem.

Ale przeniesienie to nie koniec - udowodnienie tego jest końcem. Krok, który zamienia migrację z aktu wiary w zadanie inżynieryjne, to walidacja kompletności po drugiej stronie. Liczby wierszy muszą się zgadzać, tabela po tabeli. Jeśli źródło ma daną liczbę rekordów w modelu, cel musi mieć dokładnie tyle samo. W prawdziwym Odoo to kilkaset tabel do uzgodnienia - ostatnia, którą przeszliśmy, miała ich ponad 700. Kiedy każda liczba się zgadza, ruch jest dowodliwie kompletny, nie tylko pozornie kompletny.

Rollback jako domyślność, nie jako coś dodatkowego

Nawet ostrożna migracja może trafić na coś nieoczekiwanego, więc bezpieczny projekt zakłada, że może. Jeśli walidacja znajdzie rozbieżność - liczbę, która się nie zgadza, tabelę, która się nie uzgodniła - ruch cofa się automatycznie i stawia was dokładnie tam, gdzie zaczęliście. Nie ma półzmigrowanego zawieszenia, gdzie stary system jest już rozebrany, a nowy jeszcze niegodny zaufania. Oryginał pozostaje żywy i nietknięty, dopóki kopia nie zostanie dowiedziona, a przełączenie jest zupełnie ostatnią rzeczą, która się dzieje.

To też dlatego migracja napędzana agentem jest najpierw-podgląd. Zanim przeniesienie się wykona, agent pokazuje plan: co przeczytał podczas inspekcji, co zamierza przenieść i jaka jest ścieżka rollbacku. Nic destrukcyjnego nie dzieje się na źródle bez potwierdzenia planu przez człowieka. Brama to to, co pozwala zautomatyzować coś tak konsekwentnego bez wstrzymywania oddechu.

Nudny wynik

Zrobiona w ten sposób, całość jest antyklimatyczna w najlepszym sensie: przeniesionych ponad 700 tabel, zero utraty danych, przełączenie, którego nikt nie zauważył. To cały cel. Migracja nie powinna wymagać heroizmu ani sztabu kryzysowego - powinna być wymierzonym, zwalidowanym ruchem z siatką bezpieczeństwa pod każdym krokiem. Ekscytacja jest oznaką, że coś poszło źle, nie że poszło dobrze. A ponieważ oryginał nigdy nie jest rozbierany, dopóki kopia nie zostanie dowiedziona, najgorszy realistyczny scenariusz to spędzenie wieczoru i skończenie dokładnie tam, gdzie zaczęliście - irytujące, ale nie katastrofa. Ta asymetria, mała strata przeciwko czystemu ruchowi, pozwala zaplanować migrację na zwykły tydzień zamiast obawiać się jej przez cały kwartał.

FAQ

Jak migrować Odoo na nowy serwer bez utraty danych?

Najpierw sprawdźcie źródło, żeby wiedzieć dokładnie, co się przenosi, potem zróbcie przeniesienie serwer-serwer bazy danych i filestore, a następnie zwalidujcie kompletność, dopasowując liczby wierszy tabela po tabeli. Trzymajcie gotowy automatyczny rollback, żeby każda rozbieżność zwróciła was do nietkniętego oryginału. Ta sekwencja sprawia, że migracja Odoo na nowy serwer jest dowodliwie bezstratna.

Ile trwa migracja Odoo?

Zwykłe przeniesienie bez zmiany wersji zwykle mierzy się w godzinach, zdominowane przez to, jak duży jest filestore i baza do skopiowania. Walidacja dodaje czasu, ale nie ryzyka. Migracje puchną do tygodni, gdy są połączone z aktualizacją wersji albo przeróbką niestandardowych modułów - dlatego czyściej jest traktować je jako osobne zadania.

Czy pg_dump wystarczy, żeby przenieść Odoo?

pg_dump obsługuje bazę danych, ale Odoo ma też filestore załączników i dokumentów, który żyje poza PostgreSQL, plus niestandardowe moduły i konfigurację. Kompletna migracja kopiuje to wszystko, a potem weryfikuje wynik - sama baza danych to tylko część systemu.