rsnapshot: что не так с моим crontab?

596
Danijel

Я использую Rsnapshot для резервного копирования (Linux CentOS 6).

Вот мой /etc/cron.d/rsnapshot:

30 11 * * * root /usr/bin/rsnapshot nowandthen > /backups/rsnapshot_cron.txt 2>&1 15 11 * * 4 root /usr/bin/rsnapshot weekly > /backups/rsnapshot_cron.txt 2>&1 00 11 24-31 * 4 root /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1 

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

Однако ежемесячное резервное копирование выполняется сегодня, в четверг, 2016-февраль-18 в 11:00. Сегодня не последний четверг месяца.

Что не так с моим crontab?

1
что ты видишь в своих логах? Jakuje 8 лет назад 0
Ваш crontab выглядит правильно. У вас есть правильная дата на вашем компьютере? Какой вывод у `date`? Что-нибудь актуальное в `grep CRON / var / log / syslog`? agtoever 8 лет назад 0
Я не могу объяснить, почему он работал 18-го числа, но помните, что есть несколько файлов `crontab`: кроме того, в` / etc` есть записи для каждого пользователя, включая `root`. В любом случае, ваш сценарий не будет выполнять то, что вы хотите: если последний день 31-дневного месяца - четверг, он будет выполняться 24-го и 31-го числа; если последний день февраля - среда, он вообще не будет работать. AFH 8 лет назад 0

1 ответ на вопрос

3
AFH

According to this site, your string means “At 11:00 on the 24, 25, 26, 27, 28, 29, 30 and 31st of every month and every Thu.” (my emphasis). If the site is correct this would explain why it ran on 18th.

The example entry in man 5 crontab to run on 2nd Saturday is:

0 4 8-14 * * test $(date +\%u) -eq 6 && echo "2nd Saturday" 

(ie run every day of the second week and check for the week day as part of the command) - this supports the view that the week day is an additional, alternative filter, not a further qualification, though the manual page does not make it clear.

So in your case I would use:

00 11 * * 4 root test $(date -d @$((`date +\%s`+604800)) +\%m) -ne $(date +\%m) && /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1 

Check if your date supports -d 'next Thursday': if so you can use the rather simpler:

00 11 * * 4 root test $(date -d 'next Thu' +\%m) -ne $(date +\%m) && /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1 

This runs every Thursday and checks if the date a week (604800 seconds) from now is in the same month: if not, it must be the last Thursday so the back-up command runs.

Вам нужно будет избегать знаков процента, как в примере со второй субботой. tripleee 8 лет назад 0
Если у вас есть дата GNU, она поддерживает `-d" следующий четверг "+% m`, поэтому вы можете пропустить одну вложенную подкоманду. tripleee 8 лет назад 0
@tripleee - я тестировал команду с `bash` в Ubuntu, и экранирование не требовалось, хотя я не проверял ее в` crontab`, потому что тестирование было бы слишком сложным. Я могу представить, что это будет необходимо в среде GNU / Windows, но я изменю свой ответ, поскольку это не может причинить вреда. Спасибо за совет "в следующий четверг": он работает на Ubuntu, поэтому я включу его. AFH 8 лет назад 0
Экранирование знаков процента является требованием, специфичным для синтаксиса crontab; так что да, он будет работать в командной строке без побега. tripleee 8 лет назад 0
Нет времени на тестирование ... жду следующего четверга. :) Danijel 8 лет назад 0
@tripleee - хорошо, спасибо. Теперь я нашел обсуждение процентных знаков на странице руководства. Я ошибочно предположил, что команда будет передана дословно оболочке. Мы живем и учимся. AFH 8 лет назад 0
@Danijel - я предлагаю вам ввести дополнительную, фиктивную команду (например, для вывода в файл) с тем же временем и тестовым синтаксисом, но с указанием времени в ближайшем будущем. Это гарантирует, что он не запускается неожиданно. Вам придется подождать до следующего вторника, чтобы убедиться, что он _действует_, когда ожидается. Однако, если вы используете длинную форму, убедившись, что она не работает сегодня, измените смещение секунд на «+ 604800 * 2», и оно должно запуститься. Это будет хорошей проверкой до следующей недели. Обратите внимание на мое изменение, чтобы избежать знаков процента после комментариев @ tripleee. AFH 8 лет назад 0
Да, и на самом деле `$ ((...))` - это расширение Bash, поэтому строго не разрешено в `crontab`, который всегда запускает` sh`. Вы можете сказать `bash -c '... ваш скрипт ...'` или надеяться, что `sh` - это` bash`, который не слишком строг в отношении режима POSIX. tripleee 8 лет назад 0
@tripleee - я действительно пробовал это в `sh`, хотя в Ubuntu он связан с` bash`, но он работает с синтаксисом `sh`. Это также задокументировано в руководстве `sh`, хотя оно не совместимо с Born. Я задумался о том, чтобы предложить поместить тест в скрипт, который возвращает результат теста: этому может предшествовать `#! / Bin / bash`. В качестве альтернативы, можно установить переменную окружения `SHELL` до запуска` cron`, чтобы указать, какую оболочку использовать. AFH 8 лет назад 0

Похожие вопросы