Действительно ли безопасно создать резервную копию данных SQL Server непосредственно при использовании VSS?
У меня есть клиент с очень простой единственной установкой сервера, которая включает маленькую базу данных SQL Server Express.
Я недавно настроил выпуск Быстрого запуска Backup Exec Symantec 2010 года для них. Это - бесплатная, ограниченная функцией версия OEM Backup Exec, которое не включает SQL Server Agent (или никакой агент приложений). Однако это действительно поддерживает VSS через Усовершенствованную открытую опцию файла (AOFO). В этой ситуации я всегда настраивал запланированную задачу, чтобы вывести базы данных и создать резервную копию дампов, таким образом, я могу быть уверен, что у меня есть последовательное резервное копирование.
Однако после выполнения начального тестового задания целого поля с AOFO включил, я заметил, что это счастливо создало резервную копию файлов данных SQL, включая файлы MDF/LDF, и просто дало мне очень мягко сформулированную "рекомендацию", что я мог бы хотеть рассмотреть покупку SQL Server Agent, поскольку это обнаружило данные SQL Server. Это удивлено меня на двух передних сторонах:
- Это было мое понимание, что Backup Exec автоматически исключает файлы MDF/LDF из резервных копий плоского файла с помощью функции Active File Exclusion или 'AFE', если Вы вручную не отключили это через ключ реестра. Мое понимание было то, что это было то, потому что это всегда - плохая идея создать резервную копию их непосредственно. Факт они не были исключены, был поэтому необычным и возможно намеренным.
- Отсутствие любого серьезного предупреждения, указывающего, что данные SQL могут быть непоследовательными, невосстановимыми или что бы то ни было. Просто вежливая рекомендация относительно SQL Agent.
Это привело меня задаваться вопросом, действительно ли на самом деле безопасно создать резервную копию данных SQL Server непосредственно при использовании VSS (через AOFO)? В конце концов, это, по-видимому, означало бы SQL Server, которым Устройство записи VSS называют, чтобы гарантировать, что файлы данных последовательны с приложением, прежде чем снимок будет взят. Backup Exec, кажется, 'позволило' мне сделать это, несмотря на то, что распознало данные SQL как таковые.
Я ценю, что использование специализированного SQL Agent предоставляет много преимуществ, но просто по вопросу о взятии основного, последовательного, восстановимого резервного копирования, действительно ли это безопасно?
Кажется, существует очень мало с точки зрения категорического ответа на вопрос, с некоторым конфликтом. Очевидно, в отсутствие одного я буду следовать проверенным на практике маршрутом, но он имеет меня взгляды.
Вот часть из того, что я нашел до сих пор:
Подумайте о том, что происходит. База данных SQL в любой момент времени может написать сложную транзакцию к нескольким строкам и таблицам, которые существуют по всему MDF-файлу. Если резервное копирование выполняется в то время, когда эти сложные транзакции идут по части БД, то резервное копирование выполняется до записи первой части транзакции, а второй - после. Если это таблица с большим количеством столбцов, то теоретически можно скопировать эту часть файла во время записи строки. Теперь у вас есть непоследовательная БД, о которой журналы БД не могут знать. Volume Shadow Copy собирается скопировать том, но может заморозить его на ... ну, говорят минуту, но...... Есть также тонна зависимостей и gotcha's. Зависит от него, если хочешь, но я не знаю почему. https://www.brentozar.com/archive/2018/01/perils-vss-snaps/
Концептуальный взгляд на то, что происходит в SQL резервном копировании. Настоящее SQL Backup останавливает запись изменений в БД во время резервного копирования. Она продолжает записывать в журнал все изменения и считывать их соответствующим образом из журналов, смешанных с чтением БД. После создания резервной копии базы данных запускается новый журнал, а также выполняется резервное копирование журналов, относящихся к этому моменту. Когда вы восстанавливаете эту базу данных, то файлы журнала, которые происходили, применяются. Таким образом, все будет стабильно и надежно. Существуют различные нюансы, основанные на простой или полной модели восстановления, но основы все те же. Резервируемый файл гарантированно останется неизменным. Все это делается с помощью базы данных, специально для нюансов целостности базы данных. На это стоит положиться.