← Wróć do bloga

Kopia zapasowa to rzecz, o której wiadomo, że jest — do dnia, w którym trzeba jej użyć. Wtedy okazuje się, że archiwum zawiera bazę danych, ale nie zdjęcia produktów. Albo że ma jedno i drugie, a mimo to po odtworzeniu nie działają płatności. Albo że robi się regularnie od dwóch lat i nigdy nikt jej nie odtworzył, więc nie wiadomo, czy w ogóle da się to zrobić.

Trzy elementy, bez których nie da się odtworzyć sklepu Magento: zrzut bazy danych, katalog pub/media ze zdjęciami produktów oraz plik app/etc/env.php zawierający klucz szyfrowania. Kod aplikacji odtwarza się z repozytorium git, a katalogi var, generated i pub/static generują się na nowo, więc nie trzeba ich kopiować. Bez pliku env.php zaszyfrowane dane w bazie pozostają nie do odczytania

Pierwsza pułapka: wbudowany mechanizm Magento

Magento ma własne polecenie do wykonywania kopii i zakładkę w panelu administracyjnym. Łatwo uznać to za wystarczający plan — i to jest błąd, bo funkcje kopii zapasowych w Magento są oznaczone jako przestarzałe od wersji 2.3.0, a w liniach wcześniejszych od 2.1.16 i 2.2.7. W nowszych instalacjach bywają domyślnie wyłączone, a Adobe odsyła do narzędzi zewnętrznych, takich jak Percona XtraBackup.

Dochodzi do tego kwestia praktyczna: wykonywanie kopii dużej bazy z poziomu aplikacji potrafi obciążyć sklep w trakcie jego pracy. Kopie robi się narzędziami bazy danych i systemu plików, a nie z panelu sklepu.

Trzy elementy, bez których odtworzenie się nie uda

Baza danych

Zamówienia, klienci, katalog, konfiguracja. Rośnie najszybciej i najczęściej to ona decyduje o tym, jak długo trwa odtworzenie. Przy większych sklepach warto rozdzielić kopię pełną od przyrostowej, zamiast codziennie zrzucać wszystko.

Katalog pub/media

Zdjęcia produktów, pliki do pobrania, załączniki. Zajmuje najwięcej miejsca, ale zmienia się wolno, więc nadaje się do kopii przyrostowej. To ten element, o którym najczęściej zapomina się przy pierwszym podejściu — baza odtwarza się bez błędu, a sklep pokazuje puste miejsca zamiast produktów.

Plik app/etc/env.php

Kilka kilobajtów i jednocześnie najważniejsza rzecz na tej liście. Zawiera klucz szyfrowania, którym Magento zabezpiecza wrażliwe wartości zapisane w bazie — między innymi tokeny płatności i dostępy do integracji.

Konsekwencja jest nieprzyjemna i mało oczywista: możesz mieć komplet bazy i mediów, odtworzyć sklep, zobaczyć wszystkie zamówienia i produkty — a zaszyfrowane wartości pozostaną nie do odczytania. Trzeba je wtedy konfigurować od zera, co przy rozbudowanych integracjach potrafi zająć więcej czasu niż całe odtworzenie.

Plik warto trzymać także poza samym archiwum, w menedżerze haseł albo w sejfie na dostępy — osobno od kopii, do której sięga się raz na rok.

Czego nie trzeba kopiować

Równie ważne, bo kopiowanie wszystkiego wydłuża proces i powiększa archiwum bez żadnego zysku:

  • Kod aplikacji — jest w repozytorium git i w Composerze, odtwarza się poleceniem
  • var/, generated/, pub/static — generują się na nowo po wdrożeniu

To zresztą dobry test dojrzałości konfiguracji: jeśli kodu nie da się odtworzyć z repozytorium, bo ktoś poprawiał pliki bezpośrednio na serwerze, problem jest większy niż kopie zapasowe. Opisaliśmy to przy okazji środowisk i wdrażania zmian.

Gdzie trzymać kopie

Jedna zasada, która przesądza o wszystkim: kopia na tym samym serwerze co sklep nie jest kopią zapasową. Chroni przed pomyłką administratora i przed nieudaną aktualizacją, ale nie przed awarią dysku, nie przed utratą dostępu do konta i nie przed szyfrowaniem danych przez atakującego — bo wtedy zaszyfrowane zostaje wszystko, co jest w zasięgu.

Minimum sensowne to kopia na innej maszynie, u innego dostawcy. Przy sklepie, który realnie zarabia, warto mieć też kopię, do której sam sklep nie ma prawa zapisu — tak, żeby przejęcie serwera nie oznaczało przejęcia archiwum. To ten sam sposób myślenia, który opisaliśmy we wpisie o bezpieczeństwie sklepu Magento.

Rzecz, która odróżnia kopię od pliku

Tu jest sedno całego tekstu. Kopia, której nigdy nie odtworzyłeś, nie jest kopią zapasową — jest plikiem, co do którego masz nadzieję.

Test odtworzenia robi się na środowisku testowym, nie na produkcji, i odpowiada na pytania, których nie da się rozstrzygnąć teoretycznie: ile to trwa, czy archiwum w ogóle się rozpakowuje, czy ktoś pamięta hasła potrzebne w trakcie, czy po odtworzeniu działają płatności i wysyłka maili. Raz na kwartał w zupełności wystarczy, a pierwszy taki test prawie zawsze coś wykaże.

Przy okazji warto zapisać, ile to zajęło. To jedyna uczciwa odpowiedź na pytanie „jak szybko wrócimy po awarii”, a prędzej czy później ktoś je zada.

Dane osobowe w kopiach

Archiwum sklepu zawiera dane klientów, więc podlega tym samym zasadom co sklep. W praktyce oznacza to przynajmniej dwie rzeczy do ustalenia: jak długo przechowujecie kopie i co się dzieje z danymi w archiwum, gdy klient prosi o ich usunięcie. To pytania, na które odpowiada się raz, przy projektowaniu procesu — a nie wtedy, gdy wpłynie pierwszy wniosek. Szczegóły warto potwierdzić z prawnikiem.

Lista kontrolna

  1. Czy kopia obejmuje bazę, pub/media i app/etc/env.php?
  2. Czy leży na innej maszynie niż sklep?
  3. Czy sklep ma prawo ją nadpisać lub skasować?
  4. Kiedy ostatnio ktoś ją odtworzył i ile to trwało?
  5. Czy ktokolwiek dowie się, że kopia przestała się wykonywać?
  6. Jak długo przechowujecie archiwa i co z danymi osobowymi w środku?

Punkt czwarty jest tym, który odróżnia realny plan od dobrych chęci. Punkt piąty bywa drugi w kolejności: cicha awaria harmonogramu wychodzi na jaw dokładnie wtedy, kiedy nie powinna.