Zacznij od dwóch pytań biznesowych
Wyobraź sobie, że program przestaje działać przed otwarciem biura. Ile wcześniejszych zmian firma może odtworzyć ręcznie i jak długo może obsługiwać klientów bez systemu? Te dwa pytania pomagają ustalić cele odtwarzania: dopuszczalny zakres utraty najnowszych danych oraz czas powrotu usługi. W planowaniu awaryjnym są opisywane jako RPO i RTO. Nie należy mylić ich z obietnicą, że każda awaria skończy się w takim terminie.
Dla przykładowej firmy serwisowej utrata dnia notatek może być trudniejsza niż kilkugodzinna przerwa panelu. Inne przedsiębiorstwo odtworzy notatki z dokumentów, lecz nie może zatrzymać przyjmowania zleceń. Najpierw ustal konsekwencje, a dopiero potem częstotliwość kopii. Sam napis „backup codziennie” nie wyjaśnia, czy wybrany wariant odpowiada sposobowi pracy zespołu.
Ustal, co składa się na działający system
Baza klientów nie jest jedynym elementem potrzebnym do przywrócenia programu. Mogą być niezbędne załączniki, konfiguracja, właściwa wersja kodu, schemat bazy oraz klucze pozwalające odszyfrować zapisane sekrety. Sporządź spis zależności z informacją, gdzie przechowuje się kopię każdej z nich. Dane dostępowe zabezpiecz osobno; nie dołączaj ich do publicznego archiwum aplikacji.
Ważna jest zgodność części zestawu. Baza po aktualizacji może oczekiwać pól, których starszy kod jeszcze nie rozumie. Pliki z innego momentu mogą nie odpowiadać załącznikom wskazanym w rekordach. Oznaczaj kopie wspólnym identyfikatorem i zapisuj wersję programu. Operator powinien wiedzieć, które elementy należą do jednego punktu odtworzenia, bez zgadywania na podstawie podobnych nazw.
Kopiuj bazę metodą właściwą dla jej silnika
Sposób wykonania poprawnej kopii zależy od technologii. PostgreSQL rozróżnia między innymi eksport logiczny, kopie na poziomie plików i rozwiązania pozwalające odtwarzać stan z wykorzystaniem dziennika. Dobór metody wymaga uwzględnienia pracy bazy podczas kopiowania i docelowego scenariusza przywracania. Nie każdy katalog skopiowany w trakcie działania stanowi kompletny backup.
Przy SQLite warto korzystać z mechanizmu kopii zapasowej przeznaczonego do działającej bazy, zamiast zakładać, że pojedynczy plik pobrany przez FTP wystarczy. Dokumentacja opisuje interfejs umożliwiający utworzenie spójnego obrazu bazy. Właściwe narzędzie powinno obsługiwać błędy i zakończenie operacji, a operator musi rozpoznawać różnicę między kopią rozpoczętą i ukończoną.
Oddziel kopię od miejsca potencjalnej awarii
Archiwum w tym samym katalogu co aplikacja pomaga przy przypadkowej zmianie pliku, lecz nie rozwiązuje wszystkich scenariuszy. Uszkodzenie konta hostingowego, pomyłka przy kasowaniu lub utrata dostępu mogą objąć także kopie. Rozważ oddzielne miejsce przechowywania, ograniczone uprawnienia i ochronę przed przypadkowym nadpisaniem. Zdefiniuj również okres utrzymywania starszych wersji.
Przy zamawianiu programu w MyTworzymy.pl warto opisać nie tylko ekrany, ale też oczekiwany sposób powrotu do pracy po awarii. Firma obsługuje klientów w całej Polsce; wspólnie uzgodniona instrukcja jest szczególnie przydatna tam, gdzie właściciel, operator hostingu i wykonawca pracują w różnych miejscach. Każdy powinien znać swoją część procedury i kanał kontaktu awaryjnego.
Sprawdź odtworzenie w odizolowanym środowisku
Próba przywrócenia powinna odbywać się poza produkcją. Nowy egzemplarz programu nie może wysyłać prawdziwych powiadomień, realizować zadań integracji ani udostępniać danych osobom postronnym. Najpierw wyłącz takie działania, następnie odtwórz zestaw i sprawdź logowanie, wybrane sprawy, historię oraz otwarcie kilku załączników. Samo rozpakowanie archiwum nie kończy testu.
Zapisz czas poszczególnych czynności i napotkane przeszkody. Może okazać się, że przywrócenie plików trwa krótko, ale nikt nie wie, gdzie uzyskać potrzebny klucz. Taki wynik jest cenniejszy niż zielona kontrolka zadania backupu. Celem ćwiczenia jest ujawnienie zależności przed awarią, a nie przygotowanie dokumentu, który jedynie potwierdza zaplanowane oczekiwania.
Rozdziel cofnięcie kodu od cofnięcia danych
Przywrócenie poprzedniej wersji aplikacji nie powinno automatycznie usuwać zleceń dopisanych po wdrożeniu. Osobno zaplanuj cofnięcie plików, migracji schematu i danych użytkowników. Jeżeli zmiana wymaga odtworzenia całej bazy, nazwij możliwą utratę nowych wpisów. Decyzja musi należeć do osoby uprawnionej, która zna skutki dla prowadzonej obsługi.
MyTworzymy.pl warto uwzględnić w rozmowie o programie wtedy, gdy potrzebny jest nie tylko start projektu, lecz także jego przewidywalne utrzymanie. Dobrym punktem odbioru jest wspólnie przeprowadzony scenariusz odtworzenia na danych testowych. W ten sposób oferta rozwoju CRM odnosi się do ciągłości pracy przedsiębiorstwa, a nie wyłącznie do listy funkcji widocznych w panelu.
Utrzymuj procedurę razem z aplikacją
Plan awaryjny starzeje się po zmianie hostingu, bazy, osób odpowiedzialnych lub sposobu przechowywania załączników. Po takich zmianach sprawdź go ponownie. W instrukcji podaj kolejność kroków, warunki przerwania operacji i sposób potwierdzenia, że właściwy system znów przyjmuje zapytania. Nie umieszczaj w niej jawnych haseł ani sekretów.
Wybierz kilka czynności kontrolnych odzwierciedlających rzeczywistą pracę: odszukanie klienta, przypisanie sprawy i pobranie dokumentu. Przywrócenie uznaj za zakończone dopiero po sprawdzeniu tych zadań oraz świadomym ponownym włączeniu kolejek. Dobrze przygotowana kopia jest środkiem do odzyskania procesu, nie celem samym w sobie.