1

Приветствую. Появилась необходимость делать бекап БД. Решил использовать mysqldump. Записал в крон задание

 Консоль:
0 4 * * * root mysqldump -uUSER -Pport -hlocalhost -pPASS MYDB --databases --add-drop-table --skip-opt | gzip -c > /var/backups/mysql/`date '+%d-%B-%Y'`.gz

но бекап не создается. Если делать дамп напрямую через консоль, то все работает нормально. Подскажите, пожалуйста, в чем косяк.

PS Кстати, так и должно быть, что задания в crontab -e и /etc/crontab разные?

2

Отдельно скрипт для бэкапа напиши лучше и в крон его добавь, плюс в этом же скрипте какой-нибудь подобие лога, например echo > file.log

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

3 (29.07.2012 14:31:25 отредактировано 4fun)

newzenon пишет:

Отдельно скрипт для бэкапа напиши лучше и в крон его добавь, плюс в этом же скрипте какой-нибудь подобие лога, например echo > file.log

То есть после всей записи просто добавить  echo > file.log ?
Имеет значение, где будет лежать скрипт?

upd: Сделал скрипт. Eсли запускать его вручную, то бекап создается, но через крон не получается что-то

 Консоль:
26 13 * * * root /etc/init.d/backupsql

4

А в скрипте имена программ указаны с полными путями?

Пётр.

Пётр.

5

4fun пишет:

PS Кстати, так и должно быть, что задания в crontab -e и /etc/crontab разные?

Вдумчиво прочитай.

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

6

Peter пишет:

А в скрипте имена программ указаны с полными путями?

Пётр.

Сделал с полными путями. Но ничего не поменялось.
У меня уже такое ощущение, что я не туда пишу. Пробовал писать и в /etc/crontab , и в crontab -e

7

Если делаешь правильно, те добавляешь задания используя

crontab -e

, то

crontab -l

покажет твои задания.
Например, crontab -e

0-59 * * * * /usr/local/sbin/something

И смотришь

#crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXXF3cVta installed on Sun Jul 29 11:11:32 2012)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
0-59 * * * * /usr/local/sbin/something
История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

8

ы. А cron -то запущен? Перезапусти если /etc/crontab редактируешь, хотя еще раз говорю, правильнее crontab -e.

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

9

# crontab -l

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

# ntpdate
10 * * * * root /usr/sbin/ntpdate -B -s ntp.lucky.net ntp.time.in.ua ntp2.time.in.ua
# backup
15 14 * * * root /etc/init.d/backupsql

10

Ты

# crontab /etc/crontab

так что-ли сделал? Зачем?
Удали

# crontab -r

Заново отредактируй задание:

# crontab -e

Добавляешь для ежеминутного

0-59 * * * * /usr/local/sbin/something
История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

11

ы. Для проверки вот такое добавь:

0-59 * * * * echo "Что-нибудь сделали" > /var/log/mycrontab.log

Через минуту посмотри что в /var/log/mycrontab.log

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

12 (29.07.2012 16:01:24 отредактировано 4fun)

Сделал все, как вы написали. В mycrontab.log запись пошла. Но скрипт запускать не хочет, хотя право на запуск есть
Такое ощещение, что запись в крон неправильно добавляю

0-59 * * * * root /etc/init.d/backupsql

Это я для эксперимента каждую минуту поставил. Но все равно эффекта никакого

13

Не засоряй /etc/init.d/ !!
Для этих нужд есть каталог - /usr/local/sbin/
Покажи

4fun пишет:

Такое ощещение, что запись в крон неправильно добавляю

    0-59 * * * * root /etc/init.d/backupsql

Еще раз, если добавляешь по crontab -e, то указывать пользователя не надо, crontab -e сам в курсе от кого ты в данный момент залогинен, и в соответствии с этим добавляет задание.

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

14

Спасибо, проблема решена. Убрал пользователя и переместил скрипт в /usr/local/sbin/