Proxmox Backup Server (beta)
- Thread starter martin
- Start date
We made a QEMU block-driver implementation for the backup server to access backed up images read only. One should be able to use that and NBD (there's no BUSE (block device in user space) yet) and access the data. But this was done pretty recently, a deeper integration into PVE has still to be done - but QEMU in version 5.0.0.-9 should already have it included.
See: https://forum.proxmox.com/threads/datastore-recovery.72835/#post-325491
You effectively just re-add the datastore path (currently through editing the config, that will be improved). A more elaborate "config backup" of the host like Proxmox Mailgateway has it could be elaborated.
A free, full featured, no strings attached version will always be available.
The project is licensed under AGPLv3, just like the Proxmox VE and the Mailgateway, and that will stay that way. What Proxmox, the company, will offer is support subscriptions and access to a future enterprise repository (which will not have any extra "paid only" feature, everything our product can possibly offer is available to all users. But it will be stabler, as it's longer and more extensively tested than our already well tested no-subscription repository).
@t.lamprecht , does it make any difference to use compression on jobs created on PVE when PBS is the target? Am I right to assume that enabling it would increase load on both client and server while lowering network bw usage?
For now the vzdump compression parameter has no effect if Proxmox Backup Server is the target, it's always compressed using zstd. But, disabling compression would be supported from the server, so we may allow to set this. IMHO much of the time it's just better to use it, zstd is efficient and fast after all.
It would normally only increase the load on the client, the server know if it is but it does just take the data chunk as is in both cases. With using it, network load and target storage space may be lowered.
Ok. My mistake. You've right. I thought that you are using ssh, which was dictated by the fingerprint message. I apologize for the stupid suggestion
PS
When do you plan using a web UI of PBS to manage the clients? Is it in your roadmap at all? That will be a huge advantage.
I mean something like in Avamar or Netbackup - client management tab in PBS UI. It could look like VM's or containers view in PVE.
At least for now (stable), something like this isn't actively planned. A daemon mode could make sense, it would allow a few things (like watching directories for change, configuring a schedule, ...?) so we may think about that - but no promise here yet
After booting this little Intel NUC today, there was no such process. So seems to be have been left over from backup process.
Plugging in the USB disk was seamless:
- Before mounting: "?" on PBS storage in PVE, PBS showed error not finding the chunks. Both fair enough.
- After mounting: PBS storage shown with contents just fine in PVE and PBS.
So except that little lock thing, it seems it can work well with removable storage. Last time I just sent the process a TERM signal. Next time I may just stop the backup server service and see what happens. Of course always just after all manually started backup jobs have completed.
I understand that this is just a use case for lab setups, so not major focus.
Found something interesting and I bet there is a good explanation for it:
1) When I re-run a backup shop of running VMs directly after I ran it, then the backup is almost immediate, as I expected.
2) When however the VMs are switched off, it transfers the whole VM image again, obviously checking for differences to backup on the PBS side.
Ah, and I already learned about the background: That is the dirty bitmap thing in qemu:
https://qemu.readthedocs.io/en/latest/interop/bitmaps.html
However, I am using qcow2 images and there those dirty bitmaps are supposed to be persistent on close?
So wouldn't this work on switched off VMs as well? What am I missing here?
1) When I re-run a backup shop of running VMs directly after I ran it, then the backup is almost immediate, as I expected.
2) When however the VMs are switched off, it transfers the whole VM image again, obviously checking for differences to backup on the PBS side.
INFO: status: 3% (668.0 MiB of 20.0 GiB), duration 3, read: 222.7 MiB/s, write: 222.7 MiB/s
INFO: status: 7% (1.5 GiB of 20.0 GiB), duration 6, read: 290.7 MiB/s, write: 290.7 MiB/s
INFO: status: 10% (2.2 GiB of 20.0 GiB), duration 9, read: 233.3 MiB/s, write: 233.3 MiB/s
INFO: status: 14% (3.0 GiB of 20.0 GiB), duration 12, read: 264.0 MiB/s, write: 264.0 MiB/s
INFO: status: 18% (3.8 GiB of 20.0 GiB), duration 15, read: 284.0 MiB/s, write: 284.0 MiB/s
INFO: status: 22% (4.6 GiB of 20.0 GiB), duration 18, read: 261.3 MiB/s, write: 261.3 MiB/s
INFO: status: 27% (5.6 GiB of 20.0 GiB), duration 21, read: 345.3 MiB/s, write: 345.3 MiB/sAh, and I already learned about the background: That is the dirty bitmap thing in qemu:
https://qemu.readthedocs.io/en/latest/interop/bitmaps.html
However, I am using qcow2 images and there those dirty bitmaps are supposed to be persistent on close?
So wouldn't this work on switched off VMs as well? What am I missing here?
We explicitly do not enable this for safety reasons. https://forum.proxmox.com/threads/backup-vm-pve-to-pbs-how-to-enable-incremental.72843/#post-325682 Maybe still optimized, but we want to play this safe for now - also, even with shut down backup's nothing but the incremental delta is sent over the network.
Thanks. Fair enough. If another question regarding that comes up, I ask it in that other thread.
Thomas, this seems not to be the case - I've tested with the .deb from http://download.proxmox.com/debian/pbs/dists/buster/pbstest/binary-amd64/ and its dynamic linked.
Do you have any ETA for the static binary?
This is fantastic! Thank you to the whole team at Proxmox! You guys are rock stars!
So I may have promised a bit to much and to early here. While yes, the whole rust code is statically linked and needs no extra dependency, the bindings to certain libraries like zstd, openssl, libfuse3 are still dynamically linked.
For now, we found three extra libraries the client depends on even if none of their symbols are in use (libsystemd, libudev, libpam) - they are only in use in the server. It seems the compiler gets confused here, we'll see if we can work around this so that those will be dropped.
The remaining libraries should be available everywhere, even on non-systemd distros. I'll try to get some time to experiment building a fully static binary with musl. Sorry for the confusion here, not sure how I could forget the bindings we used.
Thanks, you help is much appreciated. We failed to build the proxmox-backup from source (error[E0433]: failed to resolve: use of undeclared type or module ), so the static binary is our last hope for testing PSB with our servers running all CentOS ;-)
You need to adapt the Cargo.toml a bit if you cannot install the build dependencies from our development package repo.
https://git.proxmox.com/?p=proxmox-...7;hb=37e53b4c072f207f17496bd225a462c79ee059e0
Orient yourself on the commented out "#proxmox { git =..." line, for the url use "git://git.proxmox.com/git/proxmox.git" (and respective) instead of version you can also use "commit = sha-id".
See the "rust" section in https://git.proxmox.com/?o=age for available repositories, you'd at least need proxmox, pxar and pathpatterns.
Hmm, but CentOS should have the following libraries available, so the binary should still work - at least if CentOS doesn't ship other so-versions of the libraries.
Code:
# readelf -d /usr/bin/proxmox-backup-client
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libacl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libsystemd.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0]
0x0000000000000001 (NEEDED) Shared library: [libzstd.so.1]
0x0000000000000001 (NEEDED) Shared library: [libudev.so.1]
0x0000000000000001 (NEEDED) Shared library: [libfuse3.so.3]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libuuid.so.1]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]