Job backup Accounting красный: Agent, путь E:\SQLBackup и права, не «диск ещё жив»

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

Если backup Accounting на SQL01\MSSQLSERVER не выполняется, смотрите SQL Server Agent, текст job step, права учётки службы SQL/Agent на путь (E:\SQLBackup или \\backup\sql), свободное место и не держит ли файл антивирус. Расписание в календаре не равно файлу на диске. Пока log backup мёртв в Full, лог будет расти (переполнение журнала).

Не «починяйте» backup ручным BACKUP в тот же файл, который сейчас пишет Veeam, без понимания блокировки.

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

Типичная картина:

• Job Backup Accounting Full Failed;
• каталог пустой или файл вчерашний;
• 3201 / 3013 в логе job;
• Agent Stopped после патча.

Отличия:

Возможные причины

1. SQLSERVERAGENT не запущен.
2. Путь не существует, SMB share offline.
3. Учётка NT Service\MSSQLSERVER / Agent не имеет NTFS/share Modify.
4. Диск backup заполнен.
5. Maintenance Plan пишет в устаревший путь.
6. Одновременно два backup на один файл WITH INIT.
7. Ошибка 3041/3231 — база offline/suspect.
8. Редко: xp_backup стороннего агента, лицензия модуля.

Диагностика

1. Служба и job

Get-Service MSSQLSERVER, SQLSERVERAGENT | Format-Table Name, Status

В SSMS: Job Activity Monitor, View history, шаг. Копируйте полный текст.

2. История в msdb

SELECT TOP 20 database_name, type, backup_start_date, backup_finish_date,
       physical_device_name
FROM msdb.dbo.backupset bs
JOIN msdb.dbo.backupmediafamily bf ON bs.media_set_id = bf.media_set_id
WHERE database_name = N'Accounting'
ORDER BY backup_finish_date DESC;

3. Место и доступ

Get-Item E:\SQLBackup -ErrorAction SilentlyContinue
Get-Volume -FilePath E:\SQLBackup
# с машины SQL01
New-Item -ItemType File -Path 'E:\SQLBackup\perm-test.txt' -Force
Remove-Item 'E:\SQLBackup\perm-test.txt'

Для UNC — тот же тест под учёткой службы (psexec/PsExec осторожно, или SQL BACKUP в тестовый файл).

4. Ручной backup в окно

BACKUP DATABASE [Accounting]
TO DISK = N'E:\SQLBackup\Accounting_manual_test.bak'
WITH COPY_ONLY, COMPRESSION, STATS = 10;

COPY_ONLY для full, чтобы не сломать diff-цепочку, если вы только проверяете права.

Решение

Сценарий A. Agent Stopped

Start-Service SQLSERVERAGENT

Разберитесь, почему не Automatic. Job не «сам по себе».

Сценарий B. Права и путь

Создайте каталог, ACL: служба SQL и Agent — Modify. На SMB: не гостевой доступ; отдельная учётка backup. Не давайте Everyone Full.

Сценарий C. Место

Очистка старых .bak по политике retention после проверки, что offsite есть. Не delete last full.

Сценарий D. Job

Исправьте шаг: корректное имя базы Accounting, CHECKSUM желателен, сжатие. Разведите full и log. Если используете сторонний агент — его лог, не только msdb.

Сценарий E. Конфликт с 1С

Backup в прайм грузит диск — это не «failed», это медленно. Перенесите окно. Если failed по timeout — увеличьте время job, не выключайте backup.

Контур Accounting: как встроить backup в жизнь 1С

Назначьте один хозяин цепочки: native Agent или Veeam SQL-aware, не оба full без COPY_ONLY. Если Veeam делает full, native log должен быть согласован с этим продуктом (часто Veeam сам бэкапит log). Смешение даёт «restore не от этой цепочки» в день аварии.

Проверяйте не только Failed, но и «job не стартовал»: Agent hung, расписание отключено после обслуживания, ручной Disable «на обновление 1С» и забыли Enable. В чеклисте после обновления — пункт «backup job включён, первый log после окна прошёл».

Права: службе SQL нужно писать в каталог backup, учётке 1С — нет. Если backup вдруг заработал только после добавления 1С в sysadmin, вы лечили не то: разберитесь с ACL каталога.

E:\SQLBackup на том же datastore, что MDF — риск. Вынесите. Retention-скрипт не должен удалять последний успешный full, даже если он «старше N дней», пока нет более нового successful. Кодируйте «удалять только если есть newer full».

SELECT MAX(backup_finish_date) AS last_full
FROM msdb.dbo.backupset
WHERE database_name = N'Accounting' AND type = 'D' AND is_copy_only = 0;

Алерт: last_full старше 26 часов (при ночном full) — тикет, не ожидание 9002.

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

• History job Succeeded.
• backupset сегодня.
• Файл ненулевого размера.
• Разовый restore на Accounting_restore (см. статью restore и как резервировать SQL 1С).

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

• 3013 + I/O — диск backup, не 1С.
• VSS timeout — исключить SQL writer conflicts, не отключать SQL VSS Writer насовсем без замены метода.
• Права sysadmin у 1С не нужны для backup; службе SQL — да на файл.

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

• Алерт: нет successful full за N часов, нет log за M минут.
• Retention + мониторинг свободного места backup.
• Agent Automatic, мониторинг службы.
• Документ цепочки full/diff/log.

Проверяйте цепочку глазами календаря: full в 02:00, log каждые 30 минут, нет дыр после Disable на обновлении. Сверьте is_copy_only в backupset: если все full — COPY_ONLY, diff бесполезен, а вы думаете, что восстанавливаетесь за час. Native job и Veeam не должны молча писать в один и тот же .bak с INIT. Каталог E:\SQLBackup\Accounting\ с датой в имени проще, чем один файл на год. После смены пути поправьте оба шага full и log, иначе log 3201, а full зелёный — типичная причина утреннего 9002. Раз в месяц отдайте DBA 15 минут на RESTORE VERIFYONLY свежего full и на проверку, что Agent всё ещё Automatic.

FAQ

Job зелёный, файла нет.

Другой путь, другой сервер, NUL device, или смотрите не ту шару. physical_device_name в msdb.

Можно ли бэкапить с пользовательской учётки 1С?

Не нужно. Backup — задача Agent/админа. Учётке 1С не sysadmin.

COPY_ONLY vs обычный full.

Обычный full сдвигает цепочку diff. Для проверки прав — COPY_ONLY. Для РК — штатный full по политике.

Нужен ли backup log, если есть ночной full?

В Full — да, иначе лог и RPO. См. резервирование SQL-базы 1С.

Backup через 1С «выгрузить в DT» заменяет SQL?

Нет как единственная стратегия клиент-серверной базы.