Как автоматизировать бэкапы через cron

Краткий ответ: Соберите бэкап-команды в скрипт, сделайте его исполняемым и добавьте строку в crontab, например 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1. Логируйте всё и читайте лог — бэкап, тихо переставший запускаться, это классическая история катастрофы.

Обзор

cron выполняет команды по расписанию и есть на каждом Linux-сервере. Разница между игрушечной настройкой и надёжной невелика: абсолютные пути, вывод в лог, оповещение при падении задачи и периодический тест восстановления.

Что нужно иметь

• Бэкап-команду, которая уже работает вручную (см. бэкапы через rsync).
• Базовое знакомство с синтаксисом cron.
• SSH-аутентификацию по ключу для удалённой цели — cron не умеет вводить пароли.

Пошаговая инструкция

1. Создайте скрипт /usr/local/bin/backup.sh:

   #!/bin/bash
   set -euo pipefail
   mysqldump --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz
   rsync -az --delete /var/www/ [email protected]:/srv/backups/www/
   rsync -az /var/backups/ [email protected]:/srv/backups/db/
   echo "$(date -Is) backup OK"

2. Сделайте его исполняемым:

   chmod +x /usr/local/bin/backup.sh

3. Запланируйте (crontab -e):

   30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

4. Запустите один раз вручную и убедитесь, что строка в логе и удалённые файлы появились.
5. Добавьте оповещения о сбоях — из-за set -e любая ошибка обрывает скрипт, так что отсутствующая в логе строка "backup OK" означает сбой; небольшой скрипт-обёртка может отправить письмо или пинг.
6. Ротируйте старые дампы, чтобы диск никогда не заполнился:

   find /var/backups -name 'db-*.sql.gz' -mtime +14 -delete

Типичные проблемы

• Работает вручную, падает в cron: у cron минимальный PATH — используйте абсолютные пути для каждого бинарника и файла.
• Нет лога — нет представления: без >> ... 2>&1 ошибки исчезают; всегда перехватывайте вывод.
• Наложение запусков: длинные передачи могут столкнуться со следующим расписанием — оберните задачу во flock, если запуски могут превышать интервал.

Когда обращаться в поддержку

Бэкап-скрипты на unmanaged-планах Cloud2Y — на стороне клиента, но если задачи падают из-за сервера или сети (ошибки I/O, обрывы еженощно в одно время), откройте тикет с выдержками из лога.

Частые вопросы

Почему скрипт работает вручную, но падает в cron?

cron запускается с минимальным окружением и PATH, поэтому команды и файлы нужно указывать абсолютными путями, а любое SSH-подключение требует ключа, а не запроса пароля.

Как перехватить вывод cron-задачи бэкапа?

Перенаправьте stdout и stderr в строке crontab, например ">> /var/log/backup.log 2>&1". Без этого ошибки исчезают, и о сбоях вы узнаёте на месяцы позже, чем нужно.

Как предотвратить наложение запусков бэкапа?

Оберните задачу во flock, напр. "flock -n /tmp/backup.lock /usr/local/bin/backup.sh" — тогда длинная передача не столкнётся со следующим запуском по расписанию и не повредит цель.

Похожие статьи

• Как настроить cron-задачи
• Как делать бэкап Linux-сервера с помощью rsync
• Как проверить целостность бэкапов
• Типичные ошибки с бэкапами

Нужна помощь? Связаться с поддержкой Cloud2Y →