Kopie zapasowe aplikacji dla firmy — co, gdzie, jak często i jak sprawdzić, że da się odtworzyć?

Model zagrożeń: co realnie kasuje dane aplikacji?

Siedem scenariuszy w tabeli niżej. Ani jeden nie jest włamaniem — to pomyłka operatora, migracja, koniec planu u dostawcy albo plik, którego kopia bazy nigdy nie obejmowała.

Model zagrożeń dla kopii odpowiada na cztery pytania: kto albo co uderza, czym, co firma traci i który mechanizm to ratuje. Jeśli przy którymś wierszu nie umiesz wskazać mechanizmu, ten scenariusz kończy się utratą danych.

Mechanizm nie jest jeden dla całej aplikacji. Dokumentacja Supabase mówi wprost, że kopie bazy nie obejmują obiektów zapisanych przez interfejs magazynu plików, bo w bazie leżą wyłącznie dane o nich (odczyt 31.08.2026).

Trzy składniki kopii: baza, pliki i kod

Kopia aplikacji to trzy mechanizmy z trzema różnymi retencjami. Pytanie „czy robicie kopie” bez wskazania składnika ma tyle poprawnych odpowiedzi, ile jest składników — i każda z nich brzmi uspokajająco.

Baza. Dostawca robi ją automatycznie według planu: w Pro codzienne kopie sięgają 7 dni wstecz, w Team 14 dni, w Enterprise do 30 dni (dokumentacja Supabase, odczyt 31.08.2026).

W planie darmowym cennik przy automatycznych kopiach podaje, że nie wchodzą w plan, a dokumentacja zaleca własny zrzut bazy z wiersza poleceń i utrzymywanie kopii poza dostawcą. To jedyna kopia, jaką ma darmowy projekt.

Odtworzenie do wybranego momentu (PITR) jest u tego dostawcy płatnym dodatkiem: 100 USD miesięcznie za 7 dni okna, do wyboru 7, 14 albo 28 dni. Deklarowany punkt odtworzenia w najgorszym przypadku to dwie minuty. Włączenie dodatku wyłącza kopie dobowe.

Pliki użytkowników. Nie wchodzą do kopii bazy — po odtworzeniu zostają odnośniki do plików, których nie ma. Dokumentacja dodaje, że odtworzenie starszej kopii nie przywraca obiektów skasowanych po jej wykonaniu. Magazyn w cenniku: 1 GB w planie darmowym, 100 GB w Pro, potem 0,0213 USD za GB.

Kod i konfiguracja. Źródłem jest repozytorium, nie hosting. Domyślna retencja wdrożeń na Vercelu to 30 dni w planie Hobby dla każdego stanu wdrożenia, a w Pro i Enterprise rok dla produkcyjnych i 180 dni dla podglądowych (dokumentacja, odczyt 31.08.2026).

Są wyjątki: ostatnie dziesięć wdrożeń projektu i ostatnie dwadzieścia gotowych wdrożeń produkcyjnych zostaje niezależnie od terminu, a skasowane wdrożenie da się przywrócić przez 30 dni. To mechanizm cofnięcia zmiany, nie archiwum kodu.

U nas jedna baza to jedna kopia i jeden model uprawnień. Dlatego pierwsza wersja aplikacji nie jest rozbijana na kilka usług: przy trzech bazach odtworzenie oznacza trzy punkty w czasie, które trzeba do siebie dopasować ręcznie.

Zasady, których nie da się dołożyć po awarii

Pięć zasad. Każda kosztuje kilkanaście minut przy zakładaniu projektu, a po awarii żadnej nie da się zastosować wstecz — nie ma już czego odtwarzać.

1. Plan kopii obejmuje trzy składniki naraz. Baza, pliki i repozytorium z konfiguracją, każde z własną retencją i własnym miejscem.

   Błąd, który wyklucza: odpowiedź „dostawca robi kopie” traktowana jako cały plan.

   Koszt błędu: baza wraca, aplikacja rusza, a załączniki i zdjęcia klientów są odnośnikami donikąd.

2. Jedna kopia leży poza kontem dostawcy. Eksport bazy i plików na magazyn, do którego nie ma dostępu konto administrujące aplikacją.

   Błąd, który wyklucza: jedyna kopia w tym samym projekcie, który może zostać wstrzymany albo przejęty.

   Koszt błędu: konto staje się jednym punktem awarii dla aplikacji i dla kopii naraz. Dokumentacja Supabase sama zaleca darmowym projektom własny zrzut i kopie poza dostawcą, a kopie fizyczne nowszych wersji bazy nie są dostępne do pobrania.

3. Kopia przed każdą migracją bazy. Wykonana ręcznie tuż przed zmianą schematu, nie ta sprzed nocy.

   Błąd, który wyklucza: migracja na produkcji z założeniem, że kopia dobowa wystarczy.

   Koszt błędu: bez dodatku odtwarzającego do wybranego momentu cofasz się do kopii z poprzedniej doby, razem ze wszystkim, co klienci zdążyli w tym czasie wpisać.

