Not Proxmox error directly, but I have a problem with a vm. I have a Kerio Mailserver Linux-software on it, with about 15 users, that I have had for years on dedicated hardware. Last year, I have had it in a lxc with redundant ssd on the host, server hw-card and enterprise SSD-disks. One day, a single user had problem logging in, but cpu, memory and every other aspect looked good. Other users had no problems. There had been a loop in the mail system (delivering - or trying to - deliver a high number of emails between the mailserver and another external server.
During trying to figure out how to solve it for this user, I figured out to create a new vm since the Kerio locked up all the time (only for this user). Then I found out I could never access this users inbox folder. If I tried to go into the mailbox folder for this particular user from shell, it just stood there for an hour and I never got to the content (if I specified a specific file by full name and didn't use auto-complete, it worked). Same happened with using tar or rsync to try to transfer the folder. So I reverted to a Proxmox backup instead (before the incident and lost quite a few mails) and after hours restoring to another host, it was ok and user could log in. Folder itself is about 4.4GB.
Now, the problem is that backup - both Kerios internal (basically a gzip of new/changes files) - and Proxmox - takes about 14 hours (lxc container). The disk size is 320 GB. Other vm with far larger disks takes 5 minutes. The backup of this machine seems to bring down several other machines and cause issues each day. As long as I exclude this machine from backup, all is good and all machines - including Kerio - works.
I assume all the issues are due to the massive amount of small files. I have switched the container to different Proxmox-server (to rule out local problem on the host-machine), but same slowness. After the restore, I can look into the folder with no issues and Kerio works perfectly. Now it is only backup of this machines that takes forever. Not only Proxmox-backup - even the internal Kerio backup. Kerio works faster when doing only changed files and does the job in 6-7-8 hours by now.
Here is last nights backup, after standing there for 4 hours the progress as pretty slim - it did complete another day, then it took about 14 hours and finished backup size was 185 GB (tar.zst).
INFO: Starting Backup of VM 115 (lxc)
INFO: Backup started at 2020-10-08 06:10:33
INFO: status = running
INFO: CT Name: ***
INFO: including mount point rootfs ('/') in backup
INFO: found old vzdump snapshot (force removal)
Logical volume "snap_vm-115-disk-0_vzdump" successfully removed
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
Logical volume "snap_vm-115-disk-0_vzdump" created.
INFO: creating vzdump archive '/mnt/pve/***/dump/vzdump-lxc-115-2020_10_08-06_10_33.tar.zst'
Any ideas on what I can do? Is there a OS-limit on number of files? I see Kerio store all inbox files in single folder per user.
During trying to figure out how to solve it for this user, I figured out to create a new vm since the Kerio locked up all the time (only for this user). Then I found out I could never access this users inbox folder. If I tried to go into the mailbox folder for this particular user from shell, it just stood there for an hour and I never got to the content (if I specified a specific file by full name and didn't use auto-complete, it worked). Same happened with using tar or rsync to try to transfer the folder. So I reverted to a Proxmox backup instead (before the incident and lost quite a few mails) and after hours restoring to another host, it was ok and user could log in. Folder itself is about 4.4GB.
Now, the problem is that backup - both Kerios internal (basically a gzip of new/changes files) - and Proxmox - takes about 14 hours (lxc container). The disk size is 320 GB. Other vm with far larger disks takes 5 minutes. The backup of this machine seems to bring down several other machines and cause issues each day. As long as I exclude this machine from backup, all is good and all machines - including Kerio - works.
I assume all the issues are due to the massive amount of small files. I have switched the container to different Proxmox-server (to rule out local problem on the host-machine), but same slowness. After the restore, I can look into the folder with no issues and Kerio works perfectly. Now it is only backup of this machines that takes forever. Not only Proxmox-backup - even the internal Kerio backup. Kerio works faster when doing only changed files and does the job in 6-7-8 hours by now.
Here is last nights backup, after standing there for 4 hours the progress as pretty slim - it did complete another day, then it took about 14 hours and finished backup size was 185 GB (tar.zst).
INFO: Starting Backup of VM 115 (lxc)
INFO: Backup started at 2020-10-08 06:10:33
INFO: status = running
INFO: CT Name: ***
INFO: including mount point rootfs ('/') in backup
INFO: found old vzdump snapshot (force removal)
Logical volume "snap_vm-115-disk-0_vzdump" successfully removed
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
Logical volume "snap_vm-115-disk-0_vzdump" created.
INFO: creating vzdump archive '/mnt/pve/***/dump/vzdump-lxc-115-2020_10_08-06_10_33.tar.zst'
Any ideas on what I can do? Is there a OS-limit on number of files? I see Kerio store all inbox files in single folder per user.
Last edited:
