Що відбувається під час резервного копіювання на SQL Server?

Деякі мої колеги були здивовані, коли я сказав їм, що я можу створити резервну копію бази даних SQL Server, поки вона все ще працює, і задумався, як це можливо. Я знаю, що SQL Server здатний створити резервну копію бази даних, поки вона ще є в Інтернеті, але я не знаю, як пояснити, чому це можливо. Моє запитання - який вплив це має на базу даних?

Якщо дані будуть змінені (за допомогою вставки, оновлення чи видалення) під час роботи резервної копії, чи буде резервна копія містити ці зміни чи вони будуть додані в базу даних згодом?

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

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

Повна резервна копія містить і дані, і журнал. Для даних він просто копіює кожну сторінку бази даних в резервну копію, як це відбувається в момент, коли вона читає сторінку. Потім він додає в резервний носій весь "відповідний" журнал. Це включає щонайменше весь журнал між LSN на початку операції резервного копіювання та LSN в кінці операції резервного копіювання. Насправді журналу зазвичай більше, оскільки він повинен включати всі активні транзакції на початку резервного копіювання та журналу, необхідного для реплікації. Див. Розділ Розкриття декількох міфів щодо повних резервних копій бази даних .

Після відновлення бази даних всі сторінки даних копіюються у файли бази даних, а потім всі сторінки журналів копіюються у файли журналів. На даний момент база даних є непослідовною, оскільки вона містить зображення сторінок даних, які можуть не синхронізуватися між собою. Але зараз запускається нормальне відновлення . Оскільки журнал містить весь журнал під час резервного копіювання, в кінці відновлення база даних є послідовною.

Під час резервного копіювання буде створено знімок для бази даних, а дані будуть прочитані для резервного копіювання з цього знімка. Фактичні операції БД в реальному часі не впливатимуть на операцію резервного копіювання.

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

Це потрібно зробити з агентами, які знають про функціональність бази даних, а потім зробити "знімок" через функції ОС або можуть використовувати утиліту для скидання бази даних у безпечному стані (наприклад, mysqldump, якщо використовується mysql).

В іншому випадку ви отримаєте резервну копію, яка може бути пошкоджена, і ви не будете знати її, поки не відновите її. Я думаю, що Джоел та Джефф нещодавно трохи поговорили про це на недавньому подкасті StackOverflow.

І ви праві, що файл журналу важливий. Якщо файл журналу / журналу не синхронізований з фактичними даними, відновлення файлів призведе до пошкодження.

Вона зводиться до резервної копії, зробленої за допомогою безпечного стану бази даних, або через агент, що обізнаний із базою даних, або за допомогою програми знімків або програми, яка знає, як правильно підключити базу даних до скидання даних, не втручаючись у оновлення під час скидання даних, а потім резервного копіювання. вгору отриманий файл.

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

Ви можете взяти те, що відомо як резервне копіювання лише для копіювання. Не буду впливати на базу даних під час роботи в Інтернеті