Бекапы 1С: Модель восстановления — Полная (Full) против Простой (Simple)

← На главную

При администрировании баз данных 1С на платформе Microsoft SQL Server одним из ключевых вопросов является выбор модели восстановления (Recovery Model). Зачастую возникают споры: стоит ли использовать Simple для экономии места или переходить на Full для обеспечения максимальной сохранности данных. Рассмотрим подробно технические нюансы, мифы и практические рекомендации по настройке стратегии резервного копирования.

Понятие моделей восстановления и их влияние на работу 1С

Для начала разберем, что именно меняют эти режимы в поведении сервера. Модель восстановления определяет, как SQL Server управляет журналом транзакций (LDF-файлом).

Простая модель (Simple): В этом режиме пространство в журнале транзакций автоматически освобождается после завершения каждой транзакции (точнее, после прохождения контрольной точки — Checkpoint). Мы не можем делать бэкап лога, а значит, можем восстановить базу только на момент создания полного или дифференциального бэкапа.
Полная модель (Full): Все изменения записываются в журнал и хранятся там до тех пор, пока не будет сделан бэкап лога транзакций. Это позволяет восстановить базу на любой момент времени (Point-in-time recovery).
Модель с неполным протоколированием (Bulk-Logged): Промежуточный вариант, который ведет себя как Full, но минимально записывает массовые операции (например, создание индексов).

Развенчиваем мифы о росте логов и нехватке памяти

Проанализируем аргумент из обсуждения: "логи растут очень быстро и занимают всю память". Здесь важно разделить два понятия: дисковое пространство и оперативная память.

Миф о памяти: SQL Server использует оперативную память (Buffer Pool) в основном для кэширования страниц данных, а не файлов лога. Лог транзакций — это последовательная запись на диск. Рост файла лога .ldf критически влияет на свободное место на дисках и нагрузку на дисковую подсистему (IOPS), но не является прямой причиной нехватки оперативной памяти сервера.

Проблема роста лога: В модели Full лог действительно растет бесконтрольно, если не настроено задание BACKUP LOG. Многие ошибочно полагают, что создание полного бэкапа базы очищает лог. Это не так. В полной модели только бэкап лога помечает место внутри файла лога как свободное для повторного использования. Если выполнять BACKUP LOG каждые 15 минут, файл лога перестанет расти и зациклится внутри выделенного ему объема.

Выбор модели на основе требований бизнеса: RPO и RTO

Прежде чем выбирать техническую настройку, выясним требования бизнеса к доступности данных. Для этого используем два параметра:

RPO (Recovery Point Objective): Допустимый объем потери данных. Если бизнес говорит, что потеря 1 часа работы 50 бухгалтеров — это катастрофа, то Simple модель нам не подходит. В Full модели, делая бэкапы логов каждые 10–15 минут, мы минимизируем потери до этого интервала.

RTO (Recovery Time Objective): Время, за которое мы должны поднять базу после аварии. Восстановление цепочки логов в модели Full может занять больше времени, чем просто разворачивание одного полного бэкапа в модели Simple.

Практические советы по работе с моделью Full

Разберем по шагам, как правильно эксплуатировать полную модель восстановления для баз 1С объемом 100–250 ГБ и выше:

1. Настройка регламентных заданий: Необходимо создать цепочку заданий в SQL Agent: - Полный бэкап (раз в сутки, ночью). - Дифференциальный бэкап (каждые 4–6 часов в течение дня). - Бэкап лога транзакций (каждые 10–30 минут).

2. Проблема виртуальных лог-файлов (VLF): Если файл лога растет мелкими приращениями (например, по 10 МБ), внутри создаются тысячи VLF. Это сильно замедляет работу 1С и процесс восстановления. Проанализируем ситуацию: рекомендуется сразу "прогреть" лог, выделив под него фиксированный объем (например, 20–30% от размера БД) одним куском.

3. Бэкап "хвоста" лога (Tail-Log Backup): Это важнейшее преимущество полной модели. Если файл данных .mdf поврежден, но диск с логом .ldf жив, мы можем сделать бэкап хвоста лога и восстановиться вообще без потери данных, до последней секунды перед аварией.

Когда стоит использовать простую модель (Simple)?

Рассмотрим ситуации, когда Simple оправдана:

Тестовые базы и базы разработки: Где данные не имеют критической ценности и часто обновляются из копий.
Низкая интенсивность работы: Если в базе работает один человек и он готов раз в день перевнести данные в случае сбоя.
Ресурсоемкие операции: При выполнении массовой реструктуризации или обновлении крупных конфигураций (ERP, УПП) логи в модели Full могут раздуться до терабайтов. В таких случаях опытные админы временно переводят базу в Simple, делают обновление, а затем возвращают Full и делают полный бэкап.

Использование модели Bulk-Logged для 1С

Посмотрим на модель с неполным протоколированием. Она полезна для регламентных операций. Рассмотрим пример выполнения переиндексации:


-- Перевод в Bulk-Logged перед обслуживанием индексов
ALTER DATABASE [Trade_Base] SET RECOVERY BULK_LOGGED;

-- Выполнение реиндексации (минимальное логирование)
-- [Ваш скрипт обслуживания индексов]

-- Возврат в Full
ALTER DATABASE [Trade_Base] SET RECOVERY FULL;

Важно: В этой модели невозможно восстановление на конкретный момент времени (Point-in-time), если внутри лога есть записи о массовых операциях.

Итоги: что выбрать для продуктивной базы?

Проанализировав доводы, приходим к выводу: для продуктивных баз 1С стандартным выбором должна быть Полная модель (Full). Аргументы о "нехватке места" обычно свидетельствуют лишь о неправильной настройке расписания бэкапа журналов транзакций или отсутствии мониторинга дискового пространства.

Используйте Simple только если: - Вы четко осознаете риск потери данных за весь день (с момента последнего ночного бэкапа). - У вас нет квалифицированного специалиста для настройки цепочки бэкапов. - База является вспомогательной или тестовой.

Для крупных баз (250 ГБ+) обязательно включите настройку Windows "Perform volume maintenance tasks" (Instant File Initialization). Это позволит мгновенно создавать файлы данных при восстановлении, что значительно сократит RTO вашей системы.