BackupPC-Client Ansible rola

Ta rola, backuppc_client, instaluje i konfiguruje obydwie strony dla hostów-klientów serwera BackupPC. Współpracuje z rolą backuppc_server, która konfiguruje serwer (jednakże, jeśli konfiguracja jest standardowa i Ansible ma dostęp, może obsługiwać każdą instalację serwera BackupPC).

Działa na Debianie Buster (10) i Stretch (9) w przypadku zaawansowanej konfiguracji (kopie zapasowe baz danych), ale dla podstawowej konfiguracji dumpów BackupPC może obsługiwać Ubuntu lub inne systemy oparte na Debianie (PR akceptowane).

Ta rola i jej odpowiednik backuppc_server opierają się na roli hanxhx/backuppc.

Opis

Ta rola konfiguruje kopie zapasowe hostów w serwerze BackupPC. Może wykonać następujące akcje:

• Ustawić użytkownika Linuxa w kliencie oraz konfigurację kopii zapasowych na serwerze BackupPC, który uzyskuje dostęp do klienta tym użytkownikiem.
• Opcjonalne przesłanie do klienta skryptów pre_dump i post_dump z ewentualnymi uprawnieniami sudo, które są wykonywane odpowiednio przed i po zrzucie plików BackupPC. Skrypty te wykonują polecenia potrzebne do zapewnienia spójnych kopii zapasowych, takie jak zrzuty baz danych, migawki, itp.
• Opcjonalne skonfigurowanie użytkownika mysql z uprawnieniami SELECT we wszystkich bazach w celu wykonania zrzutu przed kopią zapasową.
• Opcjonalne ustawienie skryptu, który zrzuci określoną bazę danych PostgreSQL.

Wymagania

Będziesz potrzebować działającego serwera BackupPC zarządzanego w swoim inwentarzu Ansible, którego nazwę zdefiniujesz w zmiennej backuppc_server_name.

Na tę chwilę ta rola obsługuje jedynie kopie zapasowe metodą rsync (+ ssh).

Kompatybilność wsteczna

Aby zapewnić płynne i stopniowe wprowadzenie tej wersji roli na wszystkich hostach, które jej używają w środowisku chmurowym, rola jest kompatybilna wstecznie z API zmiennych roli v1.X.0, w tym jej wartości domyślne. Zobacz pliki defaults/main.yml i tasks/compatibility.yml, szczególnie komentarze, aby uwzględnić zmienne legacy.

Kompatybilność roli wstecz będzie usunięta w następnej głównej wersji, więc jak najszybciej dostosuj zmienne swoich hostów!

Zmienne roli

Każda konfiguracja klienta nadpisuje globalną konfigurację na serwerze. Zobacz defaults/main.yml dla wartości domyślnych lub definicji. Poniżej wymienione są zmienne, które można zdefiniować.

Dostęp do klienta

• backuppc_client_user: użytkownik unixowy, za pomocą którego serwer łączy się z klientem (domyślnie backuppc)
• backuppc_client_group: grupa unixowa zdefiniowanego powyżej użytkownika unixowego (domyślnie backuppc)
• backuppc_client_home: katalog domowy użytkownika backuppc_client_user, który wykonuje kopie zapasowe na kliencie

Konfiguracja serwera

• backuppc_server_name: nazwa domeny serwera BackupPC, który wykonuje kopię zapasową i gdzie klucz ssh jest pobierany do skonfigurowania na kliencie
• backuppc_server_user: użytkownik unixowy, który uruchamia BackupPC na serwerze. Domyślnie backuppc.
• backuppc_server_group: grupa unixowa, która uruchamia BackupPC na serwerze. Domyślnie www-data.
• backuppc_server_home: katalog domowy użytkownika unixowego BackupPC na serwerze. Domyślnie /var/lib/backuppc.
• backuppc_server_config_dir: katalog plików konfiguracyjnych pakietu BackupPC. Domyślnie /etc/backuppc.

Konfiguracja kopii zapasowej klienta na serwerze

Poniżej krótko opisano zmienne roli, które definiują konfigurację BackupPC klienta na serwerze. Pełną dokumentację znajdziesz w dokumentacji BackupPC.

Następujące flagi definiują, czy klient i serwer są konfigurowane przez rolę:

