Kopia bazy jest. A czy klient otworzy swój dokument?
Co znaczy, że portal „już działa”? W rozmowie o kopiach warto rozwinąć te dwa słowa, zanim każdy dopowie sobie coś innego. Pokażemy, jak zamienić je w próbę, do której można później wrócić.
Spis treści
Załóżmy, że wykonawca pokazuje wspólniczce raport z kontrolowanej próby: kopia bazy portalu powstała bez błędów. Odtwarza przygotowany wcześniej fikcyjny zestaw. Widać listę spraw, ale załącznik się nie otwiera. W tej zmyślonej scenie nie wiadomo jeszcze, co zawiodło. Wiadomo, że zadania klienta nie da się zakończyć.
Lista spraw może znajdować się w bazie, a załączniki w innym miejscu. Do działania potrzebne są również właściwa wersja aplikacji, ustawienia i dostęp do usług zewnętrznych. Dlatego pytanie do wykonawcy powinno brzmieć: co potrafimy odtworzyć razem i jak sprawdzimy wynik? Sam komunikat o wykonaniu kopii nie odpowiada na to pytanie.
Co musi wrócić razem
Poproś opiekuna aplikacji o krótki spis jej elementów. Baza może przechowywać sprawy, użytkowników i powiązania dokumentów. Pliki mogą leżeć poza bazą. Potrzebna jest wersja kodu, która z odzyskanymi danymi potrafi pracować, oraz konfiguracja pozwalająca ją uruchomić. Zgodność wersji bazy i aplikacji sprawdza wykonawca. Przy danych zaszyfrowanych trzeba także ustalić dostęp do potrzebnych kluczy. Nie wpisuj ich do ogólnego protokołu.
Sama nazwa narzędzia do kopii nie rozstrzyga zakresu. Na przykład dokumentacja PostgreSQL wskazuje, że eksport pg_dump obejmuje jedną bazę, a wspólne role serwera wymagają osobnego uwzględnienia. Nie dobieramy tu metody kopii. Ten przykład pokazuje, dlaczego plik z bazą nie jest automatycznie kompletem potrzebnym do przywrócenia aplikacji.
Spis powinien obejmować też domenę, logowanie, pocztę, integracje i inne potrzebne usługi. Nie każdą trzeba odzyskiwać z własnej kopii. Ustalcie, jak przywrócony portal ponownie z nich skorzysta i kto wyjaśni problem. Kopia aplikacji nie przywróci usługi zewnętrznego dostawcy.
W naszej scenie opiekun sprawdza więc także miejsce załączników i to, czy ich wersje pasują do odzyskanych wpisów. Baza cofnięta do wcześniejszego momentu i pliki z innego momentu mogą nie tworzyć poprawnego zestawu. Ocenia to wykonawca, który zna sposób zapisu danych w portalu.
Ustal, jakiej przerwy i utraty danych nie zaakceptujesz
Przed wyborem rozwiązania opisz ważną czynność: klient ma zalogować się, odczytać wskazany dokument i przekazać odpowiedź. Jak długo można pracować bez portalu? Ile najnowszej pracy można utracić i czy da się ją odtworzyć z innego źródła? To dwa różne ustalenia.
Oddziel cele kancelarii od wyniku pomiaru i parametrów przyjętych przez dostawcę. Porównaj wymagania z możliwościami, kosztem i rzeczywistą próbą. Samo zapisanie oczekiwań nie potwierdza, że da się je spełnić.
Jeśli ostatni odzyskany stan pochodzi z nocy, poranne zgłoszenia nie pojawią się w nim tylko dlatego, że aplikacja już działa. W planie trzeba ustalić, jak zachować nowsze wiadomości i pliki oraz kto rozstrzygnie ich ponowne wprowadzenie. Nie należy automatycznie nadpisywać działających danych starszą kopią.
Trzy role, niekoniecznie trzy firmy
Zapisz przy każdej części konkretnego wykonawcę i osobę odbierającą wynik. Poniższa mapa jest naszą propozycją do uzupełnienia, nie podziałem obowiązującym u każdego dostawcy.
| Rola | Co trzeba przypisać i potwierdzić |
|---|---|
| Kancelaria | [Osoba] określa ważny proces, akceptowalną przerwę i utratę pracy. Wskazuje uprawnionych odbiorców i zatwierdza decyzję o powrocie do działania. |
| Opiekun aplikacji | [Osoba] opisuje bazę, pliki, kod, konfigurację i zależności. Prowadzi uzgodnione odtworzenie oraz sprawdzenie procesu i dostępów. Dowód: [opis i zapis próby]. |
| Operator infrastruktury | [Osoba lub usługa] udostępnia uzgodnione zasoby i mechanizmy odzyskania. Zakres kopii oraz możliwości odtworzenia potwierdza [odpowiedzialny]. Dowód: [ustalenie zakresu i wynik]. |
Jedna firma może pełnić dwie role. Sam operator serwera nie musi znać znaczenia dokumentów w portalu. Kancelaria nie powinna natomiast samodzielnie dobierać kolejności odtwarzania baz i usług. Ustal także, kto prowadzi zgłoszenie do końca, kto go zastępuje i w jakich godzinach jest dostępny. Monitoring bez takiego przypisania nie odpowie na telefon za człowieka.
Próba, która dochodzi do dokumentu
Nie wyłączaj portalu klientom, żeby sprawdzić, czy kopia działa. Uzgodnij z wykonawcą odrębne, chronione miejsce próby, dostęp osób oraz sposób postępowania z danymi. Microsoft zaleca najpierw testy poza produkcją. Wykonawca ma zabezpieczyć próbę przed wysyłką wiadomości do klientów, powtarzaniem płatności, zadaniami automatycznymi i zapisem do działających systemów.
Na początek przygotujcie kontrolowany zestaw: dwie fikcyjne osoby, ich sprawy i oznaczone załączniki. Użyjcie wyłącznie adresów testowych pod Waszą kontrolą. Przed kopią dodajcie załącznik oznaczony „wersja 1”, po kopii podmieńcie go w miejscu pobierania danych do kopii na „wersję 2”. Po odtworzeniu ma wrócić pierwsza. Wykonawca wskazuje miejsce przechowywania zestawu, ustawienia kopii odpowiadające produkcji i różnice. Ta próba nie potwierdza jeszcze kompletności wszystkich rzeczywistych kopii.
Przy istniejących kopiach wykonawca sprawdza odzyskanie uzgodnionej bazy i plików oraz techniczną możliwość ich odczytu. Osoba z kancelarii uprawniona do tych akt ocenia, czy to właściwe dokumenty we właściwych sprawach i wersjach. Zakres i odbiorców uzgodnijcie z odpowiednią ochroną danych. Nie logujcie się jako rzeczywisty klient. Ustalcie też los danych i dostępów po zakończeniu próby.
Po odzyskaniu zestawu wykonajcie z opiekunem aplikacji cały uzgodniony proces. Oba zwykłe konta klientów mają otworzyć własne dokumenty i wykonać wskazaną czynność. Pracownik kancelarii sprawdza, czy testowa odpowiedź klienta pojawiła się przy właściwej sprawie. Dopiero wtedy sprawdźcie, czy jedno nie otworzy załącznika drugiego przez bezpośredni link ani bez logowania. Wykonawca potwierdza źródło odczytu w ustawieniach lub zapisie działania. Sam znacznik pomaga sprawdzić stan danych, ale nie zastępuje dowodu, że portal nie korzysta z produkcji objętej scenariuszem awarii. Szerszą kontrolę granic opisaliśmy w poradniku o uprawnieniach aplikacji i AI.
Nasz protokół próby do skopiowania:
- Zakres i warunki: [scenariusz awarii, zestaw fikcyjny czy istniejące kopie, elementy i wersja aplikacji, miejsce]. Zablokowane skutki: [wiadomości, płatności, zadania automatyczne, integracje]. Prowadzi: [kto].
- Odzyskany stan: [z jakiego momentu baza i pliki, co potwierdza ich dopasowanie]. Źródło odczytu plików i dowód: [ustawienia lub zapis]. Nowsza praca do zachowania: [co i kto].
- Czas: [początek zgłoszenia, rozpoczęcie odtwarzania, gotowość uzgodnionego procesu]. Co pominięto w tym pomiarze: [np. oczekiwanie na dostawcę].
- Wynik procesu: [logowanie, własne załączniki, odpowiedź klienta widoczna kancelarii]. Cudzy plik: [link bezpośredni, bez logowania], odmowa potwierdzona tylko przy działających własnych plikach. Dowody: [zapis]. Odbiera: [osoba].
- Otwarte pozycje: [usterka albo nie sprawdzono, właściciel, termin i zakres ponownej próby]. Decyzja o dalszej pracy: [kto i jaka].
Wpis dla zmyślonej próby z początku tekstu mógłby brzmieć tak:
Scenariusz: utrata bazy i plików, zestaw fikcyjny. Aplikacja [wersja], kopia [data]. Baza odtworzona; moment i źródło plików niepotwierdzone. Konta widzą swoje sprawy, ale załączniki się nie otwierają. Granicy cudzych plików nie zaliczono, bo własne też nie działają. Gotowości procesu nie osiągnięto. Wykonawca [osoba] ustala przyczynę do [termin]. Po poprawce powtarzamy całą próbę od nowej kopii: dwie wersje załącznika, odtworzenie, oba konta i odmowę dla cudzych plików. Istniejące kopie produkcyjne: nie sprawdzono. Odbiera [osoba].
CERT Polska odróżnia weryfikację kopii od testów odtworzeniowych, obejmujących procedurę i czas. W naszym protokole wynik dotyczy opisanych warunków. Próba bez oczekiwania na nowe środowisko nie dowodzi, że po utracie całego hostingu portal wróci równie szybko. Brak sprawdzenia oznacza „nie sprawdzono”, nie zaliczenie.
Co zostaje po próbie
Zachowajcie wynik, opis odtwarzania i kontakty również poza głównym środowiskiem. Jeśli scenariusz obejmuje utratę konta albo hostingu, sprawdźcie, czy kopie i klucze nie znikają razem z nim. Uzgodnijcie chroniony sposób dostępu do nich podczas awarii. Po zmianie zapisu załączników, logowania lub infrastruktury wróćcie do scenariusza i prób.
W LegalByte hosting i utrzymanie LegalCloud obejmują uzgodnienie środowiska, dostępów, kopii i odtwarzania. Koszt infrastruktury i koszt obsługi pokazujemy osobno. Parametry odzyskania i godziny reakcji zależą od zakresu oraz budżetu. Rozwój kodu, licencje, usługi zewnętrzne i duże migracje mają osobne zakresy. Hosting nie jest automatycznie częścią abonamentu helpdesku.
Możesz zacząć od oceny jednego scenariusza w obecnym środowisku. Nie każda luka wymaga przeniesienia aplikacji. Jeżeli potrzebujesz odzyskania pliku użytkownika, zamiast całej usługi, zacznij od poradnika o kopii dokumentów w OneDrive. Szerszy budżet własnego systemu opisujemy w tekście o koszcie aplikacji kancelarii.
Wspólniczka z naszej sceny wraca do załącznika. Raport o kopii nadal się przyda, ale teraz obok niego leży zapis, co klient może zrobić i co jeszcze czeka na sprawdzenie.
Źródła i dalsza lektura
Materiały sprawdzone 8 listopada 2026 r. Scena, mapa i protokół są naszymi propozycjami, nie wynikami wdrożenia. Dokumentacja Microsoftu dotyczy jego ram architektury, a przykład PostgreSQL pokazuje granicę eksportu bazy, nie dobór metody kopii dla Twojego systemu.
- Microsoft: Architecture strategies for disaster recovery. Cała usługa i jej komponenty, cele odzyskania, role i granice próby.
- PostgreSQL: pg_dump. Eksport jednej bazy i odrębność globalnych obiektów.
- CERT Polska: kopie zapasowe. Weryfikacja kopii oraz test procedury i czasu odtworzenia.
Omówmy jeden scenariusz odtworzenia
Opisz aplikację, obecny hosting i czynność, która musi wrócić po awarii. Nie przesyłaj kopii bazy, haseł ani dokumentów klientów. Poznaj zakres hostingu i utrzymania albo napisz do nas. Zakres oceny i koszt ustalimy przed rozpoczęciem prac.