Краткое содержание: В 2026 году ручное выполнение команд для резервного копирования баз данных или обновления сертификатов означает потерю как минимум половины вычислительных ресурсов. В этом руководстве мы обеспечим подавляющее преимущество в освоении Crontab — классического инструмента автоматизации в Linux. Вы получите чёткое объяснение синтаксиса, 4 готовых скрипта для хостинг сайтов (включая удалённое резервное копирование и мониторинг доступности) и пошаговый алгоритм устранения ошибок, когда задачи в Cron просто не запускаются.
Если вы используете качественные серверы от RackNerd, DMIT или BandwagonHost, но по-прежнему ежедневно вручную запускаете бэкапы, обновляете SSL-сертификаты или чистите логи, вы впустую расходуете ресурсы VPS. Зрелый сервер в продакшене должен работать автономно.
Сегодня мы подробно разберём Crontab (планировщик задач) — стандартный инструмент автоматизации в Linux. Мы рассмотрим его архитектуру, базовый синтаксис и гик-приёмы, которые обеспечат подавляющее преимущество и предотвратят сбои.
🧠 Основы: что такое Crontab?
В Linux cron — это фоновый демон-планировщик. Он работает по строгому расписанию: каждую минуту проверяет, есть ли задачи, готовые к выполнению, и запускает их в фоне. Crontab (Cron Table) — это конфигурационный файл, в котором вы указываете расписание для демона.
Зачем использовать Crontab?
- Минимальное потребление ресурсов: Встроен во все основные дистрибутивы (Debian, Ubuntu, Alpine) и не расходует лишнюю оперативную память.
- Полная автономность: Автоматическое создание резервных копий в 3:00 или мониторинг API каждые 5 минут без участия администратора.
- Гибкая настройка: Точность планирования до минуты, поддержка цепочек команд и запуск Shell-скриптов.
⚙️ Разбор синтаксиса
Пять звёздочек * * * * * могут показаться сложными, но их логика строго структурирована. Введите crontab -e для открытия редактора. Каждая строка — это отдельная задача, состоящая из расписания и команды.
| Позиция | Значение | Диапазон значений | Специальные символы |
|---|---|---|---|
| 1-й параметр | Минуты | 0 — 59 | * — каждую минуту; */5 — каждые 5 минут |
| 2-й параметр | Часы | 0 — 23 | 2,4 — в 02:00 и 04:00 |
| 3-й параметр | День месяца | 1 — 31 | 1-5 — с 1 по 5 число каждого месяца |
| 4-й параметр | Месяц | 1 — 12 | Допустимы сокращения: jan, feb |
| 5-й параметр | День недели | 0 — 7 | 0 и 7 — воскресенье; допустимы sun, mon |
Опытные администраторы часто заменяют сложные комбинации звёздочек встроенными макросами для улучшения читаемости:
@reboot /path/to/script.sh: Выполняется один раз при каждой перезагрузке сервера.@daily /path/to/script.sh: Ежедневно в полночь (эквивалентно0 0 * * *).@hourly /path/to/script.sh: Каждый час в 00 минут.
💻 Гик-практика: 4 обязательных скрипта автоматизации для хостинг сайтов
Ниже приведены готовые примеры для продакшен-среды. Откройте редактор через crontab -e и добавьте нужные строки.
1. Полное автоматическое резервное копирование БД на удалённый сервер
Не полагайтесь на встроенные инструменты панелей управления. Храните резервные копии самостоятельно. Для настройки удалённого хранения рекомендуем ознакомиться с нашим руководством по бесплатной синхронизации данных сервера с Google Drive. Добавьте следующую команду для ежедневного архивирования БД в 03:30:
30 3 * * * /usr/bin/mysqldump -u root -p'YourPassword' wordpress_db > /www/backup/db_$(date +\%F).sql(Примечание: символ % в команде date внутри Crontab обязательно экранируется обратным слэшем \. Это самая частая ошибка новичков.)
2. Автоматическое обновление SSL-сертификатов Let’s Encrypt
При использовании acme.sh для wildcard-сертификатов регулярное обновление обязательно. Настройте ежедневную проверку в 01:10: скрипт обновит сертификат только при необходимости.
10 1 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh > /dev/null3. Ротация и очистка логов Nginx
На высоконагруженных сайтах access.log быстро достигает нескольких гигабайт, заполняя дисковое пространство. Настройте автоматическую очистку каждое воскресенье в 04:15.
15 4 * * 0 /usr/bin/truncate -s 0 /www/wwwlogs/vps1111.com.log4. Мониторинг доступности сервера (Heartbeat)
Каждые 5 минут отправляйте HTTP GET-запрос на ваш мониторинговый инструмент для подтверждения работоспособности сервера. Если у вас ещё нет системы мониторинга, ознакомьтесь с нашим руководством по настройке Uptime Kuma для отслеживания доступности VPS.
*/5 * * * * /usr/bin/curl -k -s "https://status.vps1111.com/api/push/xxxxxxxx" > /dev/null 2>&1💡 vps1111: Практическое руководство по устранению критических ошибок
Если скрипт корректно выполняется вручную через SSH, но не запускается через Crontab, вы столкнулись с одной из типичных проблем конфигурации. Ниже приведён алгоритм диагностики:
🔍 Алгоритм диагностики:
- Изоляция переменных окружения: Crontab не загружает
.bashrcили/etc/profile. Он не знает, где находятся командыphp,wpилиdocker.
Решение: Всегда используйте абсолютные пути! Например,/usr/bin/phpвместоphp,/usr/local/bin/wpвместоwp. - Переполнение системной почты: По умолчанию Crontab отправляет вывод и ошибки на локальную почту, что быстро заполняет inode диска и затрудняет диагностику.
Решение: Добавьте перенаправление в конец команды:> /dev/null 2>&1(игнорировать вывод) или укажите лог-файл>> /var/log/my_cron.log 2>&1для последующего анализа. - Ограничения оболочки: В Ubuntu/Debian Crontab по умолчанию использует
/bin/sh(часто этоdash), который не поддерживает расширенный синтаксис Bash. Если в скрипте используются массивы или[[ ]], выполнение завершится ошибкой.
Решение: Добавьте#!/bin/bashв первую строку скрипта или явно вызывайте Bash в Crontab:* * * * * /bin/bash /path/to/script.sh. - Рекомендация: ⭐⭐⭐⭐⭐ (Обязательный инструмент для системного администрирования).
🚀 Современная альтернатива: Systemd Timers
В современных условиях администратору важно не только владеть Crontab, но и понимать более продвинутые инструменты, такие как Systemd Timers.
Главное ограничение Crontab — отсутствие управления зависимостями. Например, скрипт резервного копирования должен запускаться только после полной инициализации MySQL. Crontab не проверяет статус служб и запускает задачу строго по расписанию.
Systemd Timers интегрированы в систему управления службами Linux. Они позволяют задавать условия: «запустить задачу через 5 минут после появления сети» или «выполнять ротацию логов только при активном Nginx». Кроме того, они используют встроенный журнал journalctl, что избавляет от необходимости настраивать сложные перенаправления вывода.
Для базовых задач Crontab остаётся оптимальным решением. Однако для сложных корпоративных сценариев архитектура на базе Systemd является отраслевым стандартом.
❓ Часто задаваемые вопросы (FAQ)
Где найти логи ошибок, если задача Crontab не выполнилась?
В большинстве дистрибутивов логи Cron записываются в /var/log/syslog (Debian/Ubuntu) или /var/log/cron (CentOS/RHEL). Для упрощения диагностики рекомендуется добавлять перенаправление вывода в конец команды (например, >> /var/log/my_cron.log 2>&1), чтобы все ошибки и результаты сохранялись в отдельном файле.
Как запускать задачу каждые 30 секунд?
Минимальный интервал планирования Crontab — одна минута. Для запуска каждые 30 секунд создайте две записи в одной минуте, используя sleep 30 для задержки второй команды (например: * * * * * /script.sh и * * * * * sleep 30; /script.sh). Для задач с более высокой точностью используйте Systemd Timers или фоновые демоны.