MikroTik Backup to zadanie zabezpieczające konfigurację routerów MikroTik obsługujących infrastrukturę sieciową wdrożeń StudioSystem. W odróżnieniu od pozostałych zadań usługi SSJob, właściwy backup wykonuje skrypt uruchamiany bezpośrednio na urządzeniu w systemie RouterOS, a SSJob odpowiada jedynie za weryfikację i powiadomienia.
Czym jest MikroTik Backup
MikroTik Backup to zadanie zabezpieczające zupełnie inny element infrastruktury niż pozostałe materiały tej serii - nie bazę danych StudioSystem ani pliki aplikacji, opisane przy okazji kopii bazy MSSQL i kopii aplikacji, tylko konfigurację routerów MikroTik, na których często opiera się łączność sieciowa całego wdrożenia. Utrata konfiguracji takiego urządzenia, bez wcześniej wykonanej kopii, oznacza żmudne odtwarzanie ustawień sieciowych ręcznie, często pod presją czasu wynikającą z braku łączności.
Mechanizm ten różni się od pozostałych zadań SSJob tym, że sam proces tworzenia kopii nie dzieje się na serwerze aplikacyjnym StudioSystem, tylko bezpośrednio na routerze - w systemie operacyjnym RouterOS, wyposażonym we własny język skryptowy oraz harmonogram zadań.
Trzy rodzaje kopii konfiguracji
Pojedyncze uruchomienie skryptu backupu tworzy nie jeden, a trzy odrębne pliki, każdy zabezpieczający inny aspekt konfiguracji urządzenia:
| Plik | Zawartość |
|---|---|
| UMDB-*.umb | Kopia bazy danych User Manager, obsługującej użytkowników i profile dostępu |
| UMDB-*.backup | Pełna, binarna kopia systemu RouterOS, przywracalna bezpośrednio na urządzeniu |
| UMDB-*.rsc | Tekstowy eksport konfiguracji w postaci poleceń RouterOS możliwych do ponownego wykonania |
Każda nazwa pliku zawiera nazwę urządzenia (odczytaną poleceniem /system identity get name), datę w formacie RRRR-MM-DD oraz godzinę wykonania, dzięki czemu kolejne kopie tego samego routera nigdy się wzajemnie nie nadpisują, a administrator od razu widzi, z którego dokładnie momentu pochodzi dany plik.
Taki sposób nazewnictwa ma znaczenie praktyczne przy obsłudze wielu routerów jednocześnie - na wspólnym serwerze FTP mogą bezpiecznie współistnieć kopie pochodzące z dziesiątek różnych urządzeń i z wielu kolejnych dni, a mimo to każdy plik pozostaje jednoznacznie identyfikowalny bez potrzeby zaglądania w jego zawartość czy sprawdzania metadanych systemu plików.
Skrypt RouterOS krok po kroku
Skrypt backupu, uruchamiany cyklicznie przez wewnętrzny harmonogram RouterOS, wykonuje kolejno kilka etapów. Najpierw ustala bieżącą datę i godzinę oraz konwertuje nazwę miesiąca zwracaną przez system na jej numeryczny odpowiednik, budując z tych elementów spójny, sortowalny znacznik czasu w nazwach plików.
# backup the data
/tool user-manager database save name=$fname
/system backup save name=$fname1
/export compact file=$fname2
# upload each file over FTP
/tool fetch address="$ftphost" src-path=$fname user="$ftpuser" mode=ftp password="$ftppassword" dst-path="$ftppath/$fname" upload=yesPo zapisaniu wszystkich trzech plików lokalnie na urządzeniu, skrypt przesyła każdy z nich osobnym poleceniem /tool fetch w trybie FTP na zewnętrzny serwer, zapisując do dziennika RouterOS komunikat potwierdzający ukończenie każdego z trzech etapów przesyłania.
Kontrola infrastruktury sieciowej z jednego miejsca
Weryfikacja kopii konfiguracji routerów łączy monitoring sieci z pozostałymi zadaniami utrzymaniowymi SSJob.
Serwer FTP i porządkowanie plików
Wszystkie trzy pliki trafiają na dedykowany serwer FTP, w którym każde wdrożenie ma przypisany własny katalog docelowy, odizolowany od katalogów innych klientów. Takie rozdzielenie pozwala przechowywać kopie konfiguracji wielu routerów różnych klientów na jednym wspólnym serwerze backupowym, bez ryzyka pomylenia plików należących do różnych sieci.
Po potwierdzeniu zakończenia przesyłania - z niewielkim, celowym opóźnieniem zabezpieczającym przed przerwaniem transferu dużych plików - skrypt porządkuje lokalną pamięć routera, wyszukując i usuwając wszystkie pliki, których nazwa zaczyna się od prefiksu UMDB-. Krok ten ma istotne znaczenie praktyczne, ponieważ routery MikroTik dysponują zwykle znacznie mniejszą przestrzenią dyskową niż typowy serwer, a pozostawione kopie szybko zapełniłyby dostępną pamięć urządzenia.
To zautomatyzowane sprzątanie eliminuje typowy problem ręcznie wykonywanych backupów - zapominanie o usunięciu starych plików z urządzenia, które z czasem prowadzi do braku miejsca na wykonanie kolejnej, świeżej kopii w chwili, gdy jest ona najbardziej potrzebna. Router, w przeciwieństwie do serwera aplikacyjnego, rzadko jest rutynowo sprawdzany pod kątem wolnej przestrzeni, dlatego takie zabezpieczenie wbudowane bezpośrednio w skrypt backupu ma tu szczególne znaczenie.
Tabela mkt_backup i weryfikacja w SSJob
Fakt wykonania kopii konfiguracji poszczególnych routerów odnotowywany jest po stronie StudioSystem w tabeli mkt_backup, dającej administratorowi scentralizowany wgląd w stan zabezpieczenia całej infrastruktury sieciowej obsługiwanych wdrożeń, bez potrzeby logowania się osobno do każdego urządzenia.
Nad tą ewidencją czuwa właściwe zadanie usługi SSJob, skonfigurowane jak większość pozostałych zadań tej rodziny - wierszem w tabeli _jobs z polami OSTATNIOWYKONANO, CYKLICZNOSC, CYKLICZNOSCTYPE, MAILPOWIADOMIENIE i CONECTIONSTRINGNAME. W tym przypadku zadanie SSJob nie wykonuje samego backupu, lecz sprawdza zawartość tabeli mkt_backup i wysyła powiadomienie e-mail, gdy któryś z monitorowanych routerów nie zgłosił wykonania kopii w oczekiwanym terminie.
Mechanizm ten jest pod tym względem bliższy zasadzie działania raportu warunkowego JEŻELI niż klasycznemu zadaniu wykonującemu operację na danych - w obu przypadkach usługa SSJob najpierw sprawdza pewien stan, a dopiero potem decyduje, czy i jaką wiadomość wysłać, zamiast bezwarunkowo realizować tę samą czynność w każdym cyklu.
Różnica względem kopii bazy i aplikacji
Warto wyraźnie odróżnić MikroTik Backup od kopii bazy MSSQL oraz kopii aplikacji, mimo że wszystkie trzy zadania współdzielą ten sam mechanizm powiadomień w tabeli _jobs. Kopia bazy i kopia aplikacji zabezpieczają dane oraz pliki znajdujące się na serwerze aplikacyjnym StudioSystem i są wykonywane bezpośrednio przez usługę SSJob. MikroTik Backup zabezpiecza zupełnie inny, zewnętrzny element infrastruktury - konfigurację urządzeń sieciowych - a SSJob pełni tu rolę nadzorczą, a nie wykonawczą.
To rozróżnienie ma znaczenie praktyczne przy planowaniu odzyskiwania po awarii - pełne przywrócenie działania wdrożenia po poważnej awarii wymaga nie tylko bazy danych i plików aplikacji, ale też sprawnej sieci, którą bez aktualnej kopii konfiguracji routera trzeba by odtwarzać od zera, ręcznie odtwarzając każde ustawienie. Podobnie jak reorganizacja indeksów uzupełnia pełną odbudowę w warstwie wydajności bazy danych, tak MikroTik Backup uzupełnia kopię bazy i aplikacji w zupełnie innej warstwie - warstwie sieciowej, bez której żadna z pozostałych kopii nie przyda się użytkownikom pozbawionym dostępu do systemu.
Dobre praktyki
Kilka zasad pomaga utrzymać ten mechanizm skutecznym niezależnie od liczby obsługiwanych routerów:
- Regularna kontrola tabeli mkt_backup - szybkie sprawdzenie, czy wszystkie monitorowane routery zgłosiły ostatnią kopię zgodnie z harmonogramem.
- Testowe odtworzenie konfiguracji - okresowe, praktyczne sprawdzenie na zapasowym urządzeniu, czy plik .backup lub .rsc rzeczywiście nadaje się do przywrócenia.
- Ograniczony dostęp do katalogu FTP - każde wdrożenie powinno mieć dostęp wyłącznie do własnego, odizolowanego katalogu na wspólnym serwerze backupowym.
- Weryfikacja powiadomień - brak spodziewanego e-maila o zaległej kopii konkretnego routera jest sygnałem ostrzegawczym samym w sobie.
- Aktualizacja danych dostępowych FTP - zmiana hasła lub adresu serwera backupowego wymaga ręcznej aktualizacji skryptu na każdym obsługiwanym routerze z osobna.
Podobnie jak przy pozostałych zadaniach tej serii, koszt zaniedbania tego mechanizmu ujawnia się dopiero w chwili awarii urządzenia sieciowego - a wtedy aktualna kopia konfiguracji potrafi skrócić czas przywrócenia łączności z wielu godzin ręcznej rekonfiguracji do kilku minut wgrania gotowego pliku. Warto też, podobnie jak przy organizacji bazy danych, obserwować w czasie liczbę i wielkość plików trafiających na serwer FTP - gwałtowny wzrost rozmiaru eksportu konfiguracji bywa sygnałem nieplanowanej rozbudowy sieci, wartym odnotowania niezależnie od samego backupu.
Podsumowanie
MikroTik Backup to zadanie łączące skrypt RouterOS działający bezpośrednio na routerze z nadzorem realizowanym przez usługę SSJob po stronie StudioSystem. Trzy pliki - kopia User Managera, pełny backup systemu i eksport konfiguracji - trafiają na zewnętrzny serwer FTP, a ich obecność potwierdza tabela mkt_backup, monitorowana cyklicznym wierszem w tabeli _jobs.
Razem z kopią bazy MSSQL i kopią aplikacji, kopia konfiguracji routerów MikroTik domyka pełny obraz zabezpieczenia infrastruktury wdrożenia StudioSystem - danych, plików aplikacji i warstwy sieciowej. Żaden z tych trzech elementów nie zastępuje pozostałych, a dopiero wszystkie razem, monitorowane wspólnym mechanizmem powiadomień usługi SSJob, dają administratorowi pewność, że w razie awarii odtworzenie działania wdrożenia będzie sprawą godzin, a nie dni.