Backup, którego nikt nie testował, to tylko nadzieja. Wyjaśniamy zasadę 3-2-1, pokazujemy jak robić kopie zapasowe plików i bazy danych (DirectAdmin, wtyczki WordPress, automatyzacja) i jak przetestować odtwarzanie, zanim będzie potrzebne naprawdę.
Strona internetowa może zniknąć na kilkanaście sposobów: nieudana aktualizacja wtyczki, włamanie i podmiana plików, ransomware, błąd wykonawcy, przypadkowe usunięcie katalogu, awaria dysku. Statystycznie nie pytamy „czy" coś takiego się wydarzy, tylko „kiedy". Jedyne, co wtedy dzieli firmę od katastrofy, to aktualna, sprawdzona kopia zapasowa.
Warto też wiedzieć: kopie wykonywane przez hosting są ważnym zabezpieczeniem, ale odpowiedzialność za dane strony spoczywa na jej właścicielu. Poważny biznes powinien mieć własny, niezależny backup - dokładnie tak samo, jak firma nie trzyma jedynej kopii umów u kontrahenta.
Wymyślona dziesiątki lat temu, wciąż aktualna:
Dlaczego to takie ważne? Kopia trzymana wyłącznie na tym samym serwerze co strona ginie razem z nim - przy awarii dysku, włamaniu (atakujący kasuje też backupy!) czy blokadzie konta. Trzecia kopia „gdzie indziej" to polisa na scenariusze, w których zawodzi wszystko naraz.
Klasyczny błąd: backup samych plików bez bazy danych. Po odtworzeniu strona „jest", ale bez treści i zamówień. Pliki i baza muszą być kopiowane razem i z tego samego momentu - inaczej po odtworzeniu treści nie będą pasować do plików.
Panel DirectAdmin ma wbudowany mechanizm pełnej kopii konta:
Odtwarzanie działa w drugą stronę: wgrywasz archiwum do katalogu backups i wybierasz Przywróć. Instrukcje krok po kroku znajdziesz w naszym centrum pomocy: import i eksport bazy danych.
Dla WordPressa najprostszą drogą do zautomatyzowanych, kompletnych kopii są wtyczki:
Rozsądny harmonogram dla typowej strony firmowej: baza danych codziennie, pliki raz w tygodniu, wysyłka do zewnętrznej chmury, retencja 2-4 tygodnie. Sklep internetowy z zamówieniami: baza nawet co kilka godzin. I zasada niepodlegająca negocjacjom: ręczna kopia przed każdą aktualizacją wtyczek, motywu czy samego WordPressa.
Jeśli sprawnie poruszasz się w terminalu, dwie komendy załatwiają sprawę:
Obie możesz wpiąć w harmonogram cron (w DirectAdmin: Funkcje zaawansowane → Zadania cron) i dorzucić wysyłkę do zewnętrznego magazynu (rclone obsługuje praktycznie każdą chmurę). Podstawy pracy z terminalem: jak połączyć się przez SSH.
Najboleśniejsza lekcja z praktyki: firmy odkrywają, że ich backup jest uszkodzony, niekompletny albo za stary dopiero w dniu awarii. Dlatego raz na kwartał zrób próbę odtworzenia:
Jedna najnowsza kopia nie wystarczy - włamanie czy uszkodzenie danych bywa zauważane po tygodniach, a wtedy „najnowsza kopia" zawiera już zainfekowane pliki. Sprawdzony schemat: 7 kopii dziennych + 4 tygodniowe + 3 miesięczne. Zajmuje rozsądnie mało miejsca (kopie przyrostowe), a daje możliwość cofnięcia się o kwartał.
Robi - w McProdukt konta hostingowe są objęte regularnymi kopiami po stronie serwera, przechowywanymi niezależnie od serwera produkcyjnego. Traktuj je jednak jako siatkę bezpieczeństwa, a nie jedyny backup: własna kopia w Twojej chmurze daje pełną kontrolę i spełnia zasadę 3-2-1.
Tak często, jak często zmieniają się dane: blog aktualizowany raz w tygodniu - kopia raz dziennie w zupełności wystarczy; sklep z zamówieniami - baza co 1-6 godzin. Pomocnicze pytanie: „ile godzin pracy/zamówień mogę stracić bezboleśnie?"
Minimum: poza serwerem produkcyjnym (Dysk Google, Dropbox, S3, dysk lokalny). Idealnie: dwie niezależne lokalizacje, z czego jedna z ograniczonym dostępem do kasowania (ochrona przed ransomware).
Dobry backup spełnia trzy warunki: jest automatyczny (ludzie zapominają), trzymany poza serwerem (awarie nie wybierają) i przetestowany (nieodtwarzalna kopia nie istnieje). Skonfiguruj go według tego przewodnika w jeden wieczór - a jeśli potrzebujesz pomocy w doborze strategii dla swojej strony lub sklepu, odezwij się do nas, doradzimy konkretnie pod Twój przypadek.
Wszystkie poradniki z kategorii: Hosting od podstaw