Настройка еженедельного резервного копирования CRON

Вы можете попытаться перенаправить ошибки из вашей линии cron в файл, например:

/usr/local/mysqlbackup.sh & amp; gt; /var/log/mysqlcron.log

Это должно ловить как stdout, так и stderr и сообщать, есть ли синтаксическая ошибка и т. д.

Примечание: если вы делаете резервную копию живой базы данных, вы должны используйте специальные утилиты для резервного копирования, например mysqldump , вместо использования общей команды tar. Причина в том, что если файлы внутри / var / lib / mysql / изменяются во время выполнения tar, вы можете получить несогласованное изображение базы данных.

Несколько точек для создания:

• Почему вы используете timestrings в сценариях /etc/cron.weekly / ? Вы должны использовать только исполняемые скрипты. Вам не нужно им наступать или что-то еще. Это просто дублирует их работу. Посмотрите на /etc/cron.daily/apt для примера того, о чем я говорю. Это простой сценарий.
• В комментарии от пользователя geirha файл не может иметь расширение. Нечетный, я знаю, поэтому переименуйте его: sudo mv /etc/cron.weekly/mysqlbackup{.sh,}
• Вам нужно запустить sudo chmod + x / etc / cron.weekly / mysqlbackup , чтобы сделать его исполняемым. Затем вы можете проверить его, запустив его, используя этот путь.
• Если вы оставите его в /etc/cron.weekly / , скрипт будет запущен с правами root. Ни одна из ваших ~ / ссылок не будет работать. Используйте полные пути. Я бы предположил, что после того, как вы сделаете mkdir , вы cd в него, и это уменьшит огромные пути в последующих командах. Если вам нужны сгенерированные файлы, которые будут принадлежать вашему пользователю, сделайте свой скрипт chown для своего пользователя, когда он будет создан. Я не вижу причин, по которым любой из них можно было бы запустить с помощью root. Вы можете использовать скрипт в своем домашнем каталоге и просто использовать стандартный crontab -e , чтобы добавить свое правило и запустить его. Он все еще должен быть исполняемым, и я по-прежнему рекомендую вам использовать полные пути, но он немного облегчает разрешения.

День недели - это числовое поле, поэтому он не работает, пытаясь разобрать «fri». Измените это значение на 5 (воскресенье равно 0). edit: Я вижу, что OP был обновлен, чтобы исправить это, и все еще есть проблемы, но они адресованы в других ответах.

Формат cron хорошо документирован в Интернете, поэтому я обычно заканчиваю проверку документов до написав новое задание cron: http://en.wikipedia.org/wiki/Cron

Кроме того, убедитесь, что вы используете crontab -e (или подобное), чтобы отредактировать ваш cron-файл, который будет проверяться на повторную обработку.

Вы можете попытаться перенаправить ошибки из вашей линии cron в файл, например:

/usr/local/mysqlbackup.sh & amp; gt; /var/log/mysqlcron.log

Это должно ловить как stdout, так и stderr и сообщать, есть ли синтаксическая ошибка и т. д.

Примечание: если вы делаете резервную копию живой базы данных, вы должны используйте специальные утилиты для резервного копирования, например mysqldump , вместо использования общей команды tar. Причина в том, что если файлы внутри / var / lib / mysql / изменяются во время выполнения tar, вы можете получить несогласованное изображение базы данных.

Несколько точек для создания:

• Почему вы используете timestrings в сценариях /etc/cron.weekly / ? Вы должны использовать только исполняемые скрипты. Вам не нужно им наступать или что-то еще. Это просто дублирует их работу. Посмотрите на /etc/cron.daily/apt для примера того, о чем я говорю. Это простой сценарий.
• В комментарии от пользователя geirha файл не может иметь расширение. Нечетный, я знаю, поэтому переименуйте его: sudo mv /etc/cron.weekly/mysqlbackup{.sh,}
• Вам нужно запустить sudo chmod + x / etc / cron.weekly / mysqlbackup , чтобы сделать его исполняемым. Затем вы можете проверить его, запустив его, используя этот путь.
• Если вы оставите его в /etc/cron.weekly / , скрипт будет запущен с правами root. Ни одна из ваших ~ / ссылок не будет работать. Используйте полные пути. Я бы предположил, что после того, как вы сделаете mkdir , вы cd в него, и это уменьшит огромные пути в последующих командах. Если вам нужны сгенерированные файлы, которые будут принадлежать вашему пользователю, сделайте свой скрипт chown для своего пользователя, когда он будет создан. Я не вижу причин, по которым любой из них можно было бы запустить с помощью root. Вы можете использовать скрипт в своем домашнем каталоге и просто использовать стандартный crontab -e , чтобы добавить свое правило и запустить его. Он все еще должен быть исполняемым, и я по-прежнему рекомендую вам использовать полные пути, но он немного облегчает разрешения.

День недели - это числовое поле, поэтому он не работает, пытаясь разобрать «fri». Измените это значение на 5 (воскресенье равно 0). edit: Я вижу, что OP был обновлен, чтобы исправить это, и все еще есть проблемы, но они адресованы в других ответах.

Формат cron хорошо документирован в Интернете, поэтому я обычно заканчиваю проверку документов до написав новое задание cron: http://en.wikipedia.org/wiki/Cron

Кроме того, убедитесь, что вы используете crontab -e (или подобное), чтобы отредактировать ваш cron-файл, который будет проверяться на повторную обработку.

Вы можете попытаться перенаправить ошибки из вашей линии cron в файл, например:

/usr/local/mysqlbackup.sh & amp; gt; /var/log/mysqlcron.log

Это должно ловить как stdout, так и stderr и сообщать, есть ли синтаксическая ошибка и т. д.

Примечание: если вы делаете резервную копию живой базы данных, вы должны используйте специальные утилиты для резервного копирования, например mysqldump , вместо использования общей команды tar. Причина в том, что если файлы внутри / var / lib / mysql / изменяются во время выполнения tar, вы можете получить несогласованное изображение базы данных.

Несколько точек для создания:

• Почему вы используете timestrings в сценариях /etc/cron.weekly / ? Вы должны использовать только исполняемые скрипты. Вам не нужно им наступать или что-то еще. Это просто дублирует их работу. Посмотрите на /etc/cron.daily/apt для примера того, о чем я говорю. Это простой сценарий.
• В комментарии от пользователя geirha файл не может иметь расширение. Нечетный, я знаю, поэтому переименуйте его: sudo mv /etc/cron.weekly/mysqlbackup{.sh,}
• Вам нужно запустить sudo chmod + x / etc / cron.weekly / mysqlbackup , чтобы сделать его исполняемым. Затем вы можете проверить его, запустив его, используя этот путь.
• Если вы оставите его в /etc/cron.weekly / , скрипт будет запущен с правами root. Ни одна из ваших ~ / ссылок не будет работать. Используйте полные пути. Я бы предположил, что после того, как вы сделаете mkdir , вы cd в него, и это уменьшит огромные пути в последующих командах. Если вам нужны сгенерированные файлы, которые будут принадлежать вашему пользователю, сделайте свой скрипт chown для своего пользователя, когда он будет создан. Я не вижу причин, по которым любой из них можно было бы запустить с помощью root. Вы можете использовать скрипт в своем домашнем каталоге и просто использовать стандартный crontab -e , чтобы добавить свое правило и запустить его. Он все еще должен быть исполняемым, и я по-прежнему рекомендую вам использовать полные пути, но он немного облегчает разрешения.