Cron резервного копирования не запускается: как восстановить бэкапы

Команда, работающая в интерактивной консоли, может падать в cron из-за другого пользователя, минимального PATH, рабочего каталога, окружения и отсутствия терминала. Кроме того, сам cron может запускать задачу, но скрипт завершается ошибкой или зависает на старом lock-файле.

Сначала проверьте время последней заведомо успешной копии и сохраните текущие журналы. Запустите скрипт вручную именно под пользователем cron с очищенным окружением и получите exit code. Не удаляйте старые бэкапы для освобождения места, пока не подтверждено наличие другой восстановимой копии.

Что проверить в первую очередь

Для проблемы «задание резервного копирования cron не запускается или не создаёт новую копию» сначала зафиксируйте один воспроизводимый пример: точное время, идентификатор объекта, пользователя или операции, входные данные, версию приложения и фактический результат. Отдельно запишите ожидаемое поведение: задание выполняется под известным пользователем по проверенному расписанию, создаёт валидный артефакт, сообщает об ошибке и регулярно подтверждает успешное тестовое восстановление. Это не формальность. Без исходной точки легко принять временное совпадение за исправление, изменить сразу несколько условий и потерять возможность доказать настоящую причину сбоя.

Проверку начинайте с чтения состояния и журналов. Не запускайте массовый перерасчёт, повторную отправку, удаление записей или изменение прав на рабочей системе, пока не подготовлены резервная копия и способ отката. Секреты, токены, персональные данные и содержимое заказов в диагностические выгрузки не включайте.

• Проверьте, где объявлено задание: user crontab, system crontab, cron.d или панель управления.
• Уточните timezone и фактическое время сервера.
• Сверьте пользователя, HOME приложения, PATH и абсолютные пути команд.
• Проверьте права на скрипт, источник данных, временный каталог и хранилище назначения.
• Посмотрите свободное место, inode, quota и состояние удалённого хранилища.

Почему возникает проблема

Видимый симптом обычно находится в конце цепочки. Пользователь видит неверный статус или отказ, хотя первичная ошибка могла произойти в API, фоновой задаче, кеше, очереди, внешнем сервисе либо при проверке доступа. Основной риск этого сценария: система долго работает без актуального восстановления, а проблема обнаруживается только после потери данных. Поэтому исправление только интерфейса или ручная правка итоговой записи часто скрывает проблему, но не устраняет её.

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

• В cron используется относительный путь или команда, отсутствующая в минимальном PATH.
• Скрипт требует переменную окружения, доступную только интерактивной оболочке.
• Предыдущий процесс завис и удерживает flock.
• Пароль или ключ удалённого хранилища истёк.
• Задание выполняется, но stdout и stderr никуда не сохраняются, поэтому ошибка незаметна.

Пошаговая диагностика

Создайте безопасный тестовый сценарий, максимально похожий на проблемный, но не затрагивающий реальные списания, рассылки и клиентские данные. Присвойте операции единый correlation ID и проследите его через входящий запрос, бизнес-логику, базу, очередь и внешние интеграции. Для каждого этапа фиксируйте вход, результат, код ответа, время выполнения и номер версии записи.

Сначала подтвердите сам факт расхождения, затем последовательно исключайте уровни. Сравните рабочий и ошибочный случаи по одним и тем же полям. Проверьте часовой пояс, формат идентификаторов, порядок событий, права сервисной учётной записи и актуальность конфигурации на каждом экземпляре приложения. Если результат зависит от повторного запроса, задержки или конкретного узла, это важная часть причины, а не случайный шум.

• Проверьте журнал cron или systemd и факт старта по точному времени.
• Запустите команду через sudo -u нужного пользователя с env -i и абсолютными путями.
• Получите exit code каждого этапа dump, compression, encryption и upload.
• Проверьте активный PID и владельца lock, не удаляя lock вслепую.
• Сравните размер, checksum и список файлов последней копии с предыдущими.

Как устроить наблюдаемое резервное копирование

Успех cron означает только запуск команды. Успех бэкапа подтверждается завершённым pipeline, проверенным артефактом, внешним heartbeat и регулярным восстановлением в изолированную среду.

Надёжная реализация хранит бизнес-состояние явно и не пытается восстановить его только по экрану, случайному логу или последнему webhook. У каждого значимого действия должен быть стабильный идентификатор, понятный владелец, версия правила и проверяемый переход статуса. Повторная доставка одного события не должна создавать второе действие, а запоздавшее событие не должно возвращать объект в невозможное состояние.

• Скрипт использует абсолютные пути, строгую обработку ошибок и ненулевой exit code при сбое этапа.
• Один экземпляр защищён flock с корректной диагностикой активного процесса.
• Копия записывается во временное имя и становится завершённой атомарно.
• Локальная и удалённая копии следуют определённой политике хранения.
• Мониторинг проверяет возраст последнего успеха, а не только отсутствие сообщения об ошибке.

Как исправить проблему

Исправление разделите на небольшие обратимые изменения. Сначала устраните подтверждённую первопричину, затем восстановите повреждённые данные отдельной контролируемой процедурой. Не смешивайте выпуск нового кода и массовую коррекцию истории в одном непрозрачном запуске: для них нужны разные отчёты, критерии успеха и планы отката.

