Ongoing problems with back-ups

For the last two weeks the same weekly back-up has failed, with similar but slightly different failure messages:

Failed to open /home/USER/.backup/EXAMPLE.net_mail_users.webmintmp.4198 : No such file or directory at /usr/libexec/webmin/web-lib-funcs.pl line 1445, <readout12> line 1. Failed to open /home/USER/.backup/EXAMPLE.net_mysql for writing : No such file or directory

I didn't seek support after last week's error in case this week's back-up worked, but it failed again.

I vaguely recall a similar error being the result of the user's quota being close to max, but this user is nowhere near his quota limit.

Where can I look for more information on why this might be happening?

Status: 
Closed (fixed)

Comments

Howdy -- hmm, Jamie may have some more ideas as to what's causing that, but one thought -- are there by chance more than one backup running at the same time, that would be backing up that particular domain?

Also, check if your system is low on disk space or on inodes - this might prevent directories like .backup from being created.

Thanks for your replies.

Eric, yes, as per our previous discussions about back-up issues, there are multiple back-ups running at the same time. Most are backing up other virtual servers, but there is also the fact that the incremental daily back-up of this virtual server is happening at the same time ... because, you know, I went with the "simple schedule" for the reasons I've outlined before -- i.e., keeping a manual record of multiple "complex schedules" would be a pain. However, I have increased the time for the back-ups to wait, and this back-up does start running after waiting, and then fails. All of the other back-ups succeed.

Jamie, df -i shows only 13% inode use on this partition.

So should I make the effort to stagger these back-ups pending the feature discussed in issue 55540?

Ah yes that all does ring a bell -- sorry, a lot of requests come through here, it can be tough to remember who is doing what :-)

Just to clarify, the thing that I might try to avoid is having this specific domain being backed up twice at the same time.

Are you saying it's possible that two backups of this domain could be occurring?

Of course, if that's causing an issue we may need to add some locking to prevent that. But in the short term staggering it a bit more might help.

I suspect that something is going wrong with Virtualmin's locking that is causing two concurrent backups (which should work) to collide with each other.

Are you backing up to a single file, or one file for each domain?

Eric, I would only wonder if you'd remember me and my last support ticket because I'm a pain, not because I'm special.

Yes, daily and weekly back-ups -- both on "simple schedules" -- happen at the same time.

I don't want to re-hash ticket 55540, but I'm the kind of person who generally prefers the "complex" choice over the "simple" choice, but I've been going simple on the back-up schedules because the complex route is too complex. Making sure I go the complex route to avoid Virtualmin tripping over back-ups using simple schedules is too time-consuming. I hope that Jamie's suggested enhancement will be available soon.

Jamie, one file for each domain.

I dug into this some more, and I found a bug in the code whereby multiple concurrent backups for the same domain could collide in a way that triggers this error. It will be fixed in the next Virtualmin release though.

OK, great, thanks.

Status: Fixed ยป Closed (fixed)

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