Question about Feature Replication

wire2hire

Well-Known Member
Oct 20, 2020
55
6
48
41
Hey,

i would ask, give it a Plan, that the Proxmox Backup Server can be used for replication? I know it gives zfs replication but not all have zfs . Veeam ( roadmap) and nakivo , makes replication . What is with this solid product pbs? From backup replication to any storage , so that running vms have no impact, and underlaying storange are not importent (zfs), i think that where a nice feature.

Greets
 
hey, thanks for your answer. offside syn to another pbs, i know and its realy good. I mean replication to other pve nodes without zfs and from backup sources.
 
I mean replication to other pve nodes without zfs and from backup sources.
Just restore the VM of your choice on the other node. The storage type on the other node does not have to be the same as it was on the source. The result is basically a "replicated" VM from/to different filesystems ;-)

The are CLI tools available, so you can script the whole process to automate it - if that's what you need.
 
  • Like
Reactions: Johannes S
PBS has also a live-restore feature so you can start the VM without waiting for a completion of the restore.
 
  • Like
Reactions: UdoB
Just restore the VM of your choice on the other node. The storage type on the other node does not have to be the same as it was on the source. The result is basically a "replicated" VM from/to different filesystems ;-)

The are CLI tools available, so you can script the whole process to automate it - if that's what you need.
just restored, is are a restore, not a continous replicated. Or can i script the restore first full and then incremental per cli? Live restore are good, but not for all.

2 pve nodes with iscsi / nfs storage --- backup to a pbs , when one node goes down, i can restore or live-restore. Or i start the replicate , whats sound better, because small downtime. This feature ist no new, like in the vmware world / veeam/ nakivo and many more.
 
"continuous restore" is not implemented. one issue with it is that it can (silently!) break if something/someone modifies the disk that has been restored inbetween restore runs, unless you re-verify it which is very expensive.
 
ok so no continous cdr. but what are with "normal" replication, like restore from backup datasource to a pve node, first full , next incremental? like your zfs replication , where are the first full and then only the changes.
 
ok so no continous cdr. but what are with "normal" replication, like restore from backup datasource to a pve node, first full , next incremental? like your zfs replication , where are the first full and then only the changes.
I should have been more specific - we do not support "incremental restore" on top of an already restored guest, for the same reason. It is a bit of a similar issue like persistant bitmaps - the blockage is not so much technical (the hurdles there can be overcome), but the associated risk of data loss/corruption due to user error/ignored warnings. But we do have plans for those persistent bitmaps, and we might go down a similar route with incremental restores as well once we've established the semantics.

It's also a lot more complicated to implement for containers than it is for VMs ;)
 
  • Like
Reactions: UdoB
Thanks for the clarification. I look forward to the next versions and will see where the journey takes us! Thank you and your team for really great software and support!
 
  • Like
Reactions: fabian