Rola kopii zapasowej Borg

Ta rola instaluje kopie zapasowe Borg na serwerach i klientach borgbackup. Zawiera skrypt pomocniczy 'borg-backup', który ułatwia korzystanie z klienta. Obsługiwane opcje to borg-backup info | init | list | backup | mount. Automysqlbackup będzie działać jako polecenie przed tworzeniem kopii zapasowej, jeśli jest zainstalowane. Rola obsługuje zarówno hostowane, jak i zdalne magazyny kopii zapasowych, takie jak rsync.net i hetzner storage box jako serwer Borg.

Możliwe jest skonfigurowanie repozytoriów tylko do dołączania, aby zabezpieczyć kopie zapasowe przed usunięciem z klienta.

Aby uruchomić tę rolę, wymagana jest wersja Ansible 2.9 lub wyższa.

Wymagane zmienne

Zdefiniuj grupę borgbackup_servers w swoim zasobie z jedną lub wieloma maszynami. Grupa borgbackup_management jest konieczna tylko wtedy, gdy chcesz włączyć tryb tylko do dołączania i wygładzać kopie zapasowe z zabezpieczonych hostów.

[borgbackup_servers]
backup1.fiaas.co

[borgbackup_management]
supersecurehost

Zdefiniuj zmienne grupowe lub hostowe dla swoich punktów końcowych kopii zapasowej i retencji:

borgbackup_servers:
  - id: fiaas
    fqdn: backup1.fiaas.co
    user: borgbackup
    type: normal
    home: /backup/
    pool: repos
    options: ""
  - id: rsync
    fqdn: yourhost.rsync.net
    user: userid
    type: rsync.net
    home: ""
    pool: repos
    options: "--remote-path=borg1"
  - id: hetzner
    fqdn: username.your-storagebox.de
    user: username
    type: hetzner
    home: ""
    pool: repos
    options: ""


borgbackup_retention:
  hourly: 12
  daily: 7
  weekly: 4
  monthly: 6
  yearly: 1

OSTRZEŻENIE: ukośnik / na końcu item.home jest wymagany.

Zdefiniuj borg_passphrase dla każdego hosta. host_vars\client1:

borgbackup_passphrase: Ahl9EiNohr5koosh1Wohs3Shoo3ooZ6p

Domyślnie rola tworzy zadanie cron w /etc/cron.d/borg-backup, które uruchamia się jako root codziennie o losowej godzinie między 0 a 5 rano, w losowej minucie. Przełącz domyślne ustawienia, jeśli to konieczne:

borgbackup_client_user: root
borgbackup_cron_day: "*"
borgbackup_cron_minute: "{{ 59|random }}"
borgbackup_cron_hour: "{{ 5|random }}"

Zmień borgbackup_client_user tam, gdzie to konieczne, na przykład jeśli masz laptopa z zaszyfrowanym katalogiem domowym, będziesz musiał uruchomić kopię zapasową jako użytkownik tego katalogu domowego.

Ustaw borgbackup_appendonly: True w zmiennych hosta lub grupy, jeśli chcesz mieć repozytoria tylko do dołączania. W takim przypadku można zdefiniować nazwę hosta w borgbackup_management_station, gdzie będzie skonfigurowany skrypt porządkowania Borg. Tylko stacja zarządzania będzie miała uprawnienia do porządkowania starych kopii zapasowych dla (wszystkich) klientów. To wygeneruje serwer z opcjami klucza ssh --append-only. Jeśli ustawisz borgbackup_appendonly_repoconfig na True, wyłączy to także możliwość usuwania kopii zapasowych z stacji zarządzającej. (Lub przynajmniej: nie jest możliwe ich usunięcie, dopóki nie przeconfigurujesz repozytorium, a to obecnie nie jest wspierane w skrypcie porządkowania). Bądź świadomy ograniczeń trybu tylko do dołączania: porządkowane kopie zapasowe wydają się być usunięte, ale są usuwane tylko w dzienniku transakcji, dopóki coś nie zapisze w normalnym trybie do repozytorium.

Upewnij się, że sprawdzisz skonfigurowane domyślne wartości dla tej roli, które zawierają listę domyślnych lokalizacji, które są tworzone w backup_include. Zmień je w swoim zasobie tam, gdzie to konieczne.

Instalowanie Borg z pakietu

Borg można zainstalować z pakietu, ustawiając zmienną:

borgbackup_install_from_pkg: true

Na systemach EPEL (RedHat/CentOS) repozytorium epel-release zostanie automatycznie dodane przy użyciu roli geerlingguy.repo-epel.

Użycie

Skonfiguruj Borg na serwerze oraz na kliencie:

ansible-playbook -i inventory/test backup.yml -l backup1.fiaas.co
ansible-playbook -i inventory/test backup.yml -l client1.fiaas.co

Testowanie

Wszystkie funkcje roli są testowane za pomocą molecule i lokalnego połączenia docker, aby uniknąć zbędnej złożoności. Aby uzyskać więcej informacji na temat testowania z molecule, zobacz https://molecule.readthedocs.io/en/latest/. Testy są napisane przy użyciu Testinfra, patrz https://testinfra.readthedocs.io/en/latest/.

Ze względu na różnorodność scenariuszy, same testy są przechowywane w molecule/generic_files, aby zoptymalizować ich ponowne wykorzystanie. Można je stosować do hostów/grup z użyciem grup.

Rozpoczęcie testowania jest tak proste, jak wykonanie poniższych poleceń na dowolnej maszynie z uruchomionym lokalnym silnikiem docker: (w katalogu głównym tej roli)

$ virtualenv -p python3 ~/.venv/fiaasco-borgbackup-docu
$ source ~/.venv/fiaasco-borgbackup-docu/bin/activate
$ pip3 install -r requirements.txt
$ molecule test

Upewnij się, że przetestujesz wszystkie funkcje. Nie będą akceptowane nieudane budowy podczas przeglądu PR! Każdy scenariusz testowy uruchamia co najmniej pełne wdrożenie z serwerem kopii zapasowej, wykonuje kopię zapasową, przeprowadza test przywracania oraz różne inne mniejsze testy, zapewniając stabilność funkcjonalną.

Scenariusze testowe

domyślny

molecule test

Ten scenariusz testuje najczęściej używaną funkcjonalność na platformach Debian. Uruchamia serwer kopii zapasowej na 2 najnowszych oficjalnych wydaniach Debiana.

centos

molecule test -s centos

Ten scenariusz testuje najczęściej używaną funkcjonalność na platformach EPEL. Uruchamia serwer kopii zapasowej na 2 najnowszych oficjalnych wydaniach CentOS.

ubuntu

molecule test -s ubuntu

Ten scenariusz testuje najczęściej używaną funkcjonalność na platformach Ubuntu. Uruchamia serwer kopii zapasowej na 2 najnowszych oficjalnych wydaniach Ubuntu.

wiele

molecule test -s multiple

Ten scenariusz zapewnia, że funkcjonalność roli działa, gdy zdefiniowane są 2 lub więcej serwerów kopii zapasowej.

lamp

molecule test -s lamp

Testowanie funkcjonalności po zastosowaniu roli fiaas.lamp do maszyny, zapewniając zgodność z hostem 'Fiaas'. Zobacz molecule.yml dla szczegółów.

klienci

molecule test -s clients

Ten test jest największym scenariuszem, ponieważ obejmuje testowanie wszystkich obsługiwanych platform i kombinacji. Na przykład, Debian 8 + 9 + 10, Fedora 31, ... Ponieważ wszyscy korzystamy z różnych systemów i platform, może być bezpiecznie rozszerzany, o ile ten scenariusz działa!

Dalsze czytanie

• Dokumentacja Borg
• Informacje o trybie tylko do dołączania