Как восстановить базу данных SQL при полной модели восстановления на состояние «вчера», если полный бэкап никогда не создавался?

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

В данной статье мы подробно разберем, почему стандартные средства SQL Server Management Studio (SSMS) выдают ошибки при попытке восстановления в такой ситуации, что такое «псевдо-простая» модель восстановления и какие шаги можно предпринять для спасения данных, когда кажется, что вариантов больше нет.

Анализ проблемы: почему база не откатывается?

Рассмотрим ситуацию, описанную пользователем: база данных находится в модели Full, но полный бэкап (Full Backup) никогда не делался. Автор пытается выполнить восстановление на «пару дней назад», используя графический интерфейс, и получает ошибку: «Запрошенное содержимое не может быть загружено».

Выясним причину такого поведения системы. Для SQL Server модель восстановления Full активируется не в момент выбора соответствующего пункта в свойствах базы, а только после создания первого полного бэкапа. До этого момента база данных фактически работает в режиме, который специалисты называют pseudo-simple (псевдо-простая модель).

Проанализируем, что происходит внутри системы в этот период:

1. SQL Server не начинает строить цепочку логов транзакций (Log Chain).
2. Лог транзакций (LDF-файл) автоматически очищается (truncated) после каждой контрольной точки (checkpoint), чтобы предотвратить его переполнение.
3. Записи, необходимые для восстановления на момент времени (Point-in-Time Recovery), не сохраняются.

Таким образом, попытка «откатить транзакции» на два дня назад в живой базе невозможна, так как этих транзакций уже нет в файле лога — они были перезаписаны.

Разбор понятия «Цепочка логов» (Log Chain)

Для понимания процесса восстановления важно уяснить принцип работы цепочки логов. Каждая запись в логе имеет свой уникальный номер — LSN (Log Sequence Number). Восстановление на конкретный момент времени — это последовательное применение записей лога, начиная от определенного LSN, зафиксированного в полном бэкапе.

Если у нас нет «точки опоры» в виде полного бэкапа, SQL Server не понимает, к какому исходному состоянию данных нужно применять последующие изменения. Даже если бы мы начали делать бэкапы логов (Transaction Log Backups) вчера, они были бы бесполезны без базового Full-бэкапа, сделанного позавчера.

Пошаговая стратегия спасения данных

Если вы оказались в ситуации автора сообщения, когда стандартное восстановление через SSMS невозможно, разберем альтернативные варианты действий.

Способ 1: Использование теневых копий тома (VSS)

Часто системные администраторы забывают о встроенных механизмах защиты Windows Server. Если на дисках, где расположены файлы MDF и LDF, включена служба Volume Shadow Copy (VSS), у вас есть шанс достать файлы базы в том состоянии, в котором они были «вчера».

Выполним следующие шаги:

1. Зайдем в свойства папки, где лежат файлы базы данных.
2. Перейдем на вкладку «Предыдущие версии».
3. Если в списке есть копии за нужную дату, скопируем файлы в отдельное место.
4. Присоединим (Attach) эти файлы на другом сервере SQL или под другим именем на текущем.

Важно: SQL Server воспримет такую базу как после аварийного завершения работы. При прикреплении он запустит процесс Recovery, используя данные из LDF-файла, чтобы привести базу в согласованное состояние на момент создания теневой копии.

Способ 2: Использование сторонних анализаторов лога (Log Readers)

Если данные крайне важны, а теневых копий нет, можно попытаться прочитать «сырые» данные напрямую из файла LDF. Существуют специализированные инструменты, такие как ApexSQL Log или аналоги от Redgate.

Проанализируем возможности таких утилит:

• Они могут прочитать записи в логе, которые еще не были физически затерты новыми данными на диске.
• Они позволяют сформировать UNDO-скрипты — набор SQL-команд, которые обращают изменения (например, превращают DELETE в INSERT).
• Это сложный и трудозатратный процесс, требующий глубоких знаний структуры таблиц 1С, но иногда это единственный способ вернуть удаленные документы.

Разберем технические нюансы версий SQL Server

В сообщении №11 автор упоминает, что восстановил базу на сервере с «меньшей версией оболочки». Здесь важно внести ясность: SQL Server принципиально не позволяет восстанавливать бэкапы или прикреплять файлы данных с более высокой версии (например, с SQL 2022) на более низкую (SQL 2019).

Скорее всего, под «меньшей версией оболочки» подразумевалась версия SQL Server Management Studio или же пользователю удалось найти старый файл базы (копию MDF), который был сделан вручную или сторонним софтом. Это подчеркивает главный вывод: если стандартный механизм Full Recovery не был инициализирован, спасение данных возможно только через поиск физических копий файлов.

Как правильно настроить базу в будущем

Чтобы не попадать в подобную ситуацию, проанализируем правильный алгоритм настройки базы данных после установки или обновления:

1. Устанавливаем модель восстановления FULL в свойствах базы.
2. Немедленно выполняем первый полный бэкап. Это можно сделать скриптом:

BACKUP DATABASE [Имя_Вашей_Базы] 
TO DISK = 'C:\Backup\Initial_Full_Backup.bak' 
WITH INIT, STATS = 10;

3. Настраиваем План обслуживания (Maintenance Plan), который будет включать:

• Ежедневный полный бэкап (Full Backup).
• Регулярный бэкап логов транзакций (например, раз в час или чаще). Это критически важно, так как именно бэкап лога «срезает» его и не дает файлу LDF раздуться на весь диск.
• Проверку целостности базы (DBCC CHECKDB).

Рассмотрим пример команды для периодического бэкапа лога:

BACKUP LOG [Имя_Вашей_Базы] 
TO DISK = 'C:\Backup\Log_Backup.trn' 
WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, STATS = 5;

Заключение

Подведем итог. Само по себе наличие галочки Full Recovery Model не является страховкой. Без первого полного бэкапа система находится в подвешенном состоянии, не обеспечивая ни экономии места (как Simple), ни возможности восстановления на момент времени.

В случае с базой 1С «Налогоплательщик», упомянутой в обсуждении, клиенту повезло найти старые файлы. В других ситуациях цена ошибки может быть гораздо выше. Всегда проверяйте работоспособность вашей цепочки бэкапов командой:

SELECT 
    name AS DatabaseName,
    recovery_model_desc AS RecoveryModel,
    (SELECT MAX(backup_finish_date) FROM msdb.dbo.backupset WHERE database_name = d.name AND type = 'D') AS LastFullBackup
FROM sys.databases d;

Этот запрос покажет вам реальное положение дел: когда был сделан последний полный бэкап и в каком режиме работает ваша база. Если в колонке LastFullBackup стоит NULL — ваша база в опасности, даже если модель указана как FULL.