У меня есть клиент с очень простой настройкой одного сервера, который включает небольшую базу данных SQL Server Express.
Недавно я настроил для них Symantec Backup Exec 2010 Quickstart edition. Это бесплатная OEM-версия Backup Exec с ограниченными функциями, которая не включает агент SQL Server (или любой агент приложения). Однако он поддерживает VSS через Advanced Open File Option (AOFO). В этой ситуации я всегда настраивал запланированную задачу для дампа баз данных и резервного копирования дампа, поэтому я могу быть уверен, что у меня есть согласованная резервная копия.
Однако после запуска первоначального тестового задания всего блока с включенным AOFO я заметил, что он успешно сделал резервную копию файлов данных SQL, включая файлы MDF / LDF, и просто дал мне очень мягко сформулированную «рекомендацию», которую я мог бы пожелать. рассмотреть возможность приобретения агента SQL Server, поскольку он обнаружил данные SQL Server. Это меня удивляет по двум причинам:
Это заставило меня задуматься, действительно ли безопасно создавать резервные копии данных SQL Server напрямую, если вы используете VSS (через AOFO)? В конце концов, это, по-видимому, означает, что вызывается средство записи VSS SQL Server для обеспечения согласованности файлов данных с приложениями до создания моментального снимка. Backup Exec, похоже, «разрешил» мне это сделать, несмотря на то, что распознал данные SQL как таковые.
Я понимаю, что использование выделенного агента SQL дает ряд преимуществ, но безопасно ли это исключительно в вопросе создания базовой, согласованной, восстанавливаемой резервной копии?
Похоже, что однозначного ответа на этот вопрос очень мало, с некоторым противоречием. Очевидно, что в отсутствие одного я выберу испытанный и проверенный маршрут, но он заставил меня задуматься.
Вот кое-что из того, что я нашел на данный момент:
Подумайте о том, что происходит. база данных SQL в любой момент может записывать сложную транзакцию в несколько строк и таблиц, которые существуют во всем файле MDF. Если резервное копирование выполняется во время выполнения этих сложных транзакций, часть базы данных будет скопирована до того, как будет записана первая часть транзакции, а другая - после. Если это таблица с большим количеством столбцов, теоретически она может копировать эту часть файла во время записи строки. Теперь у вас есть несогласованная база данных, о которой журналы базы данных не могут знать. Volume Shadow Copy собирается сделать копию тома, но может заморозить том на ... ну, они говорят, на минуту, но ... Также есть масса зависимостей и ошибок. Положитесь на это, если хотите, но я не уверен, почему. https://www.brentozar.com/archive/2018/01/perils-vss-snaps/
Концептуальное представление о том, что происходит при резервном копировании SQL. Настоящая резервная копия SQL перестает записывать изменения в базу данных во время резервного копирования. Он продолжает регистрировать все изменения и должным образом считывать их из журналов, смешанных с чтениями из базы данных. После создания резервной копии базы данных и запуска нового журнала, а также после резервного копирования журналов до этого момента. Когда вы восстанавливаете это, база данных восстанавливается, а затем применялись файлы журнала, которые происходили. Так что все стабильно и надежно. Существуют разные нюансы, основанные на простой или полной модели восстановления, но основы те же. Файл, для которого выполняется резервное копирование, гарантированно останется неизменным. Все это делается базой данных, особенно для нюансов целостности базы данных. На это стоит положиться.