Короткий ответ

Клиент-серверная Accounting на SQL01\MSSQLSERVER резервируется SQL Backup, не DT. Модель FULL, full (и опционально diff) + регулярный BACKUP LOG с периодом = ваш RPO. WITH CHECKSUM, сжатие, отдельный том, мониторинг job Agent. Раз в месяц (лучше чаще) restore на другое имя и открытие 1С. DT и выгрузка конфигурации — в дополнение к обновлениям, не вместо СУБД.

Симптомы и как отличить

Плохой процесс:

  • один .bak по пятницам;
  • recovery SIMPLE, log backup нет;
  • restore никогда не пробовали;
  • backup на тот же диск, что MDF.

Файловая база — другая статья. Job красный — backup не выполняется.

Возможные причины, почему «вроде есть backup», а защиты нет

  1. Full есть, log нет → RPO = ночь, лог растёт.
  2. COPY_ONLY каждый день ломает голову, diff бесполезен.
  3. Нет места, job падает тихо.
  4. Нет restore-теста.
  5. Нет offsite.

Диагностика политики

SELECT name, recovery_model_desc FROM sys.databases WHERE name = N'Accounting';

SELECT TOP 20 backup_start_date, type, backup_size/1024/1024 AS mb, name
FROM msdb.dbo.backupset
WHERE database_name = N'Accounting'
ORDER BY backup_start_date DESC;

type: D full, I diff, L log. Нарисуйте покрытие суток.

Get-Service SQLSERVERAGENT
Get-Volume -FilePath E:\SQLBackup

Решение

1. Recovery и цепочка

ALTER DATABASE [Accounting] SET RECOVERY FULL;
BACKUP DATABASE [Accounting]
TO DISK = N'E:\SQLBackup\Accounting_full_init.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

Дальше log по расписанию (15–60 мин типично для учёта; согласуйте RPO).

BACKUP LOG [Accounting]
TO DISK = N'E:\SQLBackup\Accounting_log.trn'
WITH COMPRESSION, CHECKSUM;

Для регулярных log лучше уникальное имя с timestamp в job, не один файл WITH INIT без политики.

2. Job Agent

  • Full: ночь, дни недели по объёму.
  • Diff: день, если full тяжёлый.
  • Log: каждые N минут.
  • Уведомление на fail.
  • Учётка Agent пишет в E:\SQLBackup (права — не sysadmin 1С).

3. Пример шага full

DECLARE @f nvarchar(4000) =
  N'E:\SQLBackup\Accounting_' + CONVERT(char(8), GETDATE(), 112) + N'_full.bak';
BACKUP DATABASE [Accounting] TO DISK = @f
WITH COMPRESSION, CHECKSUM, STATS = 10;

Retention: удаление старше N дней после копирования offsite.

4. Restore-тест

По restore: другое имя, MOVE, открыть отдельной инфобазой на SRV-1C (тест-кластер/другой порт) без сети к прод-оборудовании если это копия прод-данных в том же VLAN — лучше изолировать. Минимум: RESTORE VERIFYONLY недостаточно как единственная проверка, но лучше, чем ничего; цель — RESTORE + 1С.

RESTORE VERIFYONLY FROM DISK = N'E:\SQLBackup\Accounting_full_init.bak' WITH CHECKSUM;

5. 1С в окне backup

Full в пик склада тормозит диск. Ночь. Не выгоняйте пользователей ради native backup (он online), но не стартуйте реструктуризацию одновременно.

Контур SQL01 + SRV-1C: RPO, окна и 1С

Согласуйте с бизнесом: сколько часов учёта готовы вводить заново. Это период log backup. Ночной только full при работе 8–20 означает RPO до 24 часов — для многих бухгалтерий неприемлемо.

Окна: full не в проведение зарплаты и не в закрытие месяца, если диск общий. Регламент 1С и index rebuild не вместе с full на одном LUN.

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

msdb и master бэкапьте: jobs и логины. Иначе через год вы поднимете Accounting, а Agent пустой.

Шифрование носителя и доступ: каталог backup не из пользовательских сетей. Учётка Agent — не 1С.

Документ restore: пути MOVE для этого SQL01, logical names, где сертификат, кто имеет право REPLACE. Это читают в 3 часа ночи.

Если диск backup медленный, full удлиняется и пересекается с утром: compression, быстрее диск, не отказ от CHECKSUM. COPY_ONLY для «унести на флешку перед обновлением» — да, плюс штальная цепочка продолжает жить.

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

  • recovery_model_desc = FULL.
  • В msdb есть свежие D и L.
  • Restore-тест открыл документы.
  • Алерт, если log старше SLA.
  • Offsite.

Если не помогло

  • Job fail — статья про невыполнение backup.
  • 9002 — log backup не работал, чините job, не Simple в панике без решения.
  • Слишком долго full — compression, быстрее диск backup, diff, не отказ от log.

Профилактика

  • RPO/RTO на бумаге.
  • Мониторинг msdb и места E:.
  • Перед обновлением 1С — лишний full, подготовка.
  • Backup master/msdb тоже.

Сведите политику к таблице: full ежедневно 02:00, log каждые 30 минут, retention full 14 дней локально плюс offsite, restore-тест раз в месяц на Accounting_restore, CHECKSUM включён, Agent Automatic, алерт по msdb. После смены дисков поправьте MOVE-инструкцию в runbook. Не считайте RESTORE VERIFYONLY полным тестом: 1С должна открыть копию. Не кладите цепочку только на SQL01. Перед закрытием месяца сделайте лишний full, не отменяйте log. Если Veeam — один хозяин log, native не конкурирует. Простой 1С для native backup не требуется; простой нужен для restore и для файловой базы, не путайте.

Прогон restore-теста оформите как повторяемый runbook: имя файла full, список log, MOVE на D:\SQL\RestoreTest, имя базы Accounting_restore, запрет инфобазы пользователям, открытие 1С, CHECKDB, удаление тестовой базы после скрина. Если тест боятся делать из-за места — выделите том теста, иначе у вас нет резервирования, есть надежда. Следите за log_reuse_wait_desc после внедрения log backup: должно стать NOTHING между job, не вечный LOG_BACKUP. Это проверка, что цепочка действительно живая, не только что job зелёный.

FAQ

Native vs Veeam.

Оба ок, если есть log-aware backup SQL и test restore. Не два full конкурирующих без понимания COPY_ONLY.

Нужен ли backup log при Veeam full каждый час?

Если Veeam режет цепочку native — определите один хозяин цепочки. Смешение без COPY_ONLY ломает restore.

DT раз в день с регламента 1С.

Дополнение. Не единственный backup SQL-базы.

CHECKSUM замедляет.

Приемлемо для учёта. Без checksum позже узнаете о битом bak в день пожара.

Сколько хранить trn?

Пока не отпадёт нужда в STOPAT внутри этого окна + копия full. Типично дни–недели log + месяцы full, как скажет бизнес.