This usually happens if old backup jobs didn’t release their locks. Try killing the stuck PID processes and then remove any leftover lock files in /etc/webmin/virtual-server/domains/ before running the backup again.
If you go to “System Settings ⇾ Virtualmin Configuration: Backup and restore” and set “Time to wait if maximum is exceeded” to “Halt immediately,” does it change anything?
I just checked and validated it. I’m running a backup test—it can take up to 6 hours. Sometimes it crashes after 4 hours, and sometimes after just 15 minutes.
No, it didn’t work :
. terminé en 13 minutes, 57 secondes
Impossible de verrouiller le fichier /etc/webmin/virtual-server/domains/17165433421494803 après 5 minutes. La dernière erreur était : Locked by PID 1492333
I restore the setting so as not to forget, in “System Settings ⇾ Virtualmin Configuration: Backup and restore”.
NO NO NO … those are the config files for all your Virtualmin Virtual Servers !!!
3 Likes
Are you running out of disk? Do you have overlapping backups? I’ve set up a notification email if a backup fails. There has to be a reason it fails.
Espace disque local 985.84 Gio utilisé / 2.6 Tio libre / 3.56 Tio total
The disk is correct (it’s two disks in raid)
I only have one backup in /backup/2025-09-07. It dates back to the morning of September 7, just before the package updates, as well as the Webmin and Virtualmin updates, all done at the same time. I often delete old backups and keep only one.
I restored the /tmp/.webmin folder to its default state and restarted Webmin. A new backup is now running; it will probably take anywhere from 15 minutes to 6 hours. My failure notification emails are still enabled. I’ve already shown the error line above several times.
Here is the result of the last backup: 
.. terminé en 14 minutes, 8 secondes
Impossible de verrouiller le fichier /etc/webmin/virtual-server/domains/17165433421494803 après 5 minutes. La dernière erreur était : Locked by PID 2190310
I unchecked an option in the backup settings (shown in image #4: “Transfer each virtual server after its backup”), and a backup is still running. It has been running for 5 hours now without any backup failure. It should finish in 1 or 2 hours if no error occurs.
In image N°4 : “Transfer each virtual server after its backup” in french “Transférer chaque serveur virtuel après sa sauvegarde”.
Oh no, finally he failed :
La sauvegarde a échoué. Voir ci-dessus le compte-rendu pour en déterminer la raison. Temps de sauvegarde totale a été 5 heures, 06:26 minutes.
…
Copie des fichiers de configuration Procmail et SpamAssassin
.. fait!.. terminé en 13 secondes
Impossible de verrouiller le fichier /etc/webmin/virtual-server/domains/170198173539122 après 5 minutes. La dernière erreur était : Locked by PID 2427654
Just a thought .. work out which domain id 170198173539122 actually is by name, you can do this by viewing the contents of /etc/webmin/virtual-server/domains/170198173539122 and searching for dom= then just backup that domain up to see if the error continues, it’s also worth finding what locked the domain by finding out what was/is running on PID 2427654.
How much data is in the backups ? as 6 hours indicates these backups are huge, I backup about 50gb when I do a full backup and that is normally around 45 minutes
For the domain name linked to the id 170198173539122, I made a backup only on this domain name, here is the result:
La sauvegarde est achevée. La taille finale est 21.28 kio Temps de sauvegarde totale a été 00 minutes, 02 secondes.
…
Enregistrement de restrictions de répertoire FTP ..
.. fait!Enregistrement des paramètres DKIM .. .. fait! Enregistrement des paramètres de greylisting .. .. fait! Sauvegarder la configuration taux mail limitation .. .. pas installé Enregistrement de Configuration du serveur de messagerie .. .. fait!.. fait!
Création de l’archive de sauvegarde finale en cours ..
.. fait!8 Paramètres de configuration Virtualmin sauvegardés avec succès.
My backup is usually around 70GB. A few months ago, it used to take about 1h30 to back up 45GB, but now it takes around 6 hours for 70GB. It’s true that this is very slow. The storage is not SSD, it’s HDD. Maybe it’s because of the profile pictures, there are a lot of them.
Should I run the backup domain by domain (one at a time) to see which one is causing the issue?
That is worth a try it may shed some light on where the error is occurring
Ah, I just found a problem, let me explain:
-
In the Backup settings, there is a section “servers to back up” with 2 fields and two arrows. Since 1 year, I added all the domains to be backed up in the left field, and ignored the right field. So here, I selected only one domain on the left to test it, and on the right I put all the domains not to be backed up.
Result after the backup: it backs up all the “virtualmin…” but it does not back up the websites (the site, the /home/domain directory). -
Now, by inverting: you put the content of the right field to the left and the left one to the right, and you select “Only the selection”.
Result after the backup: it saves the virtualmin… but also the websites (content of /home/domain).
Do you know if the problem could come from this?
I don’t think so, but it could be just backup each domain on it’s own and see if any errors occur
Do these domains have WordPress sites on them?
Also, on the backup schedule page does it back up all features under the “Features and settings” section? If so, does it help to select “Only those selected below…” and exclude WP Workbench?
There are 89 domains in total. There is no WordPress installed with Webmin/Virtualmin. However, there are 2 sites running WordPress, but they were installed manually by uploading via FTP. These WordPress installations are old and have been there for a long time.
I tested with a small number of domains, for example by ignoring the domains that have large image folders — such as 80,000 profile pictures, listings, or similar files on different sites. It seems that the backup works when those domains are ignored. The backup fails if a large image folder is selected.