Kopia aplikacji to zadanie usługi SSJob wykonujące kopię plików leżących na dysku serwera aplikacyjnego - kodu, konfiguracji i wygenerowanych dokumentów - niezależnie od kopii bazy MSSQL. Konfiguruje się je dokładnie tym samym mechanizmem, jednym wierszem w tabeli _jobs, ale bez rozróżniania rodzaju kopii właściwego dla zadań stricte bazodanowych.
Czym jest kopia aplikacji
Baza danych, opisana przy okazji zadania kopii bazy MSSQL, to tylko jedna część danych, od których zależy działanie platformy. Druga część - równie istotna, choć łatwiej pomijana przy planowaniu backupu - to pliki leżące bezpośrednio na dysku serwera aplikacyjnego, poza silnikiem SQL Server. Zadanie kopii aplikacji odpowiada właśnie za pełne zabezpieczenie tej drugiej, równie istotnej części danych.
To pominięcie nie jest przypadkowe - kopia bazy danych jest tematem znacznie częściej poruszanym w dokumentacji i szkoleniach administratorów baz danych, podczas gdy pliki aplikacji bywają traktowane jako coś, co „i tak jest w repozytorium kodu” albo „da się zainstalować od nowa”. W praktyce, przy wdrożeniu dostosowanym do konkretnego klienta, odtworzenie samej instalacji od zera rzadko wystarcza - brakuje w niej lokalnych modyfikacji konfiguracji i danych zgromadzonych już podczas eksploatacji.
Mechanicznie jest to zadanie takie samo jak pozostałe zadania usługi SSJob - wiersz w tabeli _jobs, uruchamiany cyklicznie w tle. Różnica leży wyłącznie w tym, co dokładnie jest kopiowane i jakie pola konfiguracyjne mają tu znaczenie.
Co obejmuje kopia aplikacji
Do plików aplikacji, które nie są częścią bazy danych, a mimo to są krytyczne dla działania systemu, należą przede wszystkim:
- Plik web.config - konfiguracja aplikacji ASP.NET, zawierająca między innymi łańcuchy połączeniowe do bazy danych i ustawienia specyficzne dla danego środowiska.
- Foldery App_Pdf, App_Xls, App_Zal - miejsca, w których zapisywane są wygenerowane wcześniej wydruki i załączniki, opisane szerzej przy okazji transakcji wydruk_refno.aspx.
- Ewentualne modyfikacje kodu - zmiany wprowadzone na potrzeby konkretnego wdrożenia, wykraczające poza standardową instalację platformy.
- Pliki statyczne i zasoby - obrazy, style i inne elementy interfejsu przechowywane bezpośrednio na serwerze.
Utrata tej warstwy danych - nawet przy zachowanej, aktualnej kopii samej bazy - oznaczałaby konieczność żmudnego, ręcznego odtwarzania konfiguracji środowiska i ponownego wgrywania wcześniej wygenerowanych dokumentów, których w bazie danych po prostu nigdy nie było.
Konfiguracja bez dodatkowego oprogramowania
Zadanie kopii aplikacji, podobnie jak pozostałe zadania SSJob, nie wymaga instalowania osobnego, dodatkowego narzędzia do backupu plików.
Konfiguracja w tabeli _jobs
Zadanie kopii aplikacji korzysta z tego samego zestawu pól co pozostałe zadania SSJob, z jednym istotnym pominięciem:
| Pole | Znaczenie |
|---|---|
| OSTATNIOWYKONANO | Data ostatniego poprawnego wykonania zadania |
| CYKLICZNOSC | Liczbowy interwał, co jaki zadanie jest uruchamiane |
| CYKLICZNOSCTYPE | Jednostka interwału - np. godziny, dni |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy do bazy przechowującej konfigurację zadania |
| FOLDERKOPII | Folder, w którym zapisywana jest wykonana kopia aplikacji |
W odróżnieniu od kopii bazy MSSQL, tutaj nie występuje pole RODZAJKOPII - kopiowanie plików aplikacji to zwykłe skopiowanie zawartości folderu, bez rozróżnienia na kopię pełną, przyrostową czy plik LOG, właściwego dla mechanizmu transakcyjnego bazy danych.
Harmonogram i częstotliwość
Częstotliwość ustala się tak samo jak w pozostałych zadaniach - parą pól CYKLICZNOSC i CYKLICZNOSCTYPE. W praktyce pliki aplikacji zmieniają się rzadziej niż dane w bazie - konfiguracja środowiska czy kod modyfikowany są sporadycznie, a nie przy każdej transakcji użytkownika - dlatego kopię aplikacji często konfiguruje się z dłuższym interwałem niż kopię bazy danych, na przykład raz na dobę zamiast co kilka godzin.
Wyjątkiem są foldery z wygenerowanymi dokumentami, takie jak App_Pdf czy App_Zal, których zawartość rośnie na bieżąco wraz z pracą użytkowników. Tam, gdzie utrata nawet jednego dnia wygenerowanych załączników byłaby dotkliwa, warto rozważyć wyraźnie częstszy interwał niż ten ustawiony dla samej konfiguracji aplikacji.
W praktyce spotyka się też podejście pośrednie - dwa osobne zadania kopii aplikacji zamiast jednego, z różnymi interwałami dla różnych podfolderów. Jedno zadanie kopiuje rzadko zmieniającą się konfigurację i kod, drugie - znacznie częściej rosnące foldery z wygenerowanymi dokumentami. Taki podział wymaga dodania dwóch osobnych wierszy w tabeli _jobs, każdego wskazującego inny folder źródłowy, ale pozwala precyzyjniej dopasować częstotliwość kopiowania do rzeczywistego tempa zmian w danych.
Powiadomienia i diagnostyka
Tak jak przy kopii bazy danych, pole MAILPOWIADOMIENIE pozwala ustawić adresy e-mail otrzymujące potwierdzenie wykonania zadania, a pole OSTATNIOWYKONANO w tabeli _jobs pozwala w każdej chwili sprawdzić, kiedy kopia była ostatnio wykonana poprawnie. Dodatkowym źródłem informacji o działaniu samej usługi pozostaje Dziennik zdarzeń Windows, opisany przy okazji instalacji usługi SSJob.
Folder docelowy kopii
Pole FOLDERKOPII wskazuje lokalizację zapisu wykonanej kopii aplikacji. Podobnie jak w przypadku bazy danych, dobrą praktyką jest wskazanie folderu na innym dysku fizycznym niż ten, na którym działa sama aplikacja - w przeciwnym razie awaria dysku aplikacyjnego zniszczyłaby jednocześnie oryginał i jego kopię, pozostawiając firmę bez jakiegokolwiek punktu odniesienia do odtworzenia środowiska.
Zasób sieciowy sprawdza się tu szczególnie dobrze, ponieważ pozwala też łatwo udostępnić kopię innej osobie zaangażowanej w proces odzyskiwania po awarii - na przykład zewnętrznemu integratorowi wspierającemu wdrożenie - bez konieczności fizycznego dostępu do serwera, na którym doszło do awarii.
Warto też rozważyć, czy kopia aplikacji i kopia bazy danych powinny trafiać do tego samego folderu docelowego, czy do osobnych lokalizacji. Rozdzielenie ułatwia porządkowanie i różnicowanie zasad retencji - pliki konfiguracyjne zmieniają się rzadko i mogą być przechowywane dłużej, podczas gdy częste kopie bazy danych szybciej zapełniają dostępne miejsce na dysku.
Warto też uwzględnić rozmiar samych folderów danych. Kartoteka towarowa i pozostałe dane referencyjne, opisane w materiale o dokumentach magazynowych, rosną powoli, ale foldery z wygenerowanymi wydrukami mogą z czasem osiągnąć rozmiar liczony w gigabajtach - warto to uwzględnić przy szacowaniu miejsca potrzebnego na kopię docelową.
Kopia aplikacji razem z kopią bazy
Pełne odzyskiwanie systemu po awarii wymaga obu elementów naraz - kopii bazy danych i kopii plików aplikacji. Sama baza danych, odtworzona na nowym serwerze bez odpowiadającej jej konfiguracji aplikacji, nie uruchomi w ogóle całej platformy - brakujący plik web.config z poprawnym łańcuchem połączeniowym całkowicie uniemożliwi połączenie z odtworzoną wcześniej bazą.
Z tego powodu oba zadania - opisane tutaj oraz w materiale o kopii bazy MSSQL - warto traktować jako komplet, a nie dwie niezależne, opcjonalne czynności. Test procedury odzyskiwania po awarii, jeśli w ogóle jest przeprowadzany, powinien obejmować odtworzenie obu elementów jednocześnie, a nie tylko bazy danych w izolacji.
Praktyczny test warto przeprowadzić na oddzielnym, testowym serwerze - odtworzyć tam obie kopie i sprawdzić, czy platforma faktycznie się uruchamia i pozwala zalogować się do modułu administratora. Dopiero taki pełny test, obejmujący zarówno bazę, jak i pliki aplikacji, daje realną pewność, że procedura odzyskiwania zadziała również w prawdziwej sytuacji awaryjnej, a nie tylko w teorii opisanej w dokumentacji.
Podsumowanie
Kopia aplikacji to zadanie SSJob zabezpieczające warstwę danych leżącą poza silnikiem SQL Server - konfigurację środowiska, ewentualne modyfikacje kodu oraz wygenerowane wcześniej dokumenty w folderach App_Pdf, App_Xls i App_Zal. Konfiguruje się je tym samym mechanizmem co pozostałe zadania, jednym wierszem w tabeli _jobs, bez rozróżniania rodzaju kopii.
Razem z kopią bazy MSSQL tworzy komplet niezbędny do pełnego odzyskania systemu po awarii - żadne z tych dwóch zadań samodzielnie nie wystarcza do przywrócenia w pełni działającej platformy dla użytkowników.
Regularne, choćby okazjonalne testowanie tego kompletu na osobnym środowisku pozwala odkryć luki w procedurze zanim staną się problemem podczas rzeczywistej awarii, kiedy czas na reakcję i tak jest już mocno ograniczony presją przywrócenia pracy firmy.