Резервное копирование & восстановление 10-20 баз данных SQL Server в ~синхронное состояние?
Мне нужно создать резервные копии 10-20 баз данных SQL Server 2008 R2 размером 10-50 ГБ, пока они находятся в режиме онлайн и одновременно используются одним корпоративным приложением. Мне также нужно восстановить их до состояния, которое в значительной степени синхронизировано по всем базам данных (я могу позволить себе до нескольких секунд десинхронизации между базами данных). Цель - захват производственных данных для сред QA/DEV.
Мне бы очень хотелось не требовать запуска баз данных в режиме полного восстановления и придумать метод резервного копирования, предназначенный для сбора данных для QA-среды и остающийся независимым от основного процесса резервного копирования, который не находится под моим контролем.
Для моих клиентов потребуется 1-2 часа для создания 20 полных резервных копий объемом ~30 ГБ каждая. Это делает последовательное создание полных резервных копий неприемлемым, поскольку базы данных будут слишком десинхронизированы при простом восстановлении.
Я'ищу идею лучше, чем эти:
ИДЕЯ 1: Снимок диска ВМ на уровне SAN. xcopy MDFs/LDFs из снимка..
Как только скопированные файлы будут подключены к другому экземпляру сервера, его процесс восстановления должен создать согласованные базы данных, которые будут созданы практически одновременно.
Googling around убедил меня, что это плохая идея, хотя бы потому, что я могу получить desync vs. master/msdb/etc..
ИДЕЯ 2: Организовать сложную систему резервного копирования; синхронизировать-восстановить все базы данных.
Это потребует от меня запуска баз данных в режиме полного восстановления, чего я не хочу. Начните параллельное резервное копирование всех баз данных задолго до крайнего срока (T0). По достижении T0 создайте резервные копии всех журналов (это займет не более нескольких минут). Возьмите результирующее множество резервных копий и попытайтесь восстановить их & откатите журналы вперед/назад, чтобы получить несколько согласованное состояние всех баз данных относительно T0.
*Это требует большого количества планирования и сценариев для надежного использования, поэтому я бы приложил все усилия, чтобы избежать этого.
Может быть, я упустил какое-то другое решение?
P.S.1: Мне бы очень хотелось иметь возможность использовать db snapshots. Идея заключалась в том, чтобы инициировать снимок каждой базы данных (который должен завершиться за несколько секунд), затем последовательно создать полную резервную копию каждой из них в течение следующих минут/часов. Затем восстановить их все на другом сервере и вернуть каждую из них к моментальному снимку. AFAIK этот сценарий невозможен, потому что снимки не могут быть резервированы вместе с базой данных. Их можно откатить только на место, на сервер, где они были созданы. Кроме того, они требуют Enterprise Edition, которой у меня нет для всех клиентов.
P.S.2: Если вы знаете стороннее решение, способное создавать синхронизированные резервные копии всех баз данных, пожалуйста, укажите его.
То, что вы ищете, это последовательное резервное копирование всех ваших клиентских баз данных, вы должны использовать ПОЛНОЕ резервное копирование вместе с
Marked Transactions(выделено жирным шрифтом):Убедитесь, что вы делаете специальные резервные копии журнала транзакций с
COPY_ONLY, иначе ваше восстановление будет мучительным, поскольку любая специальная резервная копия журнала транзакций безCOPY_ONLYнарушит цепочку журнала. В качестве меры предосторожности вы можете ограничить пользователей в использовании только резервных копийCOPY_ONLY.Размеченные транзакции подойдут для вашей ситуации. Единственное, что можно сделать параллельные резервные копии - это
STRIPEих, но тогда вы в конечном итоге убедитесь, что вы не потеряете свои полосы резервного копирования. Чтобы сделать их быстрее, вы можете поиграть сBUFFERCOUNTиMAXTRANSFERSIZE.Вам следует использовать сжатие резервных копий, а также включить мгновенную инициализацию файлов.
См.
Если вы выполняете полное резервное копирование, а также резервное копирование журнала транзакций (а это необходимо, если вы считаете эти данные важными), вы можете просто скопировать резервные копии и резервные копии журнала транзакций на тестовую систему и выполнить point in time restore для восстановления баз данных в +- одно и то же время.
В зависимости от того, находятся ли все базы данных на одной машине SQL Server или насколько хорошо синхронизированы часы серверов, вы сможете достичь цели 'пару секунд десинхронизации'.
Это может быть немного пластырным решением, но оно будет соответствовать требованиям и будет довольно простым и недорогим.
Если у вас нет полных резервных копий и резервных копий журнала транзакций важных баз данных (которые полностью восстанавливаются), вам действительно нужно пересмотреть свою стратегию резервного копирования. Снимки на уровне SAN действительно сводят на нет смысл наличия базы данных в режиме полного восстановления, поскольку вы все равно не сможете сделать восстановление в нужный момент времени.
Пожалуйста, прочитайте, что MrDenny говорит об этом
При указанных вами обстоятельствах рассматривали ли вы резервное копирование VSS через поставщика VSS, который является сторонним или основан на Microsoft? Вы можете выполнить резервное копирование COPY_ONLY, которое не нарушит цепочку восстановления производства, и в итоге у вас должна получиться резервная копия всех баз данных, которую вы сможете восстановить в других местах в разумных пределах. Помните, что резервное копирование VSS имеет те же механизмы и недостатки, что и моментальные снимки баз данных, поскольку очень активная база данных может вызвать проблемы с дисковым пространством из-за редких используемых файлов. Посмотрите ресурсы TechNet о службе SQL Writer здесь и VSS резервных копиях SQL Server здесь.
Чтобы сделать это с помощью Windows Server Backup, следуйте шагам мастера для ручного резервного копирования, убедившись, что вы выбрали резервное копирование VSS в настройках пользовательской конфигурации в разделе VSS Settings. Это позволит резервному копированию Windows Server не мешать другим резервным копиям, созданным на сервере. Подробнее см. в Справочнике по резервному копированию Windows Server.