Admin Backup/Transfer werkt niet

[Arto]

Ik gebruik Direct Admin v1.31.5, dus recente versie.
Ik probeer een Backup Cronjob te maken via Admin Backup/Transfer.

Zie bijlagen.

Na dit krijg ik dit standaard bericht :

Backups added to Queue



Details

You will be notified via the Message System when the process is complete



Ik krijg geen Message en backup word ook niet gemaakt in "die" directory.
Volgens dit cron zou er elke nacht om 00:00 het backup worden gemaakt, maar dit gebeurt helaas niet.
Paar maanden geleden ging dit allemaal zonder problemen, maar nu opeens niet.
Iemand een enige idee hoe ik dat kan oplossen.

[Arto]

Trouwens in Admin level staan deze 2 Cron's.
Ik herinner niet dat ik deze heb aangemaakt.
Enigde idee wat dit inhoud :

* * * * * 36 0 * * * /path/to/bin/php /path/to/cron.php
* * * * * /usr/local/bin/php -q -f /home/user/domains/domain.com/public_html >> /dev/null

[Fortynas]

Zijn de DirectAdmin skins eigelijk wel up 2 date?

[bami82]

Is je cron wel gestart?
(ps aux | grep cron)

[Arto]

Zijn de DirectAdmin skins eigelijk wel up 2 date?

Wat bedoel je hiermee?
Ik update gewoon mijn Direct Admin als er een Update is, met Skins heb ik nooit iets gedaan.

Is je cron wel gestart?
(ps aux | grep cron)

# ps aux | grep cron
root 4783 0.0 0.0 5240 908 ? Ss Jan24 0:56 crond
root 15975 0.0 0.0 3892 648 pts/1 D+ 15:40 0:00 grep cron

[ichosting]

Zet je cron eens iets later aangezien DA om 0:00 zelf ook dingen uitvoert.
Probeer de cron eens op bijvoorbeld 1:00 ofzo

[Arto]

Helpt helaas niet.

[brinkie]

Ik gebruik Direct Admin v1.31.5, dus recente versie.
Ik probeer een Backup Cronjob te maken via Admin Backup/Transfer.

Zie bijlagen.

De vinkjes onder de kolom 'select' weghalen.. (althans, zo staat het bij mij ingesteld en het werkt perfect, alles wordt weggeschreven naar de /home/admin/admin_backups op die manier, neem aan dat je dat wilt).

[Arto]

Die vinkjes zijn om users te selecteren
Als je dat niet selecteert dan Backup ie niet neem ik aan.
Het vage is dat directory wel wordt aangemaakt :

/home/admin/admin_backups

[systemdeveloper]

Paar maanden geleden ging dit allemaal zonder problemen, maar nu opeens niet.
Iemand een enige idee hoe ik dat kan oplossen.

Inloggen via ssh en de logs checken? Misschien doet je dns het niet goed, of de email (aangezien je die niet ontvangt), misschien zijn er een paar symlinks verdwenen, rechten aangepast oid.
Misschien is een backupprocess gewoon blijven hangen en moet even gekilled worden.
Zonder logs valt er weining te zeggen...

[Geert-Jan]

Laat anders even iemand 'mee' kijken. ik heb het gevoel dat je er zo niet uit gaat komen.
Er moeten berichten zijn, hetzij goed / foutmeldingen.
Wat zegt b.v. /var/log/directadmin ?

[Arto]

Nu staat al 2 dagen mijn Backup Cron op 17:00.
Dit is het error log van vandaag om 17:00

Zie :

May 13 17:00:01 server crond[1313]: (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)

May 13 17:00:01 server crond[1301]: (root) CMD (/usr/local/mrtg-2/bin/mrtg /var/www/html/mrtg/core/mrtg.cfg)
May 13 17:00:01 server crond[1300]: (root) CMD (/usr/local/sbin/bfd -q)
May 13 17:00:01 server crond[1307]: (admin) CMD (/usr/local/bin/php -q -f /home/user/domains/domain.com/public_html >> /dev/null)
May 13 17:00:01 server crond[1310]: (admin) CMD (36 0 * * * /path/to/bin/php /path/to/cron.php)
May 13 17:00:01 server crond[1313]: (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)
May 13 17:00:01 server crond[1317]: (root) CMD (/usr/local/directadmin/dataskq^M)
May 13 17:01:01 server crond[1575]: (root) CMD (run-parts /etc/cron.hourly)
May 13 17:01:01 server crond[1576]: (root) CMD (/usr/local/directadmin/dataskq^M)

[systemdeveloper]

A wild guess.....

ik zie daar een ^M achter een de dataskq staan... waarschijnlijk is er ergens een bestandje niet goed geupload of met een verkeerde editor aangepast.
Ik schat dat door dat tekentje die cronregel gewoon niet wordt uitgevoerd.

Check je /etc/crontab eens goed en retype die regel desnoods opnieuw als je het tekentje op het eind niet wegkrijgt.

Maar zoals gezegd... a wild guess... echter geen foutmelding kan dus betekenen dat het gewoon niet uitgevoerd word.

Ben benieuwd...

[Arto]

A wild guess.....

ik zie daar een ^M achter een de dataskq staan... waarschijnlijk is er ergens een bestandje niet goed geupload of met een verkeerde editor aangepast.
Ik schat dat door dat tekentje die cronregel gewoon niet wordt uitgevoerd.

Check je /etc/crontab eens goed en retype die regel desnoods opnieuw als je het tekentje op het eind niet wegkrijgt.

Maar zoals gezegd... a wild guess... echter geen foutmelding kan dus betekenen dat het gewoon niet uitgevoerd word.

Ben benieuwd...

etc/crontab :

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

*/5 * * * * root /usr/local/mrtg-2/bin/mrtg /var/www/html/mrtg/core/mrtg.cfg

Die regel komt hier niet eens voor, het bestand op ftp is gewoon /usr/local/directadmin/dataskq

[systemdeveloper]

Er zijn meerder plekken waar je cron kan staan idd.

Deze regel lijkt me ook niet helemaal ok trouwens:

May 13 17:00:01 server crond[1310]: (admin) CMD (36 0 * * * /path/to/bin/php /path/to/cron.php)

Misschien heb je in /var/tabs/crons nog iets staan of daar in de buurt.