Scheduled Reseller Backups Not Executing

[roarkh]

I am having a problem getting scheduled reseller backups to run reliably using the DirectAdmin control panel.

To set up my backup jobs I logged into my DirectAdmin server as a reseller and chose "Manage User Backups." In there, under "Current Backup Crons" I have seven jobs listed, each backs up "All Users" into a separate folder on an ftp server at 9:30 in the evening. Each job is set to run once per week putting the resulting backup into a different folder on the ftp server.

For instance the first job in the list is for Sunday backups. When is set to Minute:30, Hour:21, Day of Month:*, Month:*, Day of Week:0. Who is set to "All Users." Where is set to ftp://<myftpserver>/da_backups/0sunday.

I looked at the cron log for this past Sunday and see this line...

Apr 30 21:30:01 ns1 crond[32723]: (diradmin) CMD (echo -e "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)

so it looks like cron is doing its job but I usually end up with no backup in my backup folder and no message telling me either that the backup had failed or been finished successfully.

I know for sure that it is not a bad username or password on the ftp server or a bad path on the ftp server because running the exact same jobs manually to the ftp server works every time and I have deleted and recreated these jobs many times to make sure there is no typo.

Even weirder is that sometimes, seemingly at random, the cron jobs do finish properly, maybe 1 or 2 work on the average week but not on any specific evening, it changes from week to week. I have tried times other than 9:30 to see if that might make some difference but nothing I try seems to help.

Does anyone have an idea what may be happening here?

I am currently running DirectAdmin version 1.26.6 but the same thing was happening with past versions as well. The server OS is Centos 4.1.

Thanks in advance

 

[DirectAdmin Support]

Hello,

We can confirm cron is running by the log entry.
From there
1) check that /usr/local/directadmin/data is chowned to diradmin:diradmin. If we know that, and we know that the "dataskq" is running every minute, then DA is most likely trying to do it.

2) Try setting up the bacukps to run locally via cron. If it works locally but not from ftp, we can point the problem to ftp.
If it doesn't work locally, then there is a backup problem.

3) Make sure /home/tmp is chmod 1777, eg, run:
chmod 1777 /home/tmp
The bacukps system needs this.

4) Take a look inside /home/tmp/* for any files/directories. There shouldn't be anything there (except when a backup is in progress or DA file upload is in progress). If /home/tmp/reseller exists, then delete it and it's contents.

5) If we've ruled it as an ftp problem in step 2, then it's usually a firewall/ports problem. The default uses php's ftp functions, but you can swap it around to use ncftpput or curl:
http://help.directadmin.com/item.php?id=111
Which may give you better results than php's built-in functions.
Also, try shutting off any firewalls on the local machine and the remote machine to test.

John

 

[roarkh]

Thank you for your reply, I've been out of the office for a bit which is why I am just now getting back to you.

In response to your questions...

1. /usr/local/directadmin/data is owned by diradmin:diradmin and it's permissions appear to be 711 ("drwx--x--x").

2. Just this morning I set a cron job to backup locally everyday at 10:00am. For at least this morning it ran, I will need to give it a few days to know for sure because as I mentioned before the backups work sometimes but not others. For instance this weekend they did run on Saturday and Sunday but did not run Monday or Tuesday.

3. I have verified that /home/tmp has 1777 permissions as suggested.

4. /home/tmp is empty

5. If I manuallly run a database using ftp (immediate rather than cron) then it always works just fine so I don't think it is an ftp problem. I have deleted and reentered the cron jobs more than once and am absolutely positive that the username/password, address and path are correct (they are the same ones I use when running a backup manually).

I will let you knw after a few days if the local cron job I set up works reliably day in and day out.

Thank you for your help.

Roark

 

[roarkh]

As I mentioned in my previous post I set up a cron job using the Reseller Level panel to do daily backups at 10:00am to the local hard drive (home/admin/user_backups) as requested. It has been running just fine every day until today. Today it simply did not run. Also, when the backup works I get a message in the Message System stating that the backup was successful. When it does not run I get no message at all indicating either success or failure.

In case it helps here are some of the entries from my cron job from around 10:00 today...

May 17 09:57:01 ns1 crond[25464]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 09:58:01 ns1 crond[25487]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 09:59:01 ns1 crond[25542]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 10:00:01 ns1 crond[25577]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 10:00:01 ns1 crond[25578]: (diradmin) CMD (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)
May 17 10:01:01 ns1 crond[25614]: (root) CMD (run-parts /etc/cron.hourly)
May 17 10:01:01 ns1 crond[25616]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 10:02:01 ns1 crond[25658]: (root) CMD (/usr/local/directadmin/dataskq)
May 17 10:03:01 ns1 crond[25711]: (root) CMD (/usr/local/directadmin/dataskq)

 

[edzelf]

The same problem here. The backups for admin is executed correctly every day, but the backups for (in this case 1) reseller fails in about 50 % of the cases. There is a normal /var/log/cron logging and no errors in /var/log/messages.

It looks like entries in /usr/local/directadmin/data/task.queue.da are sometimes not completely executed, because occasionally the reset of bandwith tallies on the first of each month doesn't work either (about once in three month with 10 servers monitored).