giner / ansible-role-barman

Ansible role to Install and configure Barman on Linux with optional: regular backup (running by cron), wals and snapshots uploading to S3 (running by cron), metrics collection (by telegraf)
https://galaxy.ansible.com/giner/barman
Apache License 2.0
8 stars 5 forks source link

Manage SSH keys for rsync backups #5

Open jabbors opened 2 years ago

jabbors commented 2 years ago

When setting up rsync backups it would simply the Ansible manifests if the SSH keys could be managed with the same module.

Happy to wrap up a proposal PR if it would be an acceptable contribution.

giner commented 2 years ago

Why would you want rsync based backup?

jabbors commented 2 years ago

There are 2 reasons and both are due to the size of the database (>1TB)

1) pg_basebackup is single threaded so it takes a long time to perform a backup. In slower I/O and network setups it might not even be possible to complete a backup within 24 hours, assuming you take a nightly backup.

In our tests a 250G database took ~30 minutes to complete with streaming backup vs ~15 minutes with rsync and 4 jobs.

2) It becomes expensive in terms of storage as you can't take advantage of deduplication.

giner commented 2 years ago

I see. How do you see this being implemented?

jabbors commented 2 years ago

Something like this

barman_ssh_key:
  name: id_ed25519
  public: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI**************************************************ab
  private: <encrypted base64 encoded value>

barman_ssh_authorized_keys:
  - key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI**************************************************cd
    state: present
  - key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI**************************************************ef
    state: present

With two simple tasks

- name: set authorized keys for barman user
  authorized_key:
    state: '{{ item.state }}'
    user: 'barman'
    key: '{{ item.key }}'
  with_items: '{{ barman_ssh_authorized_keys }}'

- name: configure private key for barman user
  copy:
    dest: '/var/lib/barman/.ssh/{{ barman_ssh_key.name }}'
    content: '{{ barman_ssh_key.private | b64decode }}'
    mode: 0600
    owner: barman
    group: barman
  when: barman_ssh_key.private is defined
giner commented 2 years ago

What are barman_ssh_authorized_keys for?

jabbors commented 2 years ago

Those are the keys to trust when WAL files are uploaded to the barman server using barman-wal-archive command.

giner commented 2 years ago

I think I understand the motivation however unless rsync-based backup is implemented as a full-fledged feature of this Ansible role barman_ssh_key looks as something that should be handled outside of the role.

As for barman_ssh_authorized_keys - sounds like a very specific use-case with no direct relations to Barman.

At the same time these two are simple to be in a playbook itself. It could make sense to create sample playbooks setup ssh private key and configures backup_method with ssh_command. What do you think?

jabbors commented 2 years ago

SSH key management should be common knowledge by Ansible users so I don't think a sample playbook is needed for that.

I opened this issue as it would make the life a bit easier to manage the keys when a rsync based backup is chosen. As a matter of fact we have implemented it as a new role in our Ansible management repo. As it's a different role (or playbook), I already managed to forgot applying updates (SSH keys) when we added more backup targets (using rsync) to our barman backup server and had to investigate why backups didn't work.

You mentioned there are no direct relations to barman but I would claim the opposite. It's a very essential part for rsync backups that barman is configured with SSH access to the database servers as well as trusting specific servers so they can upload WAL files. In your defense, there are many ways to configure SSH access so I can agree that it would be better managed outside this role. The role could otherwise end up becoming a SSH access management role as well 😄