Proxmox Backup Server and Client
- Thread starter phs
- Start date
This was just refactored a day ago: https://git.proxmox.com/?p=proxmox-backup.git;a=shortlog;h=a3016d6583659b491fe24f13db9064c11351190d
That's a good example why it makes not much sense to reason/comment about the state or code from a project under heavy development, if not involved deeply in it.
Anyway, let's all please just wait for an official announcement/release where all questions will be answered, giving the developers now more time to actually develop
I Just wanted to make clear that this Project isen't ready for evaluation as i have already been asked about that.
The file bin/proxmox-backup-client.rs is still 2500 lines long. What has been refactored yesterday is the bin/proxmox-backup-manager.rs
As of this commit from 3h ago:
The file bin/proxmox-backup-client.rs is still 2500 lines long. What has been refactored yesterday is the bin/proxmox-backup-manager.rs
Yes i agree.
Last edited:
I'm sorry i misinterpreted that. To me Production ready and ready for testing/evaluation are very different things.
What i wanted to clear up is that the PBS is not ready for testing / making decisions about using it in the future.
For many Products this evaluation can be done even if the product isent production ready.
For anyone interested in Playing around with the PBS. Here is a script i made to automatically compile and install the PBS in a Debian 10 container. https://git.lastassault.de/speatzle/pbs-install-script
You can, but all is under heavy development and most will not work. I really suggest to wait for the first official beta release.
hello any Estimated Time of Arrival planned for this feature (at least a target)?
couple of weeks , months , 2020, 2021 ?
thanks
couple of weeks , months , 2020, 2021 ?
thanks
It needs another separate server which has several disadvantages.
Why not extend the existing replication mechanismen to be able to retain old versions based on a plan like znapzend? This would combine backup with availablility. Then at any point it would be possible to:
1) Have a perfect backup history of VMs without wasting to much extra space (compared to extra server or vzdump).
2) Revert the VM to an snaphost in case something went wrong without ANY "restore" operation
3) In case of failure of one proxmox server, it would be possible to assign the master role to any other replication target (like now in replication).
As any proxmox server can be a backup server and able to tune VMs and containers, there is no single point of failure concerning a backup server and more important NO expensive "restore" operation. Also the server roles are can be switched at any time, where a dedicated backup server is a special thing.
As there is no dedicated backup server the processing power of all proxmox servers can be used to run VMs in, whereas a backup server would be idle at most times. Obviously it would be possible to use one of the proxmox servers for just receiving backups (and not running any VMs) which would come close the the backup-only-server, but this solution offers extra flexiblilty to use all of the existing processing power.
E.g. A simple setup would be to have three servers, which run each running three VMs which gets replicated to the other two server. Then at any time, there are two copies of the VMs at the other server and in case ot failure of the server, the master rule for its three VMs gets switched to another proxmox server (which already has a replicated copy). Also at any time it would be possible to revert to older versions (snapshots) of the VMs.
Why not extend the existing replication mechanismen to be able to retain old versions based on a plan like znapzend? This would combine backup with availablility. Then at any point it would be possible to:
1) Have a perfect backup history of VMs without wasting to much extra space (compared to extra server or vzdump).
2) Revert the VM to an snaphost in case something went wrong without ANY "restore" operation
3) In case of failure of one proxmox server, it would be possible to assign the master role to any other replication target (like now in replication).
As any proxmox server can be a backup server and able to tune VMs and containers, there is no single point of failure concerning a backup server and more important NO expensive "restore" operation. Also the server roles are can be switched at any time, where a dedicated backup server is a special thing.
As there is no dedicated backup server the processing power of all proxmox servers can be used to run VMs in, whereas a backup server would be idle at most times. Obviously it would be possible to use one of the proxmox servers for just receiving backups (and not running any VMs) which would come close the the backup-only-server, but this solution offers extra flexiblilty to use all of the existing processing power.
E.g. A simple setup would be to have three servers, which run each running three VMs which gets replicated to the other two server. Then at any time, there are two copies of the VMs at the other server and in case ot failure of the server, the master rule for its three VMs gets switched to another proxmox server (which already has a replicated copy). Also at any time it would be possible to revert to older versions (snapshots) of the VMs.
Last edited:
As said various times in this and other threads: You can install it on a Proxmox VE too, documented here:
https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve
Because this is a much more general approach, independent of any storage snapshot technology. It gives our users the freedom to use the filesystem/storage-technology they want and suits their need best.
If you want availability with whole hosts failing, use ceph. Having backups separated from the live data is a feature.
PBS is fully deduplicated, backups are sent incremental and compressed - this saves a lot of space. Having an explicit server for backups is normally a good strategy, as said this is seen as a feature.
If restore can go wrong so can rollback, so not sure how that argument would work. Restores should be frequently tested in any backup system, having the data back'd up is only one part of the story.
You can still use replication if you use Proxmox Backup Server, so this still works.
Yeah, and if the cluster fails you have nothing in your hands, cannot get critical VMs/CTs up on another cluster, ...
You can efficiently sync Proxmox Backup Servers to remotes automatically, avoiding single points of failure.
And as said, any Proxmox VE can also be a Proxmox Backup Server, if you really want. I'd still suggest doing a separate or even off-site remote which the PVE nodes use only a user with limited Permissions, so that if you're PVE host would be taken over they cannot simply delete all backups/snapshots/...
Snapshots are not a backup strategy on their own, they can be worked into that somehow but it could be never as universal and feature full as the approach we went for Proxmox Backup Server.
All in all, you sound like you just want to continue using the replication, it provides already the things you ask us to turn the Proxmox Backup Server into, so...