Backups Not Running

R

roarkh

Verified User
Joined
Aug 30, 2005
Messages
141
Location
Bellingham, WA
I have a DirectAdmin server that has Reseller Level backup jobs scheduled to run nightly, for some reason they have not run two nights in a row now even though they all show up in the list of "Current Backup Crons" in the Reseller Level Backup screen. I find this extremely concerning as there is not even a message generated as to why they are not running.

Does anyone have any ideas how to troubleshoot this problem?
 
Are you sure you have it set to run nightly? Make sure you have a * in all the fields besides hour and minute.

You can also check the cron log to see if it attempted to run at all.
 
These same jobs have been set up and running for 2 or more years now, they have not been changed. They just stopped running two nights ago for some reason.

Edited to add: Actually, it is really 7 jobs that each back up once per week on a different day into a different folder, so it is actually two different weekly jobs that have not run over the last two days.
 
Last edited:
I just took a look at the cron log and see the following...
Code: 
Sep 21 21:00:01 ns1 crond[6671]: (diradmin) CMD (echo -e "action=backup&id=3&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)
Sep 22 21:00:01 ns1 crond[11970]: (diradmin) CMD (echo -e "action=backup&id=4&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)
So it does look as though cron is working and the jobs were triggered but they seem to fail silently.
 
Sep 22 21:00:01 ns1 crond[11970]: (diradmin) CMD (echo -e "action=backup&id=4&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da

there is something i dont get...

Code: 
/usr/local/directadmin/data/task.queue.da

I always used

Code: 
/usr/local/directadmin/data/task.queue

so ... thats curios...

Also all my directadmin cronjobs are on file i use to use:

Code: 
* * * * * root /usr/local/directadmin/dataskq
2 0-23/6 * * * root echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
#5 5 * * 0 root /sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
10 0 * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
20 4 1 * * root echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
0 4 * * * root echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue

Did you edited skin files os something else recently?

Keep in mind that i should be wrong, not have atm avaible a test box for test if backup put in different task file name...

Regards
 
No, I simply used the DirectAdmin interface to set these up about 2 years ago, they have been running fine since then. The only thing I can think of is two days ago I wanted to determine exactly where DirectAdmin stored its temp files while backing up (because I'm building a new server and wanted to make sure all my partitions were big enough), so I created an additional backup job to start about 5 minutes from then, let it run, I determined the temp folder being used was /home/tmp. Once that job had completed, and I received email notification of the fact, I deleted it using the DirectAdmin interface, but I did not touch the other jobs in any way or manually edit any files on the server.

Thanks for taking a look at this.

Edited to add: I am using only the default skin, I have never edited a DirectAdmin skin in any way, or changed anything else on this server recently that I can think of.
 
Last edited:
I just decided to do another test so I just added a new 8th job to the Reseller Backups to backup just one of my sites that is very small, it created this entry in /var/spool/cron/diradmin...
Code: 
56 8 * * *  echo -e "action=backup&id=8&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da
This backup ran just fine. So it seems that the task.queue.da is correct at least for this server.
I'm still not sure why the job that is started in the evening has failed the past two nights.
 
SeLLeRoNe said:
Have you tryed to remove the other cron and re-create it?
Click to expand...

Not yet, but I guess that is what I should try next. I will delete and recreate all of those jobs again and see what happens tonight.

Thanks again for your looking into this for me.
 
I am still planning and deleting and then setting up all my jobs again but I noticed something else in the Directadmin system.log file that I thought was interesting.

Even though the two backups that failed were listed as being started by the cron log (as shown in an above post), they do not show up as being started in the system.log file located in /var/log/directadmin.

Code: 
2011:09:18-21:00:01: Running Backup: type=reseller owner=admin id=7
2011:09:19-21:00:01: Running Backup: type=reseller owner=admin id=1
2011:09:20-10:26:01: Running Backup: type=reseller owner=admin id=8
2011:09:20-21:00:01: Running Backup: type=reseller owner=admin id=2
2011:09:23-08:56:01: Running Backup: type=reseller owner=admin id=8

I'm not sure if this additional information is helpful or not but there should be two more entries there, one for the 21st at 9:00pm and one for the 22nd at 9:00pm. So whatever is going wrong must happen after the time the cron job is triggered but before the backup is logged in the system.log file. Looking at backup id 2 I see that in both cases the logged time was 21:00:01 so there can not be that much going on between the two.
 
Check for available space on drives, available space in account. Search for anomalies or permissions in file names/dates after the date/time the last successful backup started.

Last step: hire an experienced administrator from these forums.

Jeff
 
Well, I deleted and recreated all the jobs and the backup did run normally last night, I'm still not sure what kept them from running the previous two nights. There was definitely plenty of hard drive space available, only about 35% of the partition is used. Thanks for your suggestions.
 
You must log in or register to reply here.
Back
Top