Если затронуты существующие записи, сначала сформируйте dry-run: список объектов, старое значение, предлагаемое новое значение и основание для изменения. Обновление должно быть идемпотентным, ограниченным точной выборкой и сопровождаться аудитом. Для финансовых данных, прав доступа и персональной информации предпочтительны компенсирующие записи, а не переписывание истории.

• Укажите shell, PATH и все рабочие каталоги явно.
• Перенесите секреты в защищённый источник, доступный сервисному пользователю, с процедурой ротации.
• Добавьте лог начала, завершения, длительности, размера и exit code каждого этапа.
• Исправьте flock и timeout, чтобы зависшая задача не блокировала расписание бесконечно.
• Настройте внешний alert при превышении максимального возраста успешной копии.

Безопасный порядок внедрения

• Сохраните конфигурацию, связанные записи и необходимые журналы; отдельно проверьте, что резервную копию действительно можно восстановить.
• Воспроизведите проблему на тестовом объекте и сохраните результат до изменения, чтобы после выпуска сравнить одинаковые сценарии.
• Внесите минимальное изменение под системой контроля версий, опишите причину, ожидаемый эффект, ограничения и точный способ отката.
• Прогоните нормальный сценарий, ошибочный ввод, повтор одного запроса, два параллельных запроса и временную недоступность зависимости.
• Выпустите изменение на ограниченную долю трафика или один процесс, если архитектура это позволяет, и сравните метрики со старой версией.
• Только после стабильного наблюдения выполните контролируемое исправление исторических данных и сохраните итоговый отчёт.

Как проверить результат

Один успешный пример недостаточен. Проверьте основную операцию повторно, крайние значения, одновременные действия, перезапуск процесса и восстановление после краткого сбоя сети. Результат подтверждайте не только экраном пользователя, но и состоянием базы, очереди, внешнего сервиса и журналом аудита. Особое внимание уделите тому, что система делает при повторной доставке уже обработанного события.

Критерии приёмки сформулируйте до выпуска. Каждый пункт должен давать однозначный ответ «выполнено» или «не выполнено», а не субъективную оценку. Если тест невозможно повторить автоматически, оставьте короткий регрессионный чек-лист с тестовыми данными и ожидаемыми статусами.

• Запуск под cron-пользователем с минимальным окружением завершается кодом 0.
• Искусственная ошибка dump или upload даёт ненулевой код и оповещение.
• Два параллельных запуска не повреждают один и тот же артефакт.
• Копия проходит checksum и открывается штатным инструментом.
• Тестовое восстановление создаёт рабочую изолированную базу или файловый набор.

Типичные ошибки при исправлении

• Считать наличие файла доказательством полноценного бэкапа.
• Перенаправлять stderr в пустоту.
• Хранить пароль прямо в общей строке crontab.
• Удалять lock без проверки живого процесса.
• Очищать старые копии до подтверждения новой и удалённой резервной копии.

Опаснее всего исправление, которое убирает заметный симптом ценой отключения проверки, ослабления прав или потери аудита. Такое изменение может сделать интерфейс «зелёным», но увеличить ущерб при следующем сбое. Если временный обход всё же необходим, ограничьте его срок, пользователей и область действия, добавьте мониторинг и заранее назначьте дату удаления.

Как предотвратить повторение

Профилактика строится вокруг явных контрактов, идемпотентных обработчиков, наблюдаемости и повторяемых релизов. Система должна не только корректно работать сейчас, но и быстро показывать нарушение правила после обновления, роста нагрузки или отказа интеграции. Ошибку, которая уже привела к потере времени, денег, данных или заявок, стоит закрепить автоматическим тестом.

Настройте мониторинг полного пользовательского пути, а не только доступности отдельных серверов. Техническая метрика должна быть связана с бизнес-результатом: заказ завершён, доступ выдан, файл восстановлен, событие обработано один раз, данные изолированы. Порог оповещения задавайте по нормальному профилю нагрузки и проверяйте, что уведомление содержит достаточно контекста для первого решения.

• Возраст последнего успешного артефакта относительно RPO.
• Длительность, размер и скорость загрузки копии.
• Ненулевые exit codes по этапам pipeline.
• Свободное место, inode и quota до запуска.
• Дата последнего успешного тестового восстановления и достигнутое RTO.

Что подготовить для технического разбора

• Короткое описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время возникновения, идентификатор тестового объекта и версии всех затронутых компонентов.
• Обезличенные фрагменты журналов до и после ошибки с единым correlation ID.
• Список последних изменений, результаты уже выполненных проверок и условия, при которых симптом исчезает.
• Безопасный доступ к тестовой среде либо минимальный пример, не содержащий паролей, токенов и персональных данных.

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

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

У cron другой пользователь, PATH, рабочий каталог и набор переменных. Нужно повторить запуск в таком же окружении.

Достаточно ли проверять размер файла?

Нет. Нужны checksum, проверка формата и регулярное восстановление.

Что важнее: локальный или удалённый бэкап?

Надёжная схема сочетает независимые копии и проверяет их восстановление по заданным RPO и RTO.

Когда нужна помощь специалиста

Если cron не создаёт свежие бэкапы, я могу проверить расписание, окружение, права, lock, хранилище и мониторинг и провести безопасный тест восстановления. Для оценки нужны строка задания без секретов, время последнего успеха и журналы запуска.