Backup, który naprawdę ratuje sklep: strategia kopii dla PrestaShop

Backup to temat, o którym wszyscy wiedzą, że jest ważny, i który mimo to najczęściej zawodzi w chwili próby. Powód jest prozaiczny: kopie są robione, ale nikt nigdy nie sprawdził, czy da się z nich wrócić. W spokojne dni backup to plik, który leży i uspokaja. W dniu awarii okazuje się, że jest niekompletny, uszkodzony albo że jego odtworzenie zajmuje trzy dni, których nie masz. Ten tekst pokazuje, jak zbudować strategię kopii dla sklepu na PrestaShop, która naprawdę ratuje sklep, a nie tylko wypełnia rubrykę w umowie. Różnica między jednym a drugim ujawnia się zwykle w najgorszym możliwym momencie, gdy sklep leży, a zegar strat tyka, więc kopię warto zbudować i sprawdzić, zanim będzie potrzebna, a nie dopiero w trakcie kryzysu. Dobrze zaplanowany backup sklepu PrestaShop bywa ostatnią, ale decydującą linią obrony.

Kopia, której nikt nie testował, to nie kopia

Najważniejsze zdanie o backupie brzmi tak: kopia zapasowa istnieje dopiero wtedy, gdy udało się z niej odtworzyć działający sklep. Wszystko wcześniej to założenie. Bardzo wiele firm żyje w przekonaniu, że są zabezpieczone, bo hosting „robi kopie”. Dopiero awaria pokazuje, że te kopie obejmowały tylko pliki bez bazy, albo że baza była, ale sprzed dwóch tygodni, albo że w ogóle nie dało się ich pobrać bez pomocy dostawcy, który akurat ma dwa dni na reakcję.

Backup to nie czynność robienia kopii, tylko zdolność powrotu. Ta różnica zmienia wszystko. Gdy myślisz o backupie jako o zdolności powrotu, zaczynasz zadawać właściwe pytania: jak szybko wrócę, ile danych stracę, kto to zrobi i czy na pewno zadziała. Dopiero te pytania prowadzą do strategii, a nie do samego zaznaczenia opcji „twórz kopie” w panelu.

Co składa się na pełny backup sklepu PrestaShop

Sklep na PrestaShop to nie jeden byt, tylko kilka warstw, które muszą do siebie pasować. Kopia jednej bez pozostałych zwykle jest bezużyteczna, bo odtworzony sklep nie będzie spójny.

Najczęstszy błąd to kopia bazy albo samych plików, ale nie jednego i drugiego naraz, z tego samego momentu. Sklep odtworzony z plików sprzed tygodnia i bazy sprzedanej dzisiaj będzie niespójny: baza wskaże na zdjęcia i moduły, których w plikach nie ma. Dlatego kopia musi być spójna w czasie, czyli obejmować wszystkie warstwy z tego samego punktu, a nie zlepek fragmentów z różnych dni.

Reguła 3-2-1 w praktyce e-commerce

Sprawdzoną ramą myślenia o kopiach jest reguła 3-2-1. Trzy kopie danych, na dwóch różnych nośnikach, z czego jedna w innej lokalizacji. Brzmi jak teoria, a rozwiązuje bardzo konkretne scenariusze, które w e-commerce zdarzają się naprawdę.

Trzy kopie chronią przed sytuacją, w której jedna jest uszkodzona, a druga akurat w trakcie nadpisywania. Dwa różne nośniki bronią przed awarią jednego typu przechowywania. Najważniejszy jest jednak ten ostatni element: jedna kopia poza serwerem sklepu. Backup trzymany na tej samej maszynie co sklep ginie razem z nim, gdy padnie dysk, gdy atak obejmie cały serwer albo gdy dostawca ma poważną awarię. Kopia w innej lokalizacji jest jedyną, która przetrwa scenariusz, w którym tracisz cały serwer.

W praktyce oznacza to najczęściej kombinację kopii lokalnej, którą można szybko odtworzyć przy drobnej awarii, i kopii zdalnej w niezależnym miejscu, która ratuje przy poważnej katastrofie. Ta druga jest wolniejsza w użyciu, ale to ona odpowiada za przetrwanie najgorszego dnia.

Do tej reguły warto dodać jeden współczesny akcent: odporność na szyfrowanie. Ataki, które szyfrują dane i żądają okupu, celują dziś także w kopie zapasowe, bo atakujący wie, że sprawny backup unieważnia jego groźbę. Dlatego kopia, do której nie da się dopisać ani nadpisać z poziomu zaatakowanego serwera, jest warta więcej niż kilka kopii dostępnych online. Trzymanie przynajmniej jednej wersji poza zasięgiem bieżących dostępów to nie przesada, tylko odpowiedź na scenariusz, który zdarza się sklepom każdej wielkości.