4. Próba odtworzenia z zapisanym punktem i czasem. Kopie sprawdzamy odtworzeniem, nie istnieniem pliku; punkt odtworzenia i czas odtworzenia są zapisane, zanim będą potrzebne.

   Błąd, który wyklucza: zdanie „kopie robią się codziennie” podane jako dowód.

   Koszt błędu: o tym, że kopia jest niepełna albo że odtworzenie trwa pół dnia, dowiadujesz się w dniu, w którym jest jedyna.

5. Kopia ma termin, tak jak dane w aplikacji. Usunięcie danych obejmuje również kopie, z terminem wynikającym z retencji dostawcy.

   Błąd, który wyklucza: polityka usuwania danych opisująca wyłącznie bazę produkcyjną.

   Koszt błędu: żądanie wykonane w aplikacji i niewykonane w kopii. Terminy i mechanikę usuwania zbiera tekst o RODO wdrożonym w kodzie, a nie w regulaminie.

Punkt odtworzenia i czas odtworzenia — dwie liczby zamiast zapewnień

Słownik NIST, za publikacją SP 800-34 Rev. 1, definiuje je krótko. Punkt odtworzenia to moment w czasie, do którego dane muszą zostać odtworzone po awarii. Czas odtworzenia to łączny czas, przez jaki elementy systemu mogą pozostawać w fazie odtwarzania, zanim odbije się to na działaniu organizacji.

Pierwsza liczba wynika z planu u dostawcy. Kopia dobowa daje punkt odtworzenia liczony w dobach, a dodatek odtwarzający do wybranego momentu deklaruje w najgorszym przypadku dwie minuty (odczyt 31.08.2026).

Druga liczba nie wynika z żadnego cennika. Czas odtworzenia to wynik próby przeprowadzonej na konkretnej bazie, z konkretną liczbą tabel i plików. Dopóki nikt takiej próby nie przeprowadził, ta liczba po prostu nie istnieje.

Jak to sprawdzić samemu w 5 minut?

Pięć sprawdzeń bez programisty. Żadne nie rusza danych, a razem zajmują około pięciu minut — plus czas, którego wykonawca potrzebuje na punkt trzeci.

1. Zapytaj o datę ostatniej próby odtworzenia (30 sekund). Dobra odpowiedź ma trzy liczby: dzień próby, ile danych stracono i ile trwało odtworzenie. Odpowiedź o częstotliwości kopii mówi o pliku, nie o odtworzeniu.
2. Sprawdź plan dostawcy w jego cenniku (60 sekund). W planie darmowym automatyczne kopie są oznaczone jako spoza planu, a projekt bywa wstrzymywany po tygodniu niskiej aktywności. Plan płatny podaje, ile dni wstecz sięgają kopie dobowe.
3. Poproś o eksport i odbierz plik (90 sekund twojego czasu). Zrzut bazy i pliki z magazynu, przekazane tak, żeby leżały u ciebie. Kopia, której nigdy nie widziałeś, jest kopią wykonawcy, nie firmy.
4. Sprawdź, gdzie leży repozytorium (30 sekund). Ma być na koncie firmy u dostawcy repozytoriów, z dostępem dla więcej niż jednej osoby. Kod na jednym laptopie to nie repozytorium, tylko katalog.
5. Sprawdź, czy hosting ma jeszcze poprzednie wdrożenie (60 sekund). Lista wdrożeń pokazuje, do której wersji da się cofnąć jednym kliknięciem. Retencja jest ograniczona terminem planu, więc to nie zastępuje repozytorium.

Wynik negatywny to lista zadań, nie awantura z wykonawcą. Trzy pierwsze punkty poprawia się w jeden dzień, dopóki aplikacja nie ma jeszcze lat historii i tysięcy plików w magazynie.

Osobne pytanie, czy w ogóle da się dostać do cudzych danych, rozstrzyga pięć testów z tekstu o zasadach bezpieczeństwa od pierwszego dnia. Kopia chroni przed utratą, nie przed wyciekiem.

Czego nie ma w dokumentacji

Operator płatności trzyma własną historię transakcji, ale nie publikuje okresu przechowywania kopii ani eksportów. Dokumentacja Stripe opisuje usuwanie i redakcję danych — transakcji nie da się usunąć, można je zredagować dopiero po 90 dniach — a okresu przechowywania kopii nie znaleźliśmy w dokumentacji na dzień 31 sierpnia 2026.

Wniosek praktyczny jest jeden: historii płatności nie traktuj jak swojej kopii. Dane, które mają przetrwać zmianę operatora, leżą w twojej bazie i w twoim eksporcie.

Reszta wątków ma osobne miejsca. Podział aplikacji na warstwy opisuje tekst o warstwach aplikacji dla firmy, a to, co dzieje się z awariami i aktualizacjami po starcie — tekst o aplikacji po starcie.

Rachunek za bazę i magazyn w dłuższym oknie zbiera zestawienie kosztu aplikacji w trzy lata. Tutaj liczy się jedno: kopia bez próby odtworzenia jest wydatkiem, nie zabezpieczeniem.