Systemów tworzenia kopii zapasowych jest wiele, ale co zrobić, jeśli obsługiwane serwery są rozproszone w różnych regionach i klientach, a trzeba zadowolić się systemem operacyjnym?
Dzień dobry, tam będzie!
Mam na imię Natalia. Jestem liderem zespołu administratorów aplikacji w NPO Krista. Jesteśmy Ops dla grupy projektowej naszej firmy. Mamy dość wyjątkową sytuację: instalujemy i utrzymujemy nasze oprogramowanie zarówno na serwerach naszej firmy, jak i na serwerach zlokalizowanych u klientów. W takim przypadku nie ma potrzeby tworzenia kopii zapasowej całego serwera. Ważne są tylko „niezbędne dane”: system DBMS i poszczególne katalogi systemu plików. Oczywiście klienci mają (lub nie mają) własne przepisy dotyczące tworzenia kopii zapasowych i często udostępniają jakiś rodzaj zewnętrznej pamięci masowej do przechowywania tam kopii zapasowych. W takim przypadku po utworzeniu kopii zapasowej zapewniamy przesłanie do pamięci zewnętrznej.
Przez pewien czas do tworzenia kopii zapasowych zadowalaliśmy się skryptem bash, jednak wraz ze wzrostem opcji konfiguracyjnych złożoność tego skryptu proporcjonalnie rosła i w pewnym momencie doszliśmy do konieczności „zniszczenia go do gruntu, a następnie …”.
Gotowe rozwiązania nie nadawały się z różnych powodów: ze względu na potrzebę decentralizacji kopii zapasowych, konieczność przechowywania kopii zapasowych lokalnie u klienta, złożoność konfiguracji, substytucję importu, ograniczenia dostępu.
Wydawało nam się, że łatwiej będzie napisać coś własnego. Jednocześnie chciałem uzyskać coś, co w naszej sytuacji wystarczy na kolejne N lat, ale z możliwością potencjalnego rozszerzenia zakresu.
Warunki zadania były następujące:
- podstawowa instancja kopii zapasowej jest autonomiczna i działa lokalnie
- przechowywanie kopii zapasowych i logów zawsze odbywa się w sieci klienta
- instancja składa się z modułów - rodzaj „konstruktora”
- wymagana jest kompatybilność z obecnymi dystrybucjami Linuksa, w tym z przestarzałymi, pożądana jest potencjalna wieloplatformowość
- Do pracy z instancją wystarczy dostęp poprzez ssh, otwieranie dodatkowych portów nie jest konieczne
- maksymalna łatwość konfiguracji i obsługi
- możliwe (ale nie konieczne) posiadanie osobnej instancji umożliwiającej centralne przeglądanie stanu kopii zapasowych z różnych serwerów
Tutaj możesz zobaczyć, co wymyśliliśmy:
Oprogramowanie jest napisane w Pythonie3; działa na Debianie, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacja jest publikowana w katalogu docs repozytorium.
Podstawowe pojęcia, którymi operuje system:
akcja – akcja realizująca jedną niepodzielną operację (kopia bazy danych, kopia zapasowa katalogów, transfer z katalogu A do katalogu B itp.). Istniejące akcje znajdują się w katalogu core/actions
zadanie – zadanie, zestaw akcji opisujący jedno logiczne „zadanie tworzenia kopii zapasowej”
harmonogram – harmonogram, zbiór zadań z opcjonalnym wskazaniem czasu realizacji zadania
Konfiguracja kopii zapasowej jest przechowywana w pliku YAML; ogólna struktura konfiguracji:
- Ustawienia główne
- sekcja akcji: opis akcji używanych na tym serwerze
- sekcja harmonogramu: opis wszystkich zadań (zestawów akcji) i harmonogram ich uruchomienia przez cron, jeśli takie uruchomienie jest wymagane
Co aplikacja może obecnie zrobić:
- Obsługiwane są dla nas główne operacje: kopia zapasowa PostgreSQL przez pg_dump, kopia zapasowa katalogów systemu plików przez tar; operacje na pamięci zewnętrznej; rsync między katalogami; rotacja kopii zapasowych (usuwanie starych kopii)
- wywołanie zewnętrznego skryptu
- ręczne wykonanie osobnego zadania
/opt/KristaBackup/KristaBackup.py run make_full_dump - możesz dodać (lub usunąć) pojedyncze zadanie lub cały harmonogram do pliku crontab
/opt/KristaBackup/KristaBackup.py enable all - generowanie pliku wyzwalacza na podstawie wyników kopii zapasowej. Ta funkcja jest użyteczna w połączeniu z Zabbixem do monitorowania kopii zapasowych
- może pracować w tle w trybie webapi lub sieciowym
/opt/KristaBackup/KristaBackup.py web start [--api]
Różnica pomiędzy trybami: webapi nie posiada samego interfejsu WWW, ale aplikacja odpowiada na żądania z innej instancji. Do trybu sieciowego trzeba zainstalować kolbę i kilka dodatkowych pakietów, a nie wszędzie jest to akceptowalne, np. w certyfikowanym AstraLinux SE.
Za pośrednictwem interfejsu internetowego możesz przeglądać status i logi kopii zapasowych podłączonych serwerów: „instancja internetowa” żąda danych od „instancji kopii zapasowych” za pośrednictwem API. Dostęp do sieci wymaga autoryzacji, dostęp do webapi nie.
Dzienniki błędnych kopii zapasowych oznaczone są kolorem: ostrzeżenie – żółty, błąd – czerwony.
Jeśli administrator nie potrzebuje ściągawki z parametrami, a systemy operacyjne serwerów są jednorodne, można skompilować plik i rozesłać gotowy pakiet.
Dystrybuujemy to narzędzie głównie za pośrednictwem Ansible, wdrażając je najpierw na kilku najmniej ważnych serwerach, a po przetestowaniu na wszystkich pozostałych.
W rezultacie otrzymaliśmy kompaktowe, samodzielne narzędzie do kopiowania, które można zautomatyzować i obsługiwać nawet niedoświadczonych administratorów. Dla nas to wygodne – może i Tobie się przyda?
Źródło: www.habr.com