Вопросы Теги

форматирование cron.allow и/или делает крон, должен быть перезапущен

  1. Локальные резервные копии (сетевые файловые серверы, включая исходные репозитории и почтовый сервер) взятый к другой машине через rsync ежедневно и многим сохраненным снимкам (в случае, если мы обнаруживаем недели по линии, что файл случайно редактировался/удалялся) способом, подобным http://www.mikerubel.org/computers/rsync_snapshots/
  2. Удаленное резервное копирование подготавливает тот: новая копия локального резервного копирования, отправленного до промежуточного удаленного сервера через rsync по SSH
  3. Удаленное резервное копирование подготавливает тот: копия подняла с промежуточного сервера, через rsync по SSH, основным удаленным резервным копированием, которое поддерживает много снимков как локальное резервное копирование
  4. Резервное тестирование (резервные копии файлового сервера): один раз в неделю сценарий делает два "rsync - контрольная сумма - пробный прогон" s, один между живыми файловыми системами и промежуточным сервером резервного копирования и один между промежуточным звеном и последней копией на разрядном удаленном резервном копировании и отправляет мне по почте результаты (таким образом, любые главные несоответствия предупредят меня к проблемам).
  5. Резервное тестирование (почтовый сервер): однажды в день, спустя несколько часов после того, как обычные резервные выполнения должны закончиться, VM, содержащий копию почтового сервера, работая на основном сервере резервного копирования, восстанавливает последнее почтовое резервное копирование на себя. Я вхожу в это время от времени (если это работает хорошо, и я вижу недавнюю новую почту и другие изменения, я знаю, что почтовое резервное копирование прекрасно).
  6. Офлайновое резервное копирование: копия этого копирует взятый прилегающий объект на диске USB каждую неделю (на самом деле, мы в настоящее время не делаем этого, но я буду провоцировать его, после того как я имею время и могу захватить кредитную карту компании для покупки нескольких внешних дисков с),

    7. Шаги 4 и 5 очень важны. Резервное копирование не является действительно резервным копированием, если Вы не протестировали его, и время, когда Вы находите, что необходимо восстановить файлы (или все) не хороший первый раз, который протестирует! Тестирование резервных копий является чем-то, что часто оставляют люди, пока не слишком поздно, чтобы сделать что-либо, если это не работало.

    Шаги 2 и 3 могут казаться излишеством, но добавить немного безопасности. Поскольку локальные серверы не могут говорить непосредственно с серверами резервного копирования или наоборот, кто-то, кому удается взломать, нельзя легко добраться оттуда до другого (только к промежуточной машине, которая, в то время как живые и резервные машины могут пройти проверку подлинности против нее, не может самостоятельно пройти проверку подлинности или против живых или против резервных машин). Это избегает риска стычки, которые недавно поражают WHT (см. http://ask.slashdot.org/story/09/03/25/0036211/How-To-Prevent-Being-Hacked-Via-Backups для обсуждения).

0
задан 21 October 2009 в 18:09
2 ответа

Как сказанный Cornfed, Ваш .php сценарий должен был бы запуститься с #!/usr/bin/php, чтобы это работал.

1) cron.allow/deny файлы только влияют на пользовательскую способность выполнить команду 'crontab', не способность к пользователю иметь crontab. Посмотрите человека crontab.

2) Да, также перечисленный в человеке crontab.

3) Да, любой пользователь мог добавить себя к тому списку. Это является слишком разрешающим. Но в большинстве случаев Вам не нужен этот файл на Debian. От человека crontab: "Для стандартных систем Debian все пользователи могут использовать эту команду".

4) Нет, но я заметил задержку принятия новых команд. См./var/log/daemon (я думаю) для обновления КРОНА, он - внутренние файлы.

1
ответ дан 4 December 2019 в 23:21
  • 1
    Я ценю ответ, см. комментарии I' ve добавляется к моему вопросу –  George Jempty 21 October 2009 в 19:24
  • 2
    PS.... новая команда принят своевременно при добавлении к root' s crontab –  George Jempty 21 October 2009 в 19:26
  • 3
    Еще раз спасибо я теперь на самом деле удалил cron.allow, который я ранее создал, и crontab все еще выполняет задачу для www-данных, подтверждая то, что Вы пишете под № 3 относительно, вероятно, не необходимости cron.allow на Debian –  George Jempty 21 October 2009 в 19:52

Вы могли бы попробовать "15,30,45 * * * */usr/bin/php/var/www/cron/test.cli.php"

0
ответ дан 4 December 2019 в 23:21

Теги

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