RPO i RTO: dwie liczby, które ustalają strategię

Za każdą sensowną strategią backupu stoją dwie liczby. RPO to ile danych możesz stracić, mierzone w czasie: jeśli kopia powstaje raz na dobę, w najgorszym razie tracisz dobę zamówień. RTO to ile czasu zajmuje powrót do działania po awarii. Te dwie wartości nie wynikają z technologii, tylko z biznesu: z tego, ile zamówień przechodzi przez sklep i ile kosztuje godzina przestoju.

Sklep robiący dużą sprzedaż nie może pozwolić sobie na dobową kopię, bo utrata doby zamówień to utrata danych o klientach, których nie da się odtworzyć, i realny chaos w realizacji. Im wyższy obrót, tym częstsze kopie i tym szybsze odtworzenie muszą być. Ustalenie tych dwóch liczb to pierwszy krok strategii, bo wyznaczają one wszystko inne: częstotliwość, sposób przechowywania i to, ile warto w backup zainwestować.

Gdzie backup najczęściej zawodzi

Awarie backupu mają swój powtarzalny katalog. Warto go znać, bo większość problemów da się wykryć zawczasu, jeśli wiadomo, gdzie patrzeć.

• Kopia obejmuje pliki, ale nie bazę danych, albo odwrotnie, więc odtworzony sklep jest niespójny.
• Backup leży na tym samym serwerze co sklep i ginie razem z nim.
• Proces po cichu przestał działać tygodnie temu, a nikt tego nie zauważył, bo nie ma alertu.
• Kopie są, ale ich odtworzenie trwa tak długo, że nie mieści się w akceptowalnym przestoju.
• Nikt nigdy nie próbował odtworzenia, więc uszkodzenie kopii wychodzi na jaw dopiero w kryzysie.

Wspólny mianownik większości tych porażek to brak nadzoru. Backup ustawiono kiedyś i uznano temat za zamknięty. Tymczasem kopia to proces, który trzeba pilnować jak każdy inny: sprawdzać, czy się wykonuje, czy jest kompletna i czy da się jej użyć. Bez tego nadzoru backup cicho gnije, a jego brak wychodzi na jaw w najgorszym momencie.

Test odtworzenia: jedyny dowód, że backup działa

Jest tylko jeden sposób, żeby mieć pewność, że backup zadziała: regularnie go odtwarzać. Test odtworzenia polega na wzięciu kopii i postawieniu z niej działającego sklepu na osobnym środowisku, a potem sprawdzeniu, że wszystko jest na miejscu: produkty, zamówienia, ustawienia, zdjęcia. Dopiero udany test zamienia założenie w pewność.

Test odtworzenia daje też coś, czego nie da żadna teoria: realny pomiar RTO. Dopiero gdy raz przejdziesz przez pełne odtworzenie, wiesz, ile ono naprawdę trwa, i możesz porównać tę liczbę z tym, ile przestoju sklep wytrzymuje. Bardzo często pierwszy test odkrywa, że odtworzenie zajmuje wielokrotnie więcej czasu, niż wszyscy zakładali, i że trzeba zmienić strategię, zanim awaria zmusi do tego w gorszych warunkach.

Dlatego test odtworzenia powinien być cyklem, a nie jednorazowym eksperymentem. Sklep się zmienia, dochodzą moduły i integracje, więc kopia, która odtwarzała się bez problemu pół roku temu, dziś może wymagać dodatkowych kroków. Regularny test wychwytuje te zmiany, zanim staną się problemem.

Warto też spisać sam przebieg odtworzenia. Gdy kroki powrotu są udokumentowane, przywrócenie nie zależy od tego, czy akurat dostępna jest jedna konkretna osoba, która pamięta, jak to zrobić. W kryzysie liczy się każda minuta, a szukanie po omacku właściwej kolejności działań to najgorszy moment na naukę. Prosty opis procedury zamienia odtworzenie z improwizacji w powtarzalny proces, który przejdzie każdy z zespołu, a nie tylko autor kopii. Ten sam dokument przydaje się przy zmianie wykonawcy, bo przenosi wiedzę o sklepie razem z danymi.

Backup przy aktualizacjach i wdrożeniach

Nie każda awaria przychodzi z zewnątrz. Spora część poważnych problemów rodzi się z własnych zmian: nieudanej aktualizacji, wgrania modułu, który zepsuł checkout, importu, który uszkodził dane. W każdej z tych sytuacji świeża kopia sprzed zmiany jest różnicą między cofnięciem się o minuty a odbudowywaniem sklepu od zera.

