I’ve been experiencing this issue with scheduled incremental backups. Occasionally, I will receive the following error. I have replaced my actual domain in question with “mysite” for example purpose.
Failed to lock file /home/mysite.net/domains/mysite.mysite.com/.backup after 5 minutes. Last error was : Locked by PID 480395
When I check for that directory (.backup), it doesn’t exist in that location whenever I look for it. Yes, I realise its a hidden directory and I checked via ls -a.
Sometimes the PID is different and by the time I go and check for that same PID, it doesn’t exist either.
So this .backup directly seemingly gets created and then held up by another process and the backup fails, then the .backup directory is removed by whatever created it but I’ve been unable to figure it out.
The only pattern is that it’s happening at 12:00AM every day just once (see screenshot). Every other incremental backup for that day works fine (I have it set to hourly).
|OS type and version
What Virtualmin and Webmin version is this?
@Jamie, perhaps something else is happening on the server during that time that prevents scheduled backups to function in expected way? If so, is this expected?
@kylegp If you check regular Cron jobs and
Webmin ⇾ Webmin Configuration: Webmin Scheduled Functions are there any jobs that would intersect with scheduled backups?
Also, are there any jobs that could intersect on
Backup and Restore ⇾ Scheduled Backups page?
I think I have found the issue.
I have a full backup running at midnight every day and incremental backups every hour.
I believe the full backup begins at midnight and the incremental backup also tries to start up but fails because the full backup is already in progress.
How can I best resolve this while retaining my desired settings? Would it be best to set the incremental backup to backup hourly except midnight under a complex schedule?
I would just shifted the schedule for full and incremental backups, for half an hour to either. Also, I wouldn’t run incremental backups on the hour (or hours, depending how slow daily backup is) when the full backup is running.
Anyway this is now resolved. The issue was ultimately causes by two schedules trying to run at the same time.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.