Feature Request: Enable Pull-Based Replication Mode (similar to Backup Pull)

[MisterDeeds]

Dear Proxmox Team,

I would like to propose a feature enhancement for Proxmox VE's integrated replication system:

Currently, VM and container replication operates exclusively in a push model, where the source node initiates replication and pushes the data to the target node.
I would like to request the implementation of an optional pull-based replication mode, similar to how backup operations can be executed via pull.

Use Case:
In environments with strict security policies, it is common to implement data diodes or one-way network links where production systems are not allowed to initiate outbound connections.
In these setups, only the replication target node (e.g., a backup or disaster recovery node) is allowed to initiate communication.
Having a pull-based replication option would allow Proxmox to be used in such high-security or compliance-sensitive environments without manual workarounds.

Suggestion:

• Allow the replication target node to pull the latest ZFS snapshots or replication data from the source.
• Ideally, integrate it into the existing replication job scheduler with a selectable "pull" or "push" mode.
• Pull operations could authenticate using the same SSH keys or tokens as currently used for cluster communication.

Benefits:

• Increased flexibility for secure and restricted environments.
• Alignment with existing backup pull functionality, making Proxmox behavior more consistent across different data protection features.
• Better support for air-gapped or semi-isolated network architectures.
  

I believe this feature would greatly enhance Proxmox VE's usability in enterprise, government, and highly secure deployments.

Thank you for considering this request!

Best regards,

 

[fabian]

PVE replication only works within a cluster, and a cluster needs two-way communication between all node pairs anyway.. if you want to just replicate ZFS storage, you can already do that with a tool of your choice, including ones that support pulling the snapshots..

 

[MisterDeeds]

PVE replication only works within a cluster, and a cluster needs two-way communication between all node pairs anyway.. if you want to just replicate ZFS storage, you can already do that with a tool of your choice, including ones that support pulling the snapshots..

Dear Fabian,

Thank you for your response and for providing clarification.

I understand that Proxmox replication currently works within a cluster and that two-way communication between nodes is required for this feature. While I appreciate that ZFS storage replication can already be accomplished using third-party tools, my request is to integrate this pull-based replication directly into Proxmox VE, similar to how backup operations currently function. This would streamline the process and reduce the need for external tools, making it easier for administrators to manage replication in highly restricted environments.

The key benefit I am hoping to achieve with this enhancement is ensuring Proxmox can be used in setups with strict security policies, where outbound connections from production systems are prohibited. Having the replication target node initiate the replication request would greatly simplify such configurations and improve the overall flexibility and security of Proxmox VE.

I also believe that integrating this functionality natively would make Proxmox VE more consistent across various data protection features, especially in environments where backup and replication share similar requirements.

Again, thank you for your attention to this matter, and I look forward to seeing how Proxmox VE evolves in future releases.

Best regards,

 

[fabian]

you could also make the inverse argument (and in fact, we frequently got hits when initially implementing PBS syncing) - that push-based replication is safer since you don't have to expose your production systems, just the offsite copy

we can revisit this once we implement external replication between clusters, but I think the initial implementation of that will be push-based, simply because it is less work to do it that way on top of the existing codebase.