Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manage SSH keys for rsync backups #5

Open
jabbors opened this issue May 11, 2022 · 8 comments
Open

Manage SSH keys for rsync backups #5

jabbors opened this issue May 11, 2022 · 8 comments

Comments

@jabbors
Copy link
Contributor

jabbors commented May 11, 2022

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
Copy link
Owner

giner commented May 11, 2022

Why would you want rsync based backup?

@jabbors
Copy link
Contributor Author

jabbors commented May 12, 2022

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.

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

@giner
Copy link
Owner

giner commented May 17, 2022

I see. How do you see this being implemented?

@jabbors
Copy link
Contributor Author

jabbors commented May 18, 2022

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
Copy link
Owner

giner commented May 27, 2022

What are barman_ssh_authorized_keys for?

@jabbors
Copy link
Contributor Author

jabbors commented May 28, 2022

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

@giner
Copy link
Owner

giner commented May 28, 2022

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
Copy link
Contributor Author

jabbors commented May 30, 2022

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 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants