Некоторые из моих коллег были удивлены, когда я сказал им, что могу создать резервную копию базы данных SQL Server, пока она еще работает, и задались вопросом, как это возможно. Я знаю, что SQL Server может выполнять резервное копирование базы данных, пока она еще находится в сети, но я не знаю, как объяснить, почему это возможно. У меня вопрос: как это повлияет на базу данных?
Если данные изменяются (вставкой, обновлением или удалением) во время выполнения резервного копирования, будут ли в резервной копии содержаться эти изменения или они будут добавлены в базу данных впоследствии?
Я предполагаю, что файл журнала играет здесь важную роль, но я не совсем уверен, как это сделать.
edit: В качестве примечания, мой случай включает в себя резервное копирование баз данных с помощью агента SQL Server и влияние изменений базы данных во время этого процесса.
Полная резервная копия содержит как данные, так и журнал. Для данных он просто копирует каждую страницу базы данных в резервную копию, как есть в настоящий момент он читает страницу. Затем он добавляет на носитель резервной копии весь «соответствующий» журнал. Это включает, по крайней мере, весь журнал между LSN в начале операции резервного копирования и LSN в конце операции резервного копирования. На самом деле журнала обычно больше, так как он должен включать все активные транзакции в начале резервного копирования и журнал, необходимый для репликации. Видеть Развенчание нескольких мифов о полных резервных копиях баз данных.
При восстановлении базы данных все страницы данных копируются в файлы базы данных, затем все страницы журнала копируются в файл (ы) журнала. База данных в настоящий момент несовместима, поскольку она содержит изображения страниц данных, которые могут быть не синхронизированы друг с другом. Но теперь нормальный восстановление запущен. Поскольку журнал содержит весь журнал во время резервного копирования, в конце восстановления база данных остается согласованной.
Вы не можете просто скопировать его, так как в промежуточной копии базы данных могут быть изменения, о которых вы упоминали в вопросе.
Это должно быть сделано с агентами, которые осведомлены о функциональности базы данных и затем делают «моментальный снимок» с помощью функций ОС или могут использовать утилиту для сброса базы данных в безопасном состоянии (например, mysqldump, если используется mysql).
В противном случае вы получите резервную копию, которая может быть повреждена, и вы не узнаете ее, пока не восстановите ее. Я думаю, что Джоэл и Джефф недавно немного говорили об этом в недавнем подкасте StackOverflow.
И вы правы в том, что файл журнала важен. Если журнал / файл журнала не синхронизированы с фактическими данными, восстановление файлов приведет к повреждению.
Это сводится к резервному копированию, сделанному с использованием безопасного состояния базы данных, либо с помощью агента, поддерживающего базу данных, либо приложения моментальных снимков, либо приложения, которое знает, как правильно подключить базу данных к отбрасыванию данных, не мешая обновлениям во время дампа данных, а затем резервного копирования вверх получившийся файл.
Во время резервного копирования будет создан моментальный снимок для базы данных, и данные будут считаны для резервного копирования из этого моментального снимка. Фактические операции с живой БД не повлияют на операцию резервного копирования.
Есть так много способов сделать это (вообще говоря, понятия не имею, как MSSQL обычно это делает), например, просто выгрузить базу данных в файл при добавлении любых изменений в файл журнала, который фиксируется после завершения дампа, - использовать моментальный снимок конкретной файловой системы. такие функции, как VSS в Windows.
Вы можете сделать так называемую резервную копию только для копирования. Не повлияет на базу данных, пока она в сети