Dlatego dobra praktyka jest prosta: przed każdą istotną zmianą powstaje kopia, a plan zmiany zawiera plan powrotu. To domyka temat aktualizacji bezpieczeństwa w PrestaShop, bo bezpieczna aktualizacja i sprawny backup to dwie strony tej samej ostrożności. Aktualizujesz odważnie właśnie dlatego, że masz do czego wrócić.

Wersjonowanie i retencja: ile kopii trzymać i jak długo

Jedna kopia to za mało, i to nie tylko z powodu ryzyka uszkodzenia. Część problemów ujawnia się z opóźnieniem: uszkodzony import, błąd w danych, a czasem włamanie, które siedzi w sklepie od tygodni. Jeśli trzymasz wyłącznie najświeższą kopię, a ona zdążyła już nadpisać stan sprzed problemu, cofnięcie się do zdrowego punktu jest niemożliwe. Dlatego kopie się wersjonuje: obok tej najnowszej trzyma się też starsze punkty w czasie.

Rozsądna retencja to zwykle kombinacja kopii z ostatnich dni, tygodni i miesięcy. Świeże pozwalają cofnąć się po drobnej wpadce, starsze ratują w sytuacji, gdy problem tlił się dłużej. Ile dokładnie trzymać, zależy od tego, jak szybko wykrywasz błędy i jakie masz obowiązki wobec danych. Ważne, żeby to była świadoma decyzja, a nie przypadkowy efekt domyślnych ustawień, bo to właśnie retencja decyduje, jak głęboko w przeszłość możesz sięgnąć w razie potrzeby.

Automatyzacja i alerty: backup bez człowieka

Backup, który zależy od tego, czy ktoś pamięta go zrobić, prędzej czy później zawiedzie. Ludzka pamięć jest zawodna, a kopie robione ręcznie znikają dokładnie wtedy, gdy jest najwięcej pracy, czyli w sezonie, gdy ryzyko awarii i tak rośnie. Dlatego kopie muszą powstawać automatycznie, według harmonogramu, bez udziału człowieka.

Sama automatyzacja to jednak nie wszystko, bo automat też potrafi po cichu przestać działać. Skończy się miejsce, zmieni się hasło, padnie połączenie z magazynem kopii. Jeśli nikt tego nie zauważy, sklep miesiącami żyje w przekonaniu, że jest zabezpieczony, choć ostatnia poprawna kopia pochodzi sprzed pół roku. Rozwiązaniem jest alert o nieudanym backupie: powiadomienie, które rusza, gdy kopia się nie wykona. Backup, który sam zgłasza swoją porażkę, jest jedyną wersją, na której da się polegać.

Backup a bezpieczeństwo i zgodność

Kopie zapasowe mają dwie twarze. Są zabezpieczeniem, ale też miejscem, w którym leżą dane osobowe klientów, więc same wymagają ochrony. Backup przechowywany bez zabezpieczenia to gotowy wyciek: atakującemu nie trzeba nawet włamywać się do sklepu, wystarczy, że sięgnie po niepilnowaną kopię. Dlatego kopie powinny być chronione tak samo poważnie jak sam sklep.

Jest też druga strona tej samej monety. Sprawny backup jest częścią odpowiedzi na incydent bezpieczeństwa: to z zaufanej kopii sprzed ataku odtwarza się czysty sklep. Backup i bezpieczeństwo splatają się więc w jeden temat, a nie dwa osobne. Kopia chroni przed skutkami włamania, a jednocześnie musi być przed włamaniem zabezpieczona.

Praktyczny wniosek jest prosty: kopie szyfruje się i ogranicza do nich dostęp tak samo rygorystycznie jak do samego sklepu. Backup jest częścią systemu bezpieczeństwa, a nie schowkiem obok niego, i tak też trzeba go traktować przy każdym przeglądzie.

Backup jako część opieki

Backup to nie plik, tylko proces: regularne kopie wszystkich warstw sklepu, jedna w niezależnej lokalizacji, z alertem, gdy coś się nie wykona, i z cyklicznym testem odtworzenia. Taki proces wymaga nadzoru, dlatego w praktyce najlepiej działa jako część opieki, a nie jako opcja zaznaczona kiedyś w panelu i zapomniana. W dobrej umowie opieki powdrożeniowej backup jest opisany dwiema liczbami: jak często robimy kopie i jak szybko z nich wracamy.

Wartość dobrego backupu widać tylko raz, ale za to wtedy, gdy liczy się najbardziej: w dniu poważnej awarii. Sklep z przetestowaną strategią kopii wraca do sprzedaży w godzinę. Sklep bez niej odbudowuje się dniami albo traci dane bezpowrotnie. To najtańsze ubezpieczenie, jakie ma sklep, pod warunkiem że ktoś realnie go pilnuje. W Sellision Care kopie są robione, przechowywane osobno i testowane, żeby w dniu próby po prostu zadziałały.