Рассмотрим распространенную, но неочевидную проблему, с которой сталкиваются администраторы баз данных: внезапное появление дубликатов файлов бэкапа при использовании стандартных планов обслуживания (Maintenance Plans) в SQL Server. Ситуация часто выглядит так: настроенное задание должно запускаться один раз в сутки, но в папке с архивами обнаруживается два, а иногда и три файла за одну и ту же дату с разницей в несколько минут или часов. Проанализируем причины этого поведения и разберем по шагам способы решения.
Для начала разберем механизм работы планировщика SQL Server Agent. Этот компонент постоянно мониторит системное время сервера и сопоставляет его с расписанием заданий. Если в какой-то момент системное время «прыгает» назад, планировщик видит, что текущее время снова попадает в интервал запуска задания, которое (с точки зрения обновленного времени) еще не выполнялось. В результате SQL Server Agent инициирует повторный запуск плана обслуживания.
Проанализируем ситуацию: если бэкап настроен на 21:30, а в 21:45 системное время сервера корректируется и откатывается на 21:25, то через 5 минут планировщик снова увидит наступление времени 21:30 и запустит архивацию второй раз. Именно поэтому в логах мы видим несколько успешных выполнений одного и того же задания за короткий промежуток времени.
Чтобы подтвердить теорию о скачках времени, нам необходимо обратиться к журналам Windows. Разберем, на что именно стоит обратить внимание:
Microsoft-Windows-Kernel-General и коду события (Event ID) 1.Если мы увидим записи следующего вида, значит, проблема найдена:
Имя журнала: System
Источник: Microsoft-Windows-Kernel-General
Код события: 1
Описание: Системное время изменено с 2022-11-30T11:25:27 на 2022-11-30T09:20:59.
Причина изменения: Время изменено приложением или компонентом системы.
Обратите внимание на поле ProcessID в XML-представлении события. Часто за корректировку времени отвечает служба W32Time (работающая под процессом svchost.exe), которая пытается синхронизировать сервер с внешним источником или контроллером домена.
Проанализируем ситуацию, характерную для виртуальных машин (Hyper-V, VMware). В таких средах часто возникает конфликт «двух хозяев», когда виртуальный сервер получает команды на корректировку времени одновременно из двух источников:
Если время на физическом хосте и на контроллере домена различается хотя бы на несколько секунд, виртуальная машина начинает постоянно «метаться» между этими значениями, провоцируя повторные запуски заданий 1С и SQL.
Если ваш SQL-сервер развернут на платформе Hyper-V, выполним следующие действия для стабилизации времени:
После этого сервер перестанет брать время от физического хоста и будет полагаться только на доменную иерархию времени, что исключит скачки.
Рассмотрим, как правильно настроить синхронизацию времени внутри самой операционной системы, чтобы избежать резких прыжков. Windows умеет подстраивать время плавно, не переводя стрелки, а чуть замедляя или ускоряя ход системных часов. Однако это происходит только при небольших расхождениях.
Выполним в командной строке (от имени администратора) команду для проверки текущего источника времени:
w32tm /query /source
Если мы видим Local CMOS Clock или VM IC Time Synchronization Provider, это может быть признаком нестабильности. Для корректной настройки в доменной среде рекомендуется использовать следующую последовательность команд:
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync
Важный момент: Если сервер является рядовым членом домена, он должен синхронизироваться с контроллером домена. В этом случае используйте:
w32tm /config /syncfromflags:domhier /update
Проанализируем, почему стабильное время критически важно не только для бэкапов SQL, но и для функционирования систем на базе 1С:Предприятие:
Подведем итог нашему разбору. Если вы заметили дублирование архивов бэкапов, не спешите перенастраивать планы обслуживания SQL. Скорее всего, проблема кроется в инфраструктуре. Проверьте системные логи на наличие событий изменения времени. Помните, что в виртуальной среде лучше оставить только один источник синхронизации — либо доменную иерархию, либо службы интеграции гипервизора, но никогда не оба сразу.
Для мониторинга ситуации в будущем можно настроить оповещение в SQL Agent, которое будет срабатывать, если задание запускается чаще, чем предусмотрено регламентом, что позволит оперативно отреагировать на проблемы с таймингом сервера.