https://pbs.proxmox.com/docs/managing-remotes.html and https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery are the relevant parts of the manual. Basically the idea is that you wake up the second PBS just for pulling backups from the primary and shut it down afterwards. You configure the permissions, that the PVE nodes are allowed to create and restore but not remove backups on the primary PBS. The secondary PBS is only allowed to pull backups from the primary PBS but not to access the PVE nodes or alter the backups on the primary PBS. And neither the PVE nodes nor the primary PBS are allowed to alter anything on the secondary PBS. Depending on your paranoia level you could even setup a firewall on the secondary PBS (with ufw or good old iptables), that usually nobody except a managment client (e.G. your notebook) can access the secondary PBS since for the pull-sync neither the nodes nor the primary PBS need to access the secondary one. In case of an emergency you would disable the firewall temporray to restore everything.
PBS on desktop pc with SSD or in VM on PVE or not at all?
- Thread starter Rytecbe
- Start date
https://pbs.proxmox.com/docs/managing-remotes.html and https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery are the relevant parts of the manual. Basically the idea is that you wake up the second PBS just for pulling backups from the primary and shut it down afterwards. You configure the permissions, that the PVE nodes are allowed to create and restore but not remove backups on the primary PBS. The secondary PBS is only allowed to pull backups from the primary PBS but not to access the PVE nodes or alter the backups on the primary PBS. And neither the PVE nodes nor the primary PBS are allowed to alter anything on the secondary PBS. Depending on your paranoia level you could even setup a firewall on the secondary PBS (with ufw or good old iptables), that usually nobody except a managment client (e.G. your notebook) can access the secondary PBS since for the pull-sync neither the nodes nor the primary PBS need to access the secondary one. In case of an emergency you would disable the firewall temporray to restore everything.
I've just noticed that you added the following questions to an older post. Comparing dates I can see that then I was already answering to the version before your editing, That's why I didn't notice the update then.
https://pbs.proxmox.com/docs/index.html or PDF version https://pbs.proxmox.com/docs/proxmox-backup.pdf
Yes, really. I've read it myself almost in full
.
Not that I understood nor remember everything, but now I more or less know how it works and I know where to find answers.
My advice is: don't do it. The forum contains a returning series of people's cryings for help on not working GUI. Many of these cases occur to be caused by various so called helper scripts which interfere with the GUI. To make matters worse, they act like a time-bomb (initially all seems OK, but then stops).
This "nag screen" isn't burdensome anyway.
https://pbs.proxmox.com/docs/index.html or PDF version https://pbs.proxmox.com/docs/proxmox-backup.pdf
Yes, really. I've read it myself almost in full
.Not that I understood nor remember everything, but now I more or less know how it works and I know where to find answers.
My advice is: don't do it. The forum contains a returning series of people's cryings for help on not working GUI. Many of these cases occur to be caused by various so called helper scripts which interfere with the GUI. To make matters worse, they act like a time-bomb (initially all seems OK, but then stops).
This "nag screen" isn't burdensome anyway.
I'm not using one, but I have a question: that seems plausible during setup, but during operation? Is ssh-access actually used for a QDev "doing its thing"? If not one could disable it after installation...
My (possibly wrong) understanding was that the QDev is attached to the corosync construct - and corosync is a completely different protocol (than ssh).
Just curious... ;-)
Good question, indeed ssh is needed for communication and migration between cluster nodes (according to https://pve.proxmox.com/wiki/Cluster_Manager#_role_of_ssh_in_proxmox_ve_clusters ) but the documentation says nothing about qdevice.
The source code however (https://github.com/proxmox/pve-cluster/blob/master/src/PVE/CLI/pvecm.pm) shows that the ssh access is needed during the seutp to setup the certificates on the qdevice and nodes of the cluster. I can imagine that in case of a cert renewal (pvecm updatecerts) or other cluster maintenance actions (like qdevice removal) ssh access might be needed again. Maybe one of the developers can chime in on on this? T
I too would expect that the qdevice should work to disable the ssh access after the setup. But I don't want to risk breakage so I'm better safe than sorry and don't mess with it without guidance from a developer
Right now the passwordless ssh access works even after adding the qdevice:
Code:
root@pve-node1:~# ssh root@pve-qnode
Linux pve-qnode 6.12.57+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 10 21:07:57 2025 from 192.168.202.11
root@pve-qnode:~#pve-node1 is one of the two nodes of my two-node cluster, pve-qnode is a small debian vm running on my single-node PVE host (which is not part of the cluster, this is by design, cluster and node serve different purposes).