• backuppc_backup_state: absent lub present (domyślnie: present). Jeśli obecny, konfiguruje kopie zapasowe klienta na serwerze, w przeciwnym razie usuwa konfigurację
• backuppc_client: jeśli ustawione na false (domyślna wartość true), nie ma dostępu ssh ani innej konfiguracji w hoście kliencie, tylko serwer jest skonfigurowany do wykonywania kopii zapasowej hosta

Plik konfiguracyjny klienta na serwerze BackupPC jest tworzony z następujących zmiennych:

• backuppc_rsync_share_names: lista punktów w drzewie folderów na kliencie do backupu. Na przykład:

backuppc_rsync_share_names:
- /etc
- /root
- /var
- /usr/local

Metoda rsync, BackupPC wykona polecenie rsync dla każdego elementu tej listy.

• backuppc_include_files:: lista folderów do uwzględnienia w kopii zapasowej klienta (opcje --include rsync zostaną zbudowane na podstawie tej zmiennej)
• backuppc_exclude_files:: lista folderów do wykluczenia z kopii zapasowej klienta (opcje --exclude rsync zostaną zbudowane na podstawie tej zmiennej)
• backuppc_xfermethod: Opcjonalna metoda transferu (domyślnie rsync)
• backuppc_more: Opcjonalny hasz ze specyficznymi kluczami/wartościami (przydatny do niestandardowych dyrektyw, takich jak harmonogram kopii zapasowych i ich przechowywanie). Zobacz przykład w pliku defaults/main.yml.

Następujące zmienne pozwalają zdefiniować wykonanie skryptów dumpu pre i post przez BackupPC:

• backuppc_pre_dump_script: ścieżka do skryptu pre_dump, który BackupPC wykona przed zrzuceniem plików podczas kopii zapasowej. Jego wartość domyślna to '{{ backuppc_client_home }}/scripts/pre_dump.sh'
• backuppc_post_dump_script: ścieżka do skryptu post_dump, który BackupPC wykona po zrzuceniu plików podczas kopii zapasowej. Jego wartość domyślna to '{{ backuppc_client_home }}/scripts/post_dump.sh'
• backuppc_scripts_local_dir: ścieżka w lokalnym kontrolerze Ansible, gdzie playbook znajdzie dwa powyższe skrypty, aby zainstalować je na kliencie. Jego wartość domyślna to '{{ playbook_dir }}/host_vars/{{ inventory_hostname }}/files/backuppc/'. W związku z tym w strukturze katalogów twojego playbooka musisz umieścić skrypty pre i post dump w plikach o tych samych podstawowych nazwach, w folderze nazwanym files/backuppc, obok folderu vars hosta, który konfigurujesz:

 host_vars
 └── <twoj_host>
     ├── files
     │   └── backuppc
     │       ├── post_dump.sh
     │       └── pre_dump.sh
     └── vars
         ├── 10_kvm_virtual.yml
         └── 20_backuppc.yml

• backuppc_scripts: Flaga skryptów true/false. Jeśli prawda, instaluje wcześniej opisane skrypty pre i post dump. Ta flaga jest przestarzała. Zachowana w celu zapewnienia kompatybilności wstecz, ale w następnej głównej wersji zostanie usunięta, a skrypty będą instalowane, gdy ich ścieżka jest zdefiniowana.

• backuppc_scripts_sudo: flaga true/false, aby nadać uprawnienia sudo do skryptów pre i post dump

• backuppc_DumpPreUserCmd i backuppc_DumpPostUserCmd: polecenia ssh, które backup os wykonywa w celu wykonania skryptów pre_dump i post_dump. Te zmienne są wcześniej zdefiniowane zgodnie z wcześniejszymi flagami, ale mogą być nadpisane.

• backuppc_sudoer polecenia autoryzowane z sudo dla użytkownika backuppc_client_user. Jest to ciąg, który można nadpisać, o ile zaczyna się od Cmnd_Alias BACKUPS =, а następie następuje lista poleceń powłoki, które użytkownik musi wykonać, aby wykonać kopię zapasową. Domyślnie ta zmienna zawiera rsync, a potencjalnie skrypty pre i post dump, w zależności od wcześniejszych flag.

Następujące zmienne dają narzędzia do definiowania, przy użyciu opisanych powyżej skryptów, zrzutu baz danych dla spójności backupów:

• backuppc_db_server_type: Zmienna o trzech stanach, która definiuje ewentualny zrzut mysql lub pgsql przed kopiami zapasowymi. Trzy możliwe wartości to: pgsql, mysql lub null. Zachowanie skryptów i zrzutów baz danych różni się dla mysql i pgsql. Szczególnie, dla MySQL musisz samodzielnie dodać skrypty pre_dump.sh i post_dump.sh, które wykonają zrzut baz danych, podczas gdy dla PostgreSQL te skrypty są budowane z szablonów (i zrzucają tylko jedną bazę danych). Dla PostgreSQL uprawnienia do bazy danych muszą być wcześniej zdefiniowane, a w przeciwieństwie do tego zadanie MySQL przydziela uprawnienia dostępu do bazy danych wybranemu użytkownikowi.
• Dla PostgreSQL zmienne to:
  • backuppc_db_to_dump_name definiuje bazę danych pgsql do backupu,
  • backuppc_db_dump_user definiuje użytkownika pgsql do uzyskania dostępu do bazy danych,
  • backuppc_db_dump_user_pass to hasło poprzedniego użytkownika. Ustawienie haseł i uprawnienia tego użytkownika na bazę danych muszą być ustawione w innym miejscu w playbooku.
• Dla MySQL zmienne to:
  • backuppc_db_server_root_pass powinno być ustawione na odpowiednią wartość, jeśli użytkownik mysql root ma zdefiniowane hasło. Domyślnie zmienna jest niezdefiniowana. Należy zauważyć, że w przypadku nowoczesnych instalacji mysql/mariadb, przynajmniej na Debianie, instalacja mysql nie prosi o hasło i nie generuje go losowo. Utrzymanie Debiana nie jest już wykonywane za pomocą konkretnego użytkownika i hasła, ale za pomocą użytkownika root przez unix sock, a nie socka uwierzytelnionego na tcp. Jeśli zmienna pozostaje niezdefiniowana, zadania mysql będą realizowane przy użyciu konfiguracji zarządzania debianem.
  • backuppc_db_dump_user i backuppc_db_dump_user_pass to nazwa użytkownika mysql i odpowiednie hasło, które będą miały dostęp SELECT do wszystkich baz i będą skonfigurowane jako domyślne w pliku .my.cnf w katalogu domowym użytkownika unixowego backuppc_client_user. Dzięki temu skrypty pre_dump.sh lub post_dump.sh będą mogły wykonać jakikolwiek zrzut bazy danych, wywołując proste polecenie mysql.

Następujące zmienne konfigurują dostęp do kopii zapasowej hosta klienta w interfejsie webowym BackupPC:

• backuppc_server_web_main_user: Główny użytkownik z dostępem do kopii zapasowych hosta klienta przez interfejs webowy BackupPC. Domyślnie backuppc.
• backuppc_server_web_other_users: Inni użytkownicy z dostępem do kopii zapasowych hosta klienta przez interfejs webowy BackupPC. Muszą być zdefiniowani jako ciąg z wymienionymi użytkownikami oddzielonymi przecinkami: "user1,user2". Dostęp użytkowników musi być skonfigurowany na serwerze BackupPC.

Przykłady skryptów Mysql

Dla kopii zapasowej MySQL, aby zrzucić wszystkie bazy przed zrzutem plików, można użyć następujących skryptów, które skorzystają z użytkownika backupowego mysql skonfigurowanego przez tę rolę:

• pre_dump.sh

#!/bin/bash
for DataB in `mysql -e "show databases" | grep -v Database`; do mysqldump --single-transaction $DataB > "$DataB.sql"; done
tar -czvf dump.sql.tar.gz *.sql
rm *.sql

• post_dump.sh

#!/bin/bash
rm dump.sql.tar.gz

Przykład Playbook

Zakładamy, że mamy standardową instancję BackupPC działającą na bck-server.domain.org, zarządzaną przez inwentarz Ansible. Poniższy playbook konfiguruje na tym serwerze kopię zapasową określonych folderów hosta client.domain.org, z potrzebnym dostępem ssh.

- name: Backup client.domain.org host
  hosts: client.domain.org
  become: true
  vars: 
  - backuppc_server_name: bck-server.domain.org
  - backuppc_rsync_share_names:
    - /etc
    - /var
    - /opt

  roles: 
  - role: udelarinterior.backuppc_client

Licencja

GPLv3

Informacje o autorze

Oryginalna rola Emilien M wzbogacona przez Víctor Torterola i Daniela Viñara