Search results

Yes, very true, using push backups as an attack vector is not the more likely scenario to occur. But just because something is unlikely doesn't mean attempts to mitigate the vulnerability shouldnt be taken. Defense in depth. I would also like to point out that Veeam uses a pull configuration. I...

Important to me, security is usually worth very little to others. This may be a misjudgment of the majority of people on here.

I would like to have a constructive conversation with both the Proxmox team and the community about the conceptual backup strategy that this product is currently following. This may not be the best place for such a topic, but I wanted it to be in the sight of the community rather than just a...

It seems the cpu change to host has made the biggest improvement. Backup jobs now run at 500-800Mbit/s.

The backup job still ran at its normal time, I just cant run it manually. # pveversion -v proxmox-ve: 7.1-1 (running kernel: 5.13.19-2-pve) pve-manager: 7.1-9 (running version: 7.1-9/0740a2bc) pve-kernel-helper: 7.1-8 pve-kernel-5.13: 7.1-6 pve-kernel-5.13.19-3-pve: 5.13.19-6...

I have tried clearing my browser cache, restarting my computer, and recreating the backup tasks. Same error

I did an upgrade, but I was already on 7.1.

Well I guess I won't be running any backups... next-run: property is not defined in schema and the schema does not allow additional properties Don't know what that even means.

After some modification, this is my benchmark (PBS still in a VM): I'm about to run some backups to see what the overall speed is, but this is looking much better. Pretty sure it was the cpu switch from kvm to host. Uploaded 365 chunks in 5 seconds. Time per request: 13784 microseconds. TLS...

I'm just now thinking about this, but my PBS vm sits on a shared NVMe VM storage. Couldn't I write the backups locally to disk, then use cron to move the resulting local backup files to a SMB share? I didn't actually look at the file system to see if PBS stores the VM backups in millions of...

Ah that makes sense, I will move everything over to that. I am not running a cluster.

The cpu was set to default kvm64. Is there any downside to running the host option? Why is it not the default?

Seems reasonable. I just don't know why there isn't a more compatible solution to these older backup architectures. Why not include an additional feature in PBS to conduct backups similar to veeam? It would give people the flexibility to do network based backups, and make PBS easier to implement...

# grep -m1 -o aes /proc/cpuinfo aes

I see the benefits there. And if I really cared about the fine-grained recovery options I'd probably consider it. But to be honest, I really only care about something big breaking and having a couple restore points. Any important application data on the VMs is all stored directly on a NAS...

Well, I guess I'll have to move back to cron job for vzdump. That at least transfers at full speed. All I'm saying is that veeam does a decent job at incremental backups, and doesn't use this method. In order for PBS to work for me, I'd have to go and buy a ton of local storage for PBS and I...

Ah, that sucks. I think I just confirmed that, I tried transfering a 10GB file full of random data from PBS through the SMB share to the Truenas VM and was able to sustain 330-450MB/s. Is there anyway to force backup jobs to pull large images instead? Any idea why proxmox would stray from...

That is extremely disappointing, considering Veeam had full support for network shares and at high speeds. I have done plenty of SMB data transfers from other debian VMs and can easily saturate the disk write speeds, why is PBS (which is just debian) limited here?

Uploaded 66 chunks in 5 seconds. Time per request: 82194 microseconds. TLS speed: 51.03 MB/s SHA256 speed: 273.01 MB/s Compression speed: 552.43 MB/s Decompress speed: 972.39 MB/s AES256/GCM speed: 82.09 MB/s Verify speed: 136.66 MB/s ┌───────────────────────────────────┬───────────────────┐ │...