Что происходит во время резервного копирования SQL Server?

Некоторые из моих коллег были удивлены, когда я сказал им, что могу создать резервную копию базы данных SQL Server, пока она еще работает, и поинтересовался, как это возможно. Я знаю, что SQL Server способен выполнять резервное копирование базы данных, пока она еще в сети, но я не знаю, как объяснить, почему это возможно. Мой вопрос, как это влияет на базу данных?

Если данные будут изменены (путем вставки, обновления или удаления) во время выполнения резервного копирования, будет ли резервная копия содержать эти изменения или будет добавлена ​​в базу данных впоследствии?

Я предполагаю, что файл журнала играет важную роль здесь, но я не совсем уверен, как.

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

Полная резервная копия содержит как данные, так и журнал. Для данных он просто копирует каждую страницу базы данных в резервную копию, как и в тот момент, когда он читает страницу. Затем он добавляет на носитель резервных копий весь «соответствующий» журнал. Это включает, по крайней мере, весь журнал между LSN в начале операции резервного копирования и LSN в конце операции резервного копирования. В действительности обычно существует больше журналов, так как он должен включать все активные транзакции в начале резервного копирования и журнал, необходимый для репликации. Посмотрите Разоблачение пары мифов вокруг полных резервных копий базы данных .

Когда база данных восстанавливается, все страницы данных копируются в файлы базы данных, затем все страницы журнала копируются в файл (ы) журнала. В настоящий момент база данных является несовместимой, поскольку она содержит изображения страниц данных, которые могут быть не синхронизированы друг с другом. Но сейчас запускается нормальное восстановление . Поскольку журнал содержит весь журнал во время резервного копирования, в конце восстановления база данных является согласованной.

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

Вы не можете просто скопировать его, поскольку в середине копии базы данных могут быть изменения, как вы упоминали в этом вопросе.

Это должно быть сделано с агентами, которые осведомлены о функциональности базы данных, а затем делают «снимок» через функции ОС или могут использовать утилиту для вывода базы данных в безопасное состояние (например, mysqldump, если используется mysql).

В противном случае вы получите резервную копию, которая может быть повреждена, и вы не узнаете ее, пока не восстановите ее. Я думаю, что Джоэл и Джефф недавно говорили об этом на недавнем подкасте StackOverflow.

И вы правы в том, что файл журнала важен. Если файл журнала / журнала не синхронизирован с фактическими данными, восстановление файлов приведет к повреждению.

Он сводится к резервному копированию, выполненному с использованием безопасного состояния базы данных, либо через агент с поддержкой базы данных, либо через приложение моментальных снимков, либо приложение, которое знает, как правильно подключить базу данных к сбросу данных, не мешая обновлениям во время сброса данных и резервного копирования. до результирующего файла.

Есть так много способов сделать это (вообще говоря, понятия не имею, как это обычно делает MSSQL), например, просто выгрузить базу данных в файл, добавляя любые изменения в файл журнала, который фиксируется после завершения дампа, - к использованию снимка, специфичного для файловой системы. такие функции, как VSS на Windows.

Вы можете взять так называемую резервную копию только для копирования. Не влияет на базу данных, пока она в сети