Разберем ситуацию, когда пользователи обнаруживают исчезновение данных в базе 1С, работающей на SQL Server, после ежедневных откатов, которые изначально были вызваны несанкционированным горячим рестартом. Эта проблема может проявляться как периодическое исчезновение документов, созданных за предыдущий день, и восстановление состояния базы данных на более ранний момент времени. Подобные «чудеса» часто указывают на системные проблемы за пределами самой 1С или SQL Server, чаще всего связанные с инфраструктурой виртуализации.
Первоначальные наблюдения включают в себя исчезновение документов, которые были созданы и записаны в базу данных 1С (Управление Торговлей 10.3) после «горячего» рестарта сервера. Изначальный инцидент был спровоцирован сбоем, приведшим к изменению системного времени сервера. После корректировки времени и нормальной перезагрузки сервера проблема, казалось бы, исчезла, но через день обнаружилось, что все документы, созданные после того инцидента, пропали. На следующий день история повторилась, и исчезли уже данные за предыдущий день, при этом полностью появились все данные, сделанные еще раньше. Это очень похоже на откат к какой-то точке сохранения.
Давайте посмотрим на первоначальные предположения, которые мы можем сразу исключить или подтвердить.
Все эти признаки указывают на то, что проблема находится за пределами прикладного уровня 1С и даже за пределами самого SQL Server. Необходимо искать причину на уровне операционной системы или инфраструктуры.
Подозрение на внешний откат системы возникло довольно быстро, особенно когда речь зашла о виртуальных машинах. Рассмотрим по шагам, как мы пришли к окончательной диагностике:
Эти шаги позволяют нам сделать однозначный вывод: проблема заключается в ежедневном откате всей виртуальной машины к предыдущему состоянию.
На основе всей собранной информации мы можем с высокой степенью уверенности заявить, что причина проблемы кроется в действиях хостинг-провайдера. Наиболее вероятно, что ваш провайдер арендованного сервера настроил автоматический ежедневный откат виртуальной машины к предыдущему состоянию, возможно, с использованием снимков (snapshots) или путем восстановления из резервной копии по регламенту. Один из участников прямо указал: "очень похоже, что зеркало накатывается по регламенту каждое утро". Вы также подтвердили, что проблема 100% не в 1С, и не в SQL, а именно в откате всей системы.
Такая практика может быть применена для определенных типов сервисов (например, тестовых сред, публичных киосков или демонстрационных стендов), где требуется, чтобы система каждый день загружалась в "чистом" первоначальном состоянии. Однако для продуктивного рабочего сервера, на котором сохраняются критически важные данные, это совершенно недопустимо и является грубейшей ошибкой в конфигурации со стороны провайдера.
Давайте подробнее рассмотрим, по каким причинам виртуальные машины могут откатываться, и какие механизмы стоят за этим явлением. Понимание этих механизмов поможет в диалоге с провайдером.
Снимки, или снапшоты, — это одна из наиболее распространенных функций виртуализации. Они позволяют зафиксировать состояние виртуальной машины (ВМ) в определенный момент времени. После создания снимка все изменения, вносимые в ВМ, записываются в отдельный файл (дифференциальный диск), а исходный диск остается неизменным. При откате к снимку все изменения, сделанные после его создания, отменяются, и ВМ возвращается к состоянию на момент снимка. Хостинг-провайдеры могут использовать снимки для быстрого восстановления или предоставления "чистой" среды каждый день. Зачастую это делается без ведома клиента или с неясными условиями. Чрезмерное использование снимков на высоконагруженных ВМ, таких как серверы баз данных, может привести к проблемам с производительностью и заполнению хранилища, а также к потере данных, если снимки используются для отката к предыдущим состояниям.
В некоторых гипервизорах, например, VMware ESXi, существует возможность настроить виртуальные диски как "независимые и непостоянные" (independent and non-persistent). В этом режиме все изменения, записанные на такой диск, отбрасываются при выключении или перезагрузке ВМ. Таким образом, ВМ всегда загружается в исходном состоянии, которое было на момент последней полной записи на диск. Эта настройка может быть применена для тестовых сред или для публичных терминалов, где важно всегда иметь свежую и неизменную установку. Если ваш провайдер использовал эту настройку для диска с операционной системой и/или данными, это является прямой причиной еженощных откатов.
В облачных или хостинг-средах часто применяются механизмы автоматического восстановления ВМ после сбоев физического оборудования. Если физический сервер, на котором работает ВМ, выходит из строя, ВМ может быть автоматически перенесена на другой сервер или перезапущена. В редких случаях, при определенных, некорректных конфигурациях, этот процесс может включать восстановление ВМ из предыдущей копии или снимка, особенно если исходная машина была повреждена, а восстанавливается некий "золотой" образ.
Человеческий фактор является одной из наиболее частых причин потери данных в виртуальных средах. Ошибочное удаление ВМ, неправильная настройка, запуск неверного регламентного задания или восстановление не той резервной копии могут привести к полной или частичной потере данных, а также к эффекту отката. В вашем случае, упомянутый "горячий рестарт" из-за действий провайдера уже является подтверждением проблем с управлением инфраструктурой.
Если система резервного копирования провайдера работает некорректно или по какой-то причине ежедневно восстанавливает устаревшие копии (например, из-за ошибки в расписании или неверно настроенного процесса), это может приводить к постоянному откату системы к прошлому состоянию. Некоторые системы резервного копирования сами по себе используют снимки, и проблемы с ними (например, повреждение цепочки снимков) также могут вызвать потерю данных.
Аппаратные сбои дисков, контроллеров или сетевого хранилища (SAN/NAS) на хост-сервере могут приводить к потере данных на ВМ. В сложных виртуализированных средах, использующих дедупликацию и сжатие данных, ошибки на уровне хранилища могут проявляться непредсказуемо, включая частичную потерю или откат данных, если система пытается восстановиться из поврежденных блоков.
Перемещение ВМ между физическими хостами (live migration) в некоторых случаях может вызвать временную потерю связи или некорректное завершение текущих операций, что теоретически может привести к сбоям. Хотя это реже приводит к полному откату системы, подобные инциденты могут усугублять общую нестабильность среды.
Учитывая все эти факторы, мы можем с уверенностью сказать, что проблема лежит в плоскости управления виртуальной инфраструктурой со стороны хостинг-провайдера.
Хотя проблема с откатом ВМ является основной, вопросы о настройке часового пояса также возникали в ходе обсуждения. Некорректная настройка часового пояса на сервере или в SQL Server может вызывать расхождения во времени и путаницу в отображении данных, хотя и не приводит к их потере. Тем не менее, это полезная диагностическая процедура, которую стоит уметь выполнять.
Вы пытались использовать функцию CURRENT_TIMEZONE() в SQL Server, но получили ошибку 'CURRENT_TIMEZONE' is not a recognized built-in function name. Это произошло потому, что данная функция доступна только в более новых версиях SQL Server (начиная с SQL Server 2017). В вашем случае, SQL Server 2008 R2, для получения информации о часовом поясе сервера необходимо использовать другой подход, который обращается к системному реестру Windows, где хранится эта информация.
Мы можем получить название текущего часового пояса, выполнив следующий запрос:
DECLARE @TimeZone VARCHAR(50);
EXEC MASTER.dbo.xp_regread 'HKEY_LOCAL_MACHINE',
'SYSTEM\CurrentControlSet\Control\TimeZoneInformation',
'TimeZoneKeyName', @TimeZone OUT;
SELECT @TimeZone AS CurrentTimeZone;
Этот запрос использует расширенную хранимую процедуру xp_regread для чтения значения из реестра Windows. В вашем случае этот запрос вернул "Russian Standard Time", что является корректным названием часового пояса, используемого в России. Таким образом, хотя проблема с часовым поясом была рассмотрена, она не является причиной потери данных, но это хороший пример общей диагностики.
Основное решение проблемы лежит в коммуникации с вашим хостинг-провайдером. Вот наши рекомендации:
Это самый важный шаг. Вы уже убедились, что проблема не в 1С или SQL, а в инфраструктуре. Объясните им ситуацию, предоставив все факты: ежедневный откат данных в 1С, исчезновение любых файлов, сохраненных на сервере в течение дня, и точное время, когда это происходит. Требуйте детального объяснения происходящего и подтверждения, используют ли они снимки, настроены ли ежедневные восстановления, или есть ли проблемы с их кластером или оборудованием. Запросите, чтобы они отключили любые автоматические откаты или восстановления, которые не соответствуют вашим требованиям к продуктивному серверу.
Потеря данных — это критически серьезная ситуация для любого бизнеса. Поскольку проблема вызвана действиями провайдера, вы имеете полное право требовать немедленного устранения неисправности и, возможно, компенсации за потерю данных и простои в работе. Уточните условия договора об уровне обслуживания (SLA), если таковой имеется.
Независимо от того, что ответит провайдер, крайне важно иметь собственные регулярные бэкапы базы данных 1С и всех важных файлов, сохраняемые вне виртуальной машины или даже у другого провайдера. Это позволит восстановить данные в случае проблем с текущим хостинг-провайдером или любых других непредвиденных ситуаций. Рассмотрите использование штатных средств резервного копирования SQL Server (планы обслуживания) для создания полных и дифференциальных бэкапов.
Мы рекомендуем настроить регулярное резервное копирование базы данных SQL Server, например, с помощью SQL Server Management Studio (SSMS) с использованием планов обслуживания. В рамках плана обслуживания можно создать задание, которое будет выполнять резервное копирование вашей базы данных в указанное место.
-- Пример SQL команды для полного резервного копирования базы данных
BACKUP DATABASE [ВашаБаза1С]
TO DISK = N'D:\SQL_Backups\ВашаБаза1С_Full_$(ESCAPE_SQUOTE(REPLACE(REPLACE(REPLACE(CONVERT(NVARCHAR(20), GETDATE(), 120), '-', ''), ':', ''), ' ', '_'))).bak'
WITH NOFORMAT, NOINIT, NAME = N'ВашаБаза1С-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO
Замените [ВашаБаза1С] на реальное имя вашей базы данных и D:\SQL_Backups\ на путь к вашей папке для бэкапов. Важно, чтобы эта папка находилась на диске, который не подвергается откатам, или чтобы сами резервные копии регулярно копировались на внешнее хранилище.
Недостаточно просто создавать бэкапы; необходимо регулярно тестировать их работоспособность путем восстановления на отдельной тестовой машине или в изолированной среде. Это гарантирует, что в случае реальной катастрофы вы сможете восстановить данные.
Помните, что снимки ВМ для SQL Server поддерживаются корректно только при использовании технологии VSS (Volume Shadow Copy Service), которая обеспечивает согласованное состояние приложения при создании снимка. Любая другая технология снимков, которая не взаимодействует с приложениями гостевой ОС через VSS, может привести к некорректному или поврежденному состоянию SQL Server после восстановления из такого снимка. Это еще одна причина, по которой провайдер должен быть внимателен к конфигурации.
В конечном итоге, разрешение этой проблемы полностью зависит от действий вашего хостинг-провайдера. После того как вы предоставите им неопровержимые доказательства, они будут обязаны либо изменить конфигурацию вашей виртуальной машины, либо предложить другое решение, соответствующее вашим потребностям в сохранении данных.