Open jabbors opened 2 years ago
Why would you want rsync based backup?
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.
I see. How do you see this being implemented?
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
What are barman_ssh_authorized_keys for?
Those are the keys to trust when WAL files are uploaded to the barman server using barman-wal-archive
command.
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?
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 😄
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.