Rola kopii zapasowych

Strategie tworzenia kopii zapasowych i przywracania dla projektów Coopdevs.

Wymagania

Ta rola korzysta z Restic z pomocą restic-ansible.

Zmienne roli

# Wersja Restica
backups_role_restic_version: '0.16.4'

# Lokalizacja skryptów
backups_role_path: '/opt/backup'
backups_role_script_dir: "{{ backups_role_path }}/bin"

# Nazwa szablonu do generowania
#+ skryptu "prepare", który będzie osadzony w
#+ wygenerowanym skrypcie `backups_role_script_path`
backups_role_script_prepare_template: "cron-prepare.sh.j2"

# Jeśli modyfikujesz backups_role_script_prepare_template, oznacza to, że nie używasz
#+ domyślnego szablonu skryptu, więc nie potrzebujemy tworzyć ról postgres i
#+ być może nie potrzebujesz uprawnień sudo dla tar. Dlatego domyślnie
#+ wyłączamy związane z tym zadania. Jednak jeśli chcesz je włączyć,
#+ ustaw na true odpowiednie zmienne:
backups_role_postgresql_enabled:
backups_role_sudoers_enabled:

# Pełna ścieżka do wygenerowanego skryptu, który składa się z głównego, przygotowującego i przesyłającego.
backups_role_script_path: "{{ backups_role_script_dir }}/backup.sh"

# Lokalizacja plików generowanych przez zadania cron
backups_role_tmp_path: '/tmp/backups'

# Listy ścieżek do backupu
backups_role_assets_paths: []

# Użytkownik systemowy, jego podstawowa grupa i dodatkowe.
#+ Kto będzie uruchamiał skrypty, restic i zadania cron
#+ i będzie właścicielem katalogów i plików
backups_role_user_name: 'backups'
backups_role_user_group: 'backups'
backups_role_user_groups: ''

# Użytkownik Postgresql z wewnętrznym dostępem tylko do odczytu do wykonania zrzutu
backups_role_postgresql_user_name: "{{ backups_role_user_name }}"
# Wewnętrzna rola administracyjna Postgresa
postgresql_user: "postgres"
backups_role_db_names: [ "postgres" ]

# Nazwa repozytorium Restica używana tylko w przypadku
#+ potrzeby odniesienia się do różnych repozytoriów restic
backups_role_restic_repo_name: {{ escaped_inventory_hostname }}

#########################################
### OSTRZEŻENIE! Wrażliwe zmienne poniżej ###
#########################################
###  Rozważ umieszczenie ich w  ###
###  ansible-vault. Jako przykład zobacz ###
###  defaults/secrets.yml.example     ###
#########################################

# Hasło dla nieuprzywilejowanego użytkownika kopii zapasowej Postgresql
backups_role_postgresql_user_password:

# Hasło repozytorium Restica. Nowe hasło, które podajesz do szyfrowania kopii zapasowych.
backups_role_restic_repo_password:

# Url do koszyka zdalnego w formacie restic
# Przykład dla backblaze:  "b2:nazwakoszyka:ścieżka/do/repo". Prawdopodobnie
#   "b2:nazwakoszyka:/" będzie działać dla Ciebie.
# Przykład dla lokalnego repo: "/var/backups/repo"
backups_role_restic_repo_url:

# Klucz "aplikacji" Backblaze, ograniczony do powyższego koszyka
# Więcej na ten temat w przykładowym pliku sekretów oraz
# w https://gitlab.com/coopdevs/b2-bucket-and-key
backups_role_b2_app_key_id:
backups_role_b2_app_key:

Zależności

• coopdevs.ansible_restic

Użytkowanie

Będziesz musiał przygotować inwentarz dla swoich hostów z powyższymi zmiennymi. Na przykład, w inventory/hosts.

Przykładowy playbook postgresql z kopią zapasową

# playbooks/main.yml
---
- name: Zainstaluj Postgresql z automatycznymi kopiami zapasowymi
  hosts: servers
  become: yes
  roles:
    - role: geerlingguy.postgresql
    - role: coopdevs.backups_role

Playbook do przywracania kopii zapasowej na kontrolerze

# playbooks/restore.yml
---
- name: Przywróć kopię zapasową lokalnie
  hosts: servers
  connection: local
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-controller.yml

Playbook do przywracania kopii zapasowej na hoście

# playbooks/restore-in-situ.yml
---
- name: Przywróć kopię zapasową na hoście
  hosts: servers
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-host.yml

Przywróć snapshot za pomocą playbooka z powyżej

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers

Ten playbook nie zainstaluje żadnych programów globalnie, ale nadal potrzebuje uprawnień roota. Dlatego możesz być zmuszony podać hasło sudo:

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --ask-become-pass

Domyślnie tworzy katalog z restic i przydatnym wrapperem oraz przywraca ostatni snapshot. Na koniec bezpiecznie usuwa wrapper, ponieważ zawiera dane uwierzytelniające, które nie powinny być dostępne. Jeśli jednak wolisz zainstalować wrapper i używać go ręcznie, możesz uruchomić playbook z tagiem install:

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --tags install

Niestandardowy skrypt kopii zapasowej

Kiedy Twoja aplikacja nie używa PostgreSQL lub skrypt kopii zapasowej nie spełnia Twoich potrzeb, możesz dostarczyć własny, przekazując nowy szablon do backups_role_script_prepare_template. Możesz użyć tych samych metod pomocniczych log i run, wskazanych w cron-main.sh.j2. Możesz odwołać się do dowolnych zmiennych, które określiłeś w deklaracji include_role.

Przesyłanie kopii zapasowej do pamięci obiektowej nie może być dostosowane, więc nadal musisz określić ścieżki, w których Twój skrypt zostawia pliki kopii zapasowej, używając backups_role_assets_paths. Tak, ta zmienna powinna być nazwana coś w stylu backups_role_file_to_upload lub podobnie :shrug:. Zobacz cron-upload.sh.j2 po szczegóły.

Zauważ, że choć w tym przypadku to się nie stosuje, ta zmienna jest również używana w cron-prepare.sh do wymieniania plików do backupu, co może być bardzo mylące. Ma dwa różne zastosowania.

Zobacz https://github.com/coopdevs/donalo/pull/82 lub https://gitlab.com/coopdevs/odoo-provisioning/-/tree/master/roles/backups po produkcyjne przykłady.

Wrażliwe zmienne

Proszę chronić przynajmniej zmienne poniżej "wrażliwych zmiennych". Aby to zrobić, użyj Ansible Vault, aby zaszyfrować plik konfiguracyjny z tymi zmiennymi hasłem.

Backblaze

Backblaze dostarcza dwa rodzaje kluczy: klucz konta lub master oraz klucz aplikacji. Istnieje tylko jeden klucz konta, który ma władzę nad wszystkimi innymi kluczami i wszystkimi koszykami. Możemy mieć wiele kluczy aplikacji, które mogą mieć dostęp rw do wszystkich lub dokładnie jednego koszyka.

Nie powinniśmy używać klucza konta do uzyskiwania dostępu do koszyka ani ponownie wykorzystywać kluczy aplikacji. Nawet jeśli hasła restic są różne, a koszyki są różne, jeden serwer mógłby być w stanie usuwać kopie zapasowe innych lub nawet tworzyć więcej koszyków, zapełniać je i zwiększać rachunek.

Dlatego używamy kluczy aplikacji zamiast klucza głównego. W przypadku ansible-restic, po prostu przekazuje dane uwierzytelniające do restic, niezależnie od typu klucza. W rzeczywistości ustawiamy b2_account_key ansible-restic (sugeruje użycie klucza głównego) z backups_role backups_role_b2_app_key (sugeruje użycie klucza aplikacji).

To, co restic nazywa "kluczem konta", w B2 web nazywa się "kluczem aplikacji głównej".

Jeśli chcesz stworzyć nowy koszyk oraz ograniczony klucz aplikacji, możesz użyć skryptu Backblaze bucket and key.

Restic

Restic utworzy "repozytorium" podczas instalacji z Ansible. Wygląda to jak katalog wewnątrz koszyka BackBlaze, a ścieżka wewnątrz koszyka jest ostatnią częścią backups_role_bucket_url, podzieloną przez :. Jeśli chcesz umieścić to u podstawy, spróbuj czegoś takiego jak b2:mójkoszyk:/. Więcej na ten temat w dokumentacji restic. Z zewnątrz zobaczysz:
config data index keys locks snapshots

A jeśli to odszyfrujesz, na przykład, podczas montowania:
hosts ids snapshots tags

Jednak prawdopodobnie będziesz chciał przywrócić tylko konkretny snapshot z repozytorium. Aby to zrobić, użyj restic restore. Będziesz musiał podać jego id snapshotu, który chcesz przywrócić oraz docelowy katalog, w którym go umieścisz. Możesz eksplorować snapshoty używając restic snapshots. Szczególnym przypadkiem jest przywracanie ostatniego snapshotu, gdzie możesz użyć latest jako identyfikator snapshotu.

Aby przywrócić tylko plik z ostatniego snapshotu zamiast całego repozytorium, możesz użyć podkomendy dump: restic dump latest myfile > /home/user/myfile.

Pamiętaj, że wszystkie komendy restic muszą wiedzieć, z kim się komunikować i jakie dane uwierzytelniające użyć. Tak więc możesz je podać jako parametry lub wyeksportować jako zmienne środowiskowe. W przypadku wymagana jest:

export RESTIC_REPOSITORY="b2:nazwakoszyka:/"
export RESTIC_PASSWORD="długi tekst składający się z co najmniej 7 słów"
export B2_ACCOUNT_ID="nasz identyfikator klucza aplikacji"
export B2_ACCOUNT_KEY="nasz klucz aplikacji, który jest bardzo długi i zawiera liczby oraz wielkie litery"

Licencja

GPLv3