Crontab для резервного копирования rsync с подключением ssh

Я думаю, что это невозможно сделать с помощью выскочки, так как сценарий /etc/init.d/sendsigs, который вызывается выскочкой при остановке / перезапуске, убивает все процессы (killall5 -9) в течение 10 секунд, и даже если это не удастся, он идет на размонтирование всего и завершение работы.

Лучшим способом было бы использовать скрипты ржавого /etc/init.d/sendsigs .

Пример: /etc/init.d/shutdown_job

#! /bin/sh
### BEGIN INIT INFO
# Provides:          shutdown_job
# Required-Start:    
# Required-Stop:     sendsigs
# Default-Start:
# Default-Stop:      0 6
# Short-Description: bla
# Description: 
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/lsb/init-functions

do_stop () {
    date > /root/s.log
    sleep 20
    date >> /root/s.log
}

case "$1" in
  start)
    # No-op
    ;;
  restart|reload|force-reload)
    echo "Error: argument '$1' not supported" >&2
    exit 3
    ;;
  stop)
    do_stop
    ;;
  *)
    echo "Usage: $0 start|stop" >&2
    exit 3
    ;;
esac

:

Затем активируйте скрипт

sudo update-rc.d shutdown_job start 19 0 6 .

Это поставит скрипт перед выскочкой на уровнях выполнения 0 a 6 (shutdown, reboot). Этот образец сценария будет записывать дату, затем спать в течение 20 секунд, а затем записывать дату снова в /root/s.log.)

Дополнительная информация:

man update-rc.d http: //www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
0
задан 15 May 2018 в 11:15

2 ответа

Проблема была в том, что соединение ssh Ошибка проверки ключа хоста.

Я запустил cronjob на кронтабе корня. (Я добавил cronjob через «sudo crontab -e».)

14 2 * * * / usr / bin / rsync -az --delete -e ssh / home / user / folder / user @ server .example.com: / home / user / folder

Кажется, что ssh-соединение затем устанавливается пользователем root, а не «пользователем».

Таким образом, попытка подключения на самом деле:

14 2 * * * / usr / bin / rsync -az --delete -e ssh / home / user / folder / user@server.example.com: / home / user / folder

ssh root@server.example.com

ssh user@server.example.com

, а не

Итак, я добавил cronjob к кронтабу «пользователя». (crontab -e (без sudo)).

Теперь выполняется проверка ключа хоста, и задание crontab rsync выполняется должным образом.

Я не знаю точно, если вышеприведенные предположения Правильно, но это решило проблему.

Надеюсь, что эта нить поможет кому-то еще на определенном этапе.

1
ответ дан 17 July 2018 в 14:16

Проблема была в том, что соединение ssh Ошибка проверки ключа хоста.

Я запустил cronjob на кронтабе корня. (Я добавил cronjob через «sudo crontab -e».)

14 2 * * * / usr / bin / rsync -az --delete -e ssh / home / user / folder / user @ server .example.com: / home / user / folder

Кажется, что ssh-соединение затем устанавливается пользователем root, а не «пользователем».

Таким образом, попытка подключения на самом деле:

14 2 * * * / usr / bin / rsync -az --delete -e ssh / home / user / folder / user@server.example.com: / home / user / folder

ssh root@server.example.com

ssh user@server.example.com

, а не

Итак, я добавил cronjob к кронтабу «пользователя». (crontab -e (без sudo)).

Теперь выполняется проверка ключа хоста, и задание crontab rsync выполняется должным образом.

Я не знаю точно, если вышеприведенные предположения Правильно, но это решило проблему.

Надеюсь, что эта нить поможет кому-то еще на определенном этапе.

1
ответ дан 20 July 2018 в 14:19

Другие вопросы по тегам:

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