Automated backups result in "A backup to the same destination is already running" error

This error just started happening:

A backup to the same destination is already running with PID 31600

It is reported to the email address that I set up for when there are failed backups. I don't encounter any problems at all when running backups manually.

I was surprised to see that there aren't any search results at all for "a backup to the same destination is already running" so I'm making this ticket as public for now.



What output do you see if you run this command as root from the command line on your server:

crontab -l | grep backup

Do you actually have two backups scheduled to the same destination? Or is the time between backup runs lower than the time is actually takes to complete?

Here is the output of crontab -l | grep backup :

0 4 * * * /etc/webmin/virtual-server/ --id 12750384387272
@hourly /etc/webmin/virtual-server/ --id 12750388197724

There are only two backups set to run and they haven't conflicted before... this is a recent development.

What are the destinations of those two backups?

Also, if you check the backup logs in Virtualmin, how long do they run for? If an hourly run was to last longer than an hour, you would get this error.

pixel_paul's picture
Submitted by pixel_paul on Mon, 11/08/2010 - 04:03 Pro Licensee

I experienced this as of upgrading to Virtualmin 3.82:

Backup failed! See the progress output above for the reason why. Total backup time was 00 minutes, 03 seconds.

Virtual servers that failed :

{list of all virtual servers}

Sent by Virtualmin at: https://servername:10000

A backup to the same destination is already running with PID 21936

These are the two jobs I have set up:

Yes, weekly (on Sunday) Full

Yes, at cron time 0 0 * * 1-6 Incremental

So there is no cross over of backups - its one a day with a full back up starting at midnight Sunday morning, the rest incremental.

Last successful full backup:

31/Oct/2010 00:00 3:26:12 8.85 GB Yes

Last successful Incremental backup:

06/Nov/2010 00:00 20:03 863.79 MB Yes

I upgraded to 3.82 on the 05/Nov/2010 at 10:04:33, so for some reason it looks like the backup ran successfuly at midnight of the 6th, but hung and so failed on the 7th and 8th.

crontab -l | grep backup results in this output:

@weekly /etc/webmin/virtual-server/ 0 0 * * 1-6 /etc/webmin/virtual-server/ --id 1224493658791

Re: #5, There are only two backups and they save to separate destinations:


The "everything" backups are the ones that are failing. They run once a day and, when successful, take about 2 hours to complete.

When you see a failure like this, check the directory /etc/webmin/virtual-server/backuplocks for a .lock file whose name is based on the problem destination. In it should be a PID file for the process that is still running on the backup ..

Removing the .lock file makes it possible for me to do a manual backup, but the daily, automatic backups are still failing.

When an automated backup runs and fails, what process's ID is in that .lock file?

This just happened again and there's actually no .lock file in /etc/webmin/virtual-server/backuplocks

Someone else reported something similar to this recently, and I was finally able to track it down. It turns out there is a bug in the detection of concurrent backups that can falsely trigger this error :-(

The next Virtualmin release (3.83) will fix the bug. Let me know if you'd like to get a patch with a fix sooner ..

Automatically closed -- issue fixed for 2 weeks with no activity.

Re: #13:

Yes, please provide a patch. Thanks! 3.8.3 isn't available yet, so I'm reopening this.

I've attached a diff file for /usr/{share,libexec}/webmin/virtual-server/ to this bug report.

Be sure to run /etc/webmin/restart after applying it.

Thanks! The patch applied successfully:

$ patch -p0 /usr/share/webmin/virtual-server/ < /root/
patching file /usr/share/webmin/virtual-server/
Hunk #1 succeeded at 414 (offset -2 lines).
Hunk #2 succeeded at 432 (offset -2 lines).
Hunk #3 succeeded at 1086 (offset -48 lines).

I'll see soon enough if it works. Running Debian 5 Lenny.

Started getting these recently, i have a full backup on sunday at 2 am and incremental at 2 other days... the total backup time is a couple of hours for the full and a few 10's of mins for the incremental - i do not have duplicates statements in the cron, these happen every time the backup is fired.. i get two backup jobs fired, the first one works the second/other fails - i realise this is not a backup issue but a cron or scheduling issue, the first backup always works, the second always fails.

I have just deleted both the full and the incremental and re-made them. will report back on results.

Sorry that you're having problems with backups!

This particular issue is 6 years old though... is there any chance you could start a new issue, and there, can you show us what you see when going into Backup and Restore -> Scheduled Backups? Thanks!