Istnieje wiele systemów do tworzenia kopii zapasowych, ale co zrobić, jeśli obsługiwane serwery są rozproszone w różnych regionach i u klientów, a trzeba się posługiwać środkami systemu operacyjnego?
Dzień dobry, Habr!
Nazywam się Natalia. Jestem liderem zespołu administratorów aplikacji w NPO "Krista". Jesteśmy działem operacyjnym dla grupy projektów naszej firmy. Mamy do czynienia z dość nietypową sytuacją: instalujemy i wspieramy nasze oprogramowanie zarówno na serwerach naszej firmy, jak i na serwerach znajdujących się u klientów. W tym przypadku nie ma potrzeby tworzenia kopii zapasowej całego serwera. Ważne są jedynie "istotne dane": bazy danych i poszczególne katalogi systemu plików. Oczywiście klienci mają (lub nie mają) swoje regulacje dotyczące tworzenia kopii zapasowych i często udostępniają jakieś zewnętrzne miejsce do przechowywania kopii zapasowych. W takim przypadku po utworzeniu kopii zapasowej zapewniamy wysyłkę do zewnętrznego magazynu.
Przez jakiś czas do celów tworzenia kopii zapasowych korzystaliśmy ze skryptu bash, ale w miarę rozrastania się opcjonalnych ustawień rosła również złożoność tego skryptu, i pewnego pięknego dnia doszliśmy do konieczności "zniszczenia go do fundamentów, a następnie....".
Gotowe rozwiązania nie pasowały z różnych powodów: z powodu konieczności decentralizacji kopii zapasowych, obowiązkowego przechowywania kopii zapasowych lokalnie u klienta, trudności w konfiguracji, importozamienności, ograniczeń dostępu.
Stwierdziliśmy, że łatwiej będzie napisać coś własnego. Chcieliśmy stworzyć coś wystarczającego do naszej sytuacji na kolejne N lat, ale z możliwością potencjalnego rozszerzenia obszaru zastosowania.
Warunki zadania były następujące:
- podstawowy instans kopii zapasowej jest autonomiczny, działa lokalnie
- przechowywanie kopii zapasowych i logów zawsze w obrębie sieci klienta
- instans składa się z modułów – swoisty "konstruktor"
- wymagana jest kompatybilność z używanymi dystrybucjami Linux, w tym przestarzałymi, pożądana jest potencjalna wieloplatformowość
- do pracy z instansem wystarczy dostęp przez ssh, otwieranie dodatkowych portów nie jest konieczne
- maksymalna prostota konfiguracji i eksploatacji
- możliwe (ale nieobowiązkowe) istnienie osobnego instansu, który pozwala na centralne przeglądanie stanu kopii zapasowych z różnych serwerów
To, co nam się udało, można zobaczyć tutaj:
Program został napisany w python3; działa na Debianie, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacja jest dostępna w katalogu docs repozytorium.
Podstawowe pojęcia używane przez system:
action – działanie, które realizuje jedną atomową operację (backup bazy danych, backup katalogu, przenoszenie z katalogu A do katalogu B itp.). Istniejące actions znajdują się w katalogu core/actions
task – zadanie, zbiór actions, opisujące jedną logiczną „zadanie backupu”
schedule – harmonogram, zbiór task z opcjonalnym wskazaniem czasu wykonania zadania
Konfiguracja backupu jest przechowywana w pliku yaml; ogólna struktura konfiguracji:
- ogólne ustawienia
- sekcja actions: opis działań używanych na tym serwerze
- sekcja schedule: opis wszystkich zadań (zbiorów działań) oraz harmonogram ich uruchamiania przez cron, jeśli takie uruchomienie jest wymagane
Co potrafi aplikacja w chwili obecnej:
- obsługiwane są główne operacje: backup PostgreSQL przez pg_dump, backup katalogu systemu plików przez tar; operacje z zewnętrznym magazynem; rsync między katalogami; rotacja backupów (usuwanie starych kopi)
- wywołanie zewnętrznego skryptu
- ręczne wykonanie pojedynczego zadania
/opt/KristaBackup/KristaBackup.py run make_full_dump - można dodać (lub usunąć) pojedyncze zadanie lub cały harmonogram w crontabie
/opt/KristaBackup/KristaBackup.py enable all - generacja pliku sygnalizacyjnego na podstawie wyników backupu. Ta funkcja jest przydatna w połączeniu z Zabbix do monitorowania backupów
- może działać w tle w trybie webapi lub web
/opt/KristaBackup/KristaBackup.py web start [--api]
Różnica między trybami: w webapi nie ma własnego interfejsu webowego, ale aplikacja odpowiada na zapytania innego instancji. W trybie web należy zainstalować flask i kilka dodatkowych pakietów, co nie zawsze jest akceptowalne, na przykład w certyfikowanej AstraLinux SE.
Poprzez interfejs webowy można zobaczyć stan i logi backupów podłączonych serwerów: „instancja webowa” pobiera dane z „instancji backupowej” za pomocą API. Dostęp do web wymaga autoryzacji, dostęp do webapi – nie.
Logi niepoprawnie przeprowadzonych backupów są oznaczane kolorem: warning – żółtym, error – czerwonym.
Jeśli administrator nie potrzebuje ściągawki dotyczącej parametrów i systemy operacyjne serwerów są jednorodne, można skompilować plik i rozpowszechniać gotowy pakiet.
Rozpowszechniamy tę usługę głównie przez Ansible, wdrażając najpierw na części mniej istotnych serwerów, a po testach na wszystkie pozostałe.
Ostatecznie otrzymaliśmy kompaktowe, autonomiczne narzędzie do kopiowania, które można zautomatyzować i które nadaje się do użytku nawet dla mniej doświadczonych administratorów. Nam to odpowiada – może i wam się przyda?
Źródło: habr.com
