Резервное копирование баз данных 1С на сетевые ресурсы — это стандартная задача для системного администратора, обеспечивающая дополнительный уровень безопасности данных. Однако при реализации этой задачи часто возникают сложности, связанные с правами доступа, сетевыми протоколами и производительностью. В этой статье мы подробно разберем, как правильно настроить MS SQL Server для работы с сетевыми папками, какие учетные записи использовать и как оптимизировать процесс передачи данных.
Разберем фундаментальный аспект: под какой учетной записью работает ваш SQL Server. По умолчанию служба может запускаться под локальной системной учетной записью (например, NT Service\MSSQLSERVER). Проблема заключается в том, что эта учетная запись не имеет прав доступа к ресурсам в доменной сети. Проанализируем варианты решения этой задачи.
Многие начинающие администраторы пытаются сменить пользователя службы на обычного «пользователя домена». Это рабочее решение, но оно не является безопасным. Рассмотрим более современный и правильный подход — использование Managed Service Accounts (MSA) или group Managed Service Accounts (gMSA).
Основные преимущества gMSA в доменной среде:
gMSA можно использовать для целого кластера серверов.Важно помнить: бэкапы выполняются самим ядром СУБД (Database Engine), а не SQL Server Agent (хотя агент инициирует задание). Поэтому права на сетевую шару должны быть выданы именно учетной записи, под которой запущена основная служба sqlservr.exe.
Выясним причину, по которой SQL Server часто «не видит» сетевой диск Z: или X:. Дело в том, что сетевые диски подключаются в контексте сессии конкретного пользователя. Служба SQL Server работает в своей изолированной сессии, где никаких «букв дисков» не существует.
Рассмотрим правильный способ указания пути. Всегда используйте полные UNC-пути. Формат команды в SQL Management Studio (SSMS) будет выглядеть следующим образом:
BACKUP DATABASE [Trade_DB]
TO DISK = '\\BackupServer\SqlBackups\Trade_Full.bak'
WITH FORMAT, STATS = 10;
Если вам все же необходимо использовать логическую букву диска (что крайне не рекомендуется), придется использовать системную процедуру xp_cmdshell для маппинга диска внутри контекста SQL, но это создает серьезную брешь в безопасности сервера.
Проанализируем ситуацию, когда нам нужно иметь копию бэкапа и локально (для быстрого восстановления), и в сети (для отказоустойчивости). Вместо того чтобы сначала делать бэкап, а потом копировать его скриптами, мы можем использовать встроенную возможность MIRROR TO.
Эта функция доступна в редакции Enterprise и позволяет записывать данные одновременно в несколько мест. Рассмотрим пример кода:
BACKUP DATABASE [Buh_DB]
TO DISK = 'D:\LocalBackups\Buh_Full.bak'
MIRROR TO DISK = '\\NetworkStorage\Backups\Buh_Full.bak'
WITH FORMAT, CHECKSUM;
В этом случае SQL Server сам гарантирует, что обе копии идентичны. Если запись в одно из мест прервется из-за ошибки сети, вся операция будет считаться неуспешной, что позволит вам вовремя узнать о проблеме.
Посмотрим на проблему производительности. Сеть — это всегда «узкое горлышко». Чтобы ускорить процесс и избежать таймаутов, мы можем подсказать SQL Server, как эффективнее упаковывать данные для передачи по сетевому каналу. Разберем два ключевых параметра:
Пример оптимизированной команды:
BACKUP DATABASE [ERP_DB]
TO DISK = '\\HighSpeedStorage\Share\ERP.bak'
WITH COPY_ONLY, STATS = 5,
MAXTRANSFERSIZE = 4194304,
BUFFERCOUNT = 50;
Выясним, как бороться с мнением о «ненадежности сети». При передаче больших файлов по протоколу SMB возможны редкие, но критичные ошибки. Для защиты от поврежденных бэкапов крайне важно использовать флаг WITH CHECKSUM.
При использовании этого флага SQL Server выполняет следующие действия:
Рассмотрим эстетический вопрос, поднятый в обсуждении: стоит ли дописывать бэкапы логов в один и тот же файл (инкрементально) или создавать кучу мелких файлов?
Рекомендация: Делайте отдельные файлы для каждой транзакции. Проанализируем почему:
Robocopy).Типовая схема для 1С баз среднего размера:
Если вы делаете бэкап журналов транзакций каждые 5-10 минут, журнал событий SQL Server (Error Log) очень быстро заполнится сообщениями об успешных операциях. Это затрудняет поиск реальных ошибок.
Разберем использование флага трассировки -T3226. Этот параметр подавляет запись успешных сообщений о бэкапе в лог. Мы рекомендуем добавить его в параметры запуска службы SQL Server, чтобы в журнале оставались только важные системные оповещения.
Напоследок затронем вопрос инфраструктуры. Если ваш сервер БД и файловое хранилище работают на Windows Server 2012 или выше, вам доступен протокол SMB 3.0. Постарайтесь убедиться, что между серверами включена функция SMB Multichannel. Она позволяет агрегировать пропускную способность нескольких сетевых адаптеров, что делает бэкап по сети практически таким же надежным и быстрым, как запись на локальный массив дисков.
Подведем итог: для успешного и надежного сохранения бэкапов в сеть необходимо использовать gMSA аккаунты, полные UNC-пути, обязательную проверку CHECKSUM и правильную стратегию ротации файлов. Такой комплексный подход гарантирует сохранность данных вашей системы 1С.