Kopia zapasowa Odoo, której nigdy nie przywróciliście, to nie plan - to nadzieja z nazwą pliku. Prawie każdy ma kopie zapasowe. Znacznie mniej osób kiedykolwiek jakąś przywróciło, co znaczy, że znacznie mniej osób faktycznie wie, czy ich kopie działają. Dowiadujecie się tego w najgorszy możliwy dzień, w środku awarii, że archiwum jest uszkodzone albo że filestore nigdy nie został w nim uwzględniony. Oto jak ustawić kopie zapasowe, monitoring i odzyskiwanie, które naprawdę przećwiczyliście - tak by „serwer padł" stało się niedogodnością, nie katastrofą.

Kopia zapasowa, której nikt nie testuje

Niewygodna statystyka krążąca wśród ludzi, którzy zajmują się tym zawodowo, mówi, że spora część prób przywrócenia kopii zapasowej zawodzi w momencie odzyskiwania - archiwum jest nieczytelne, filestore brakuje, albo proces nigdy nie został przetestowany od początku do końca. Kopię zapasową Odoo szczególnie łatwo zrobić w połowie źle, bo Odoo przechowuje dane w dwóch miejscach: bazie PostgreSQL i osobnym filestore załączników i dokumentów. Zrzućcie bazę i zapomnijcie o filestore, a wasze przywrócenie wróci z każdym PDF-em faktury i przesłanym dokumentem zniknionym. Kopia zapasowa wyglądała dobrze. Po prostu nie była kompletna, i nikt tego nie sprawdził.

Backupujcie obie połówki, według harmonogramu

Prawdziwa kopia zapasowa Odoo obejmuje obie połówki i robi to automatycznie. Ręczne kopie zapasowe są zapominane; zaplanowane zadanie nie. Mechanika jest dobrze znana: pg_dump dla bazy danych, archiwum katalogu filestore, połączone w jeden datowany pakiet, tak by przywrócenie miało wszystko w jednym miejscu. Zaplanujcie, żeby działało samo, i zweryfikujcie, że zadanie faktycznie wyprodukowało plik - zadanie cron, które po cichu zawiodło trzy tygodnie temu, to swój własny rodzaj pułapki.

Wyprowadźcie kopie poza serwer

Kopia zapasowa, która żyje na tym samym serwerze, co chroniona rzecz, to nie disaster recovery - to historia wersji. Jeśli serwer padnie, zostanie skompromitowany albo przypadkowo usunięty, lokalna kopia zapasowa ginie razem z nim. Więc kopie muszą być ściągnięte poza serwer, najlepiej na inną infrastrukturę w innej lokalizacji. To właśnie chroni was przed awariami, które faktycznie zatapiają firmy: utrata sprzętu, skompromitowany host, niefortunne rm. Poza serwerem to różnica między złym popołudniem a złym kwartałem.

Gdy agent prowizjonuje system, to jest coś, co może ustawić pierwszego dnia zamiast „później" - zaplanowane kopie zapasowe, automatycznie ściągane poza serwer, jako część tej samej instalacji, która postawiła instancję. To warstwa prowadzenia tego, co agent potrafi, a traktowanie tego jako część prowizjonowania to sposób, by przestało być zadaniem, do którego wszyscy się zabierają i nigdy nie dochodzą.

Przećwiczcie odzyskiwanie

Oto krok, który zamienia kopie zapasowe z teatru w prawdziwy plan: próba przywrócenia. Stawiacie kopię zapasową gdzieś na czysto - w jednorazowym środowisku - i potwierdzacie, że faktycznie wraca: baza się ładuje, filestore jest nietknięty, dane są poprawne, aplikacja działa. Udany test archiwum dowodzi tylko, że plik jest czytelny. Tylko pełne przywrócenie dowodzi, że Odoo potrafi załadować bazę i filestore razem. To różne twierdzenia, a luka między nimi to miejsce, gdzie żyją katastrofy.

Przetestowaliśmy nasze własne odzyskiwanie przez restart i przez przywrócenie właśnie z tego powodu - runbook, którego nigdy nie uruchomiliście, to fikcja. Zalecany rytm jest skromny: okresowe przywrócenie niedawnej kopii zapasowej do testowej bazy danych, weryfikacja danych, rozebranie. Pół godziny udowadniania, że działa, bije godzinę odkrywania, że nie działa, podczas gdy klienci czekają. A ponieważ to czyste, jednorazowe środowisko, sama próba jest bezpieczna - ta sama staranność, która rządzi migracją, obowiązuje i tutaj.

Monitoring zamyka pętlę

Kopie zapasowe mówią wam, że możecie się odzyskać; monitoring mówi wam, kiedy tego potrzebujecie. Kontrole dostępności i zdrowia obserwują instancję, więc słyszycie o kłopotach, zanim zrobią to wasi klienci - usługa, która padła, dysk, który się zapełnia, zadanie kopii zapasowej, które się nie wykonało. Razem, kopie zapasowe poza serwerem, przetestowane przywrócenie i aktywny monitoring zamieniają awarię pojedynczego komponentu w coś rutynowego i odzyskiwalnego. Nic z tego nie jest ekscytujące, i o to właśnie chodzi.

Nudne celowo

Dobra higiena operacyjna jest celowo nudna. Monitoring, o którym nie myślicie, kopie zapasowe ściągnięte gdzieś bezpiecznie i odzyskiwanie, które faktycznie przećwiczyliście, to to, co zamienia „serwer padł" z wydarzenia kończącego firmę w linijkę w logu incydentów. To cała ambicja - nie heroizm podczas kryzysu, ale kryzys, który nigdy się nim nie staje, bo nudna praca została zrobiona wcześniej. Jeśli chcecie, żeby agent ustawił to pierwszego dnia, to część Zoxron MCP.

FAQ

Jak poprawnie zrobić kopię zapasową Odoo?

Obejmijcie zarówno bazę PostgreSQL, jak i filestore - kopia zapasowa Odoo, która pomija filestore, traci każdy załącznik. Zautomatyzujcie ją na harmonogramie z pg_dump plus archiwum filestore, połączcie je razem i ściągnijcie kopie z serwera na osobną infrastrukturę, tak by awaria hosta nie mogła ich zabrać ze sobą.

Jak często testować kopie zapasowe?

Regularnie, i na prawdziwym przywróceniu - nie tylko teście archiwum. Przywrócenie niedawnej kopii zapasowej do jednorazowej bazy danych i weryfikacja danych zajmuje około pół godziny i to jedyna rzecz, która faktycznie dowodzi, że odzyskiwanie działa. Comiesięczna próba to rozsądna baza; dokładny rytm ma mniejsze znaczenie niż robienie tego, zanim będzie potrzebne.

Jaki jest dobry plan disaster recovery dla Odoo?

Trzy części: automatyczne kopie zapasowe bazy danych i filestore, kopie przechowywane poza serwerem na osobnej infrastrukturze i przećwiczona próba przywrócenia, która dowodzi, że kopia wraca czysto. Dodajcie monitoring, żeby wcześnie dowiadywać się o awariach. Odzyskiwanie, które faktycznie przeprowadziliście, to plan; takie, które tylko spisaliście, to nadzieja.