Sama informacja, że kopia się zrobiła, nie wystarcza. W G2E mówimy o tym, co odtwarza się jako pierwsze, kto naciska guzik, jak długo to trwa i czy ostatnio ktoś to przetestował. Bez tego backup to plik na dysku, nie plan ciągłości.
Raz dziennie, raz w tygodniu, „chyba codziennie"? Częstotliwość kopii definiuje RPO — maksymalną stratę danych w razie awarii.
Jedna kopia czy 7? Jeśli zmiana popsuła dane tydzień temu, a backup ma 3 dni retencji — wracać już nie ma do czego.
Backup, którego nikt nie odtworzył, jest hipotezą. Test restore raz na kwartał potrafi wykryć problemy, zanim wykryje je awaria.
Migawka VM podczas transakcji bazodanowej bez snapshot-aware backupu może odtworzyć bazę „w trakcie". Sprawdzamy, czy aplikacja po restore wstanie.
Pożar, zalanie, ransomware w klastrze — backup leżący obok produkcji znika razem z nią. Druga lokalizacja zmienia poziom ryzyka.
Wszyscy = nikt. W chwili awarii ktoś musi mieć decyzję: co odtwarzamy, w jakiej kolejności, kogo informujemy. Bez tego restore się rozjeżdża.
Okno startu kopii nakłada się na otwarcie księgowości albo szczyt fakturowania. Backup wpływa na produkcję, więc administrator skraca jego zakres.
Kopia powstaje, raporty pokazują „OK", ale nikt nigdy nie odtworzył jej do działającej aplikacji. Pierwszy test odbywa się na produkcji w dniu awarii.
Backup leży na tym samym serwerze, w tej samej szafie, w tej samej serwerowni. Pożar, zalanie albo ransomware niszczy oryginał razem z jedyną kopią.
„Backupem zajmuje się chłopak od ERP" / „pewnie robi to dostawca hostingu" / „zewnętrzna firma to ogarnia". W dniu awarii każdy wskazuje na drugiego.
Zamiast trzyliterowych skrótów rzucanych w ofertach, pokazujemy co to konkretnie znaczy dla Twojej firmy. To dwie różne decyzje, każda z własną ceną i sensem.
RPO = odstęp czasu między ostatnią kopią a momentem awarii. Backup co 24 h oznacza RPO do 24 h. Krótsze RPO (np. kopia co 4 h dla bazy) wymaga osobnego scenariusza.
RTO = czas od momentu awarii do momentu, gdy aplikacja jest znów dostępna dla użytkowników. Restore VM z backupu, restore bazy, smoke-testy, przepięcie ruchu — każde z nich dodaje minuty.
ERP, baza, kontroler domeny, pliki działu sprzedaży? Bez kolejności na piśmie restore odbywa się ad-hoc. Z kolejnością — zostaje miejsce na decyzje strategiczne, nie operacyjne.
Kto autoryzuje uruchomienie kopii? Właściciel, IT manager, partner ERP, NSIX? W dniu awarii nie ma czasu na ustalanie tego od zera.
Najnowsza? Sprzed awarii? Sprzed wdrożenia, które zepsuło dane? Reguły wyboru wersji są łatwiejsze, gdy ułoży się je przed awarią, nie w jej trakcie.
Restore zakończony sukcesem to coś więcej niż „VM wstała". Lista testów poprodukcyjnych (logowanie, kluczowy raport, integracje, e-faktura) odpowiada, czy firma może wrócić do pracy.
Zarząd, użytkownicy, partner ERP, klienci, urząd skarbowy w przypadku e-faktur. Komunikat na każdy z tych kierunków łatwiej napisać dziś niż w trakcie awarii.
Opisz krótko swoje środowisko: co działa, gdzie dziś trafiają kopie i co firma musi odtworzyć jako pierwsze. Wracamy z listą pytań i wstępnym kierunkiem.