Search results

Apologies, I am not familiar with your processes. I thought when @Stoiko Ivanov mentioned "is more likely to get merged with upstream" that it was still in a test phase. We have applied the fix and thank you for this community which helped bring closure to this issue.

Just wondering if the fixes has been added to the upstream yet or the estimated time on the merge?

Last week, I deleted the contents of my offsite NFS store on a NAS which proxmox syncs to and re-added the store in proxmox which recreates the .chunks etc . I have been syncing the backups to this location since and so far no scheduled backup errors. Strange indeed. I will let you know if...

My backups worked last night (no other sync jobs were running at the time). Will see how things go after a few days then will let the sync jobs run (basically backing up to a remote nas)

On target, thank you! We can see more discussion relating to the issue one level higher https://lists.proxmox.com/pipermail/pbs-devel/2022-July/

@mira I will stop all other jobs from running at the same time (sync jobs, GC cleanup) and let you know how it goes. I have jobs running all the time syncing to a qnap nas as it is going too slow. Edit: I can confirm the scheduled backup worked now that the proxmox backup server is not running...

crickets

We are still having the same issue - Proxmox, could you please throw some more resources at this as there a few clients with this issue.

I have to manually run jobs as I can't rely on the schedule. Although it 'should not make a difference' we are getting the error since the upgrade. Please don't take offense to this, we just need it looked into. Interesting enough, when I went to run a manual job this time, it failed. I noticed...

I have a similar issue - once I perform a proxmox backup, I get a similar kernel crash. After this update too..

maybe not related, we rolled back to 6.4 after having multipath issues with pve7. This was not clear to begin with as the symptoms was the VM's went into a panic and stopped responding requiring reboots and volume repairs.

Hi Everyone, I believe we got to the bottom of it, however, it raises a few questions to Proxmox to provide a fix in version 7. vzdump was not the issue, it was a symptom of a larger issue with multipath. Initially we were able to get the backups to appear to work when we throttled the...

Since updating to Proxmox version 7, we have not been able to backup a single VM (Production affected) The issue is that VZDUMP slows down and VM's on the Proxmox nodes become unresponsive. I was able to get 450MB transfer using rsync to the VM locally to test access to the vm drives which go...