Мне нужно выполнить резервное копирование 10-20 баз данных SQL Server 2008 R2 с размерами от 10 до 50 ГБ, когда они подключены к сети и используются одновременно одним корпоративным приложением. Мне также нужно восстановить их до состояния, которое в значительной степени синхронизировано между всеми базами данных (я могу позволить себе несколько секунд на рассинхронизацию между базами данных). Целью является сбор производственных данных для сред QA / DEV.

Я бы очень хотел не требовать, чтобы базы данных работали в полном восстановлении, и предложить метод резервного копирования, который предназначен для сбора данных для сред обеспечения качества и остается независимым от основного процесса резервного копирования, который не находится под моим контролем.

Моим клиентам потребуется 1-2 часа, чтобы собрать 20 полных резервных копий по ~ 30 ГБ каждая. Это делает последовательное полное резервное копирование неприемлемым, поскольку базы данных будут слишком десинхронизированы при работе в режиме простого восстановления.

Я ищу идею лучше, чем они:

IDEA 1: снимок виртуальных дисков на уровне SAN. xcopy MDFs / LDFs из снимка.

После того, как скопированные файлы присоединены к другому экземпляру сервера, процесс восстановления должен создавать согласованные базы данных, которые в значительной степени создаются одновременно.
Поиск в Интернете убедил меня, что это плохая идея, по крайней мере потому, что я могу получить рассинхронизацию против master / msdb / etc.

IDEA 2: организовать комплексное резервное копирование и синхронное восстановление во всех базах данных

Это требует от меня требовательного запуска баз данных в полном восстановлении, чего я не хочу. Запустите параллельное резервное копирование для всех баз данных задолго до крайнего срока (T0). По достижении T0 создайте резервную копию всех журналов (это займет не более нескольких минут). Возьмите получившееся множество резервных копий и попробуйте восстановить их и прокрутить журналы вперед / назад, чтобы получить несколько согласованное состояние по базам данных относительно T0.
Это требует большого планирования и написания сценариев, чтобы использовать его надежно, поэтому я бы пошел на все, чтобы избежать этого.

Я пропускаю какое-то другое решение?

PS1: Мне бы очень хотелось иметь возможность использовать снимки БД . Идея заключалась в том, чтобы создать снимок каждого дБ (который должен быть закончен в секундах), а затем полностью выполнить резервное копирование каждого из них последовательно в течение следующих минут / часов. Затем восстановите их все на другом сервере и верните каждый из них в моментальный снимок. AFAIK этот сценарий невозможен, потому что снимки не могут быть сохранены вместе с базой данных. Их можно откатить только на том месте, где они были созданы. Кроме того, они требуют Enterprise Edition, который у меня не для всех клиентов.

PS2: Если вам известно о стороннем решении, способном создавать кросс-дБ синхронизированные резервные копии, пожалуйста, укажите это.

Мне нужно сделать резервную копию 10-20 баз данных SQL Server, используемых одновременно одним приложением предприятия, пока они находятся в сети, таким образом, чтобы восстановить их состояние, которое в значительной степени синхронизировано между всеми базами данных

То, что вы ищете, - это согласованное резервное копирование для всех ваших клиентских баз данных, вы должны использовать ПОЛНОЕ резервное копирование вместе с Marked Transactions(выделено жирным шрифтом):

Когда вы делаете связанные обновления для двух или более баз данных, связанных баз данных , вы можете использовать метки транзакций, чтобы восстановить их до логически согласованной точки . Однако это восстановление теряет все транзакции, которые были зафиксированы после метки, которая использовалась в качестве точки восстановления. Маркировка транзакций подходит только тогда, когда вы тестируете связанные базы данных или когда вы готовы потерять недавно совершенные транзакции.

Убедитесь, что вы выполняете резервное копирование журнала транзакций adhoc COPY_ONLY, иначе восстановление будет затруднено, поскольку любое резервное копирование журнала транзакций adhoc без него COPY_ONLYнарушит цепочку журналов. В качестве меры предосторожности вы можете запретить пользователям использовать только COPY_ONLY резервные копии .

Мне нужно решение для SQL Server версии 2008 R2 и выше. Размеры БД составляют до 50 ГБ на БД, и время на их резервное копирование составляет более 1-2 часов.

Отмеченные транзакции будут работать для вашей ситуации. Единственное, что делает параллельное резервное копирование - это STRIPEим, но в итоге вы убедитесь, что не потеряете свои полосы резервного копирования. Чтобы сделать их быстрее, вы можете играть с BUFFERCOUNTи MAXTRANSFERSIZE.

Вы должны использовать сжатие резервных копий , а также включить Мгновенная инициализация файла .

Ссылаться на

• Использование отмеченных транзакций (модель полного восстановления)
• Как увеличить скорость полного резервного копирования базы данных SQL с помощью сжатия и твердотельных дисков?

Если вы выполняете полные резервные копии, а также резервные копии журналов транзакций (и вам следует, если вы считаете эти данные важными), вы можете просто скопировать резервные копии и резервные копии журналов транзакций в тестовую систему и выполнить восстановление на определенный момент времени, чтобы восстановить базы данных в + - одновременно.

В зависимости от того, находятся ли все базы данных на одном и том же компьютере с 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 Backup для подробностей.

Я выберу @ Kin's как ответ, потому что это был первый ответ, который соответствовал заданному вопросу. Я нашел дополнительный ответ и опишу его ниже.

Для клиентов, использующих простую модель восстановления, мне потребуется копия MDF и LDF, извлеченная из временного снимка диска, сделанного в T0 на уровне гипервизора или SAN. Я могу использовать их для восстановления базы данных в состоянии от T0.

Для клиентов, использующих модель полного восстановления, мне потребуется:

• Копии из основного процесса резервного копирования последней полной резервной копии, выполненной до минимальной цепочки T0 + последующих резервных копий журнала транзакций, охватывающих T0. Затем я могу выполнить восстановление во времени до T0.

• Доступ для выполнения моих собственных вспомогательных COPY_ONLYрезервных копий. Я начну их все параллельно в момент времени T0, что должно занять не более нескольких секунд, и это было моей главной задачей № 1. Затем при восстановлении я буду выполнять восстановление на момент времени FirstLSN из каждой резервной копии. Прелесть этого в том, что мне вообще не нужно взаимодействовать с процессом резервного копирования MAIN, который был моей другой проблемой, они могут даже обрезать журналы, пока COPY_ONLYвыполняются мои резервные копии, не влияя на их согласованность.

Я делаю это несколько раз в год для QA и других сред, которые являются копиями производства. Для восстановления действительно необходим режим полного восстановления, и восстановление в определенный момент времени работает хорошо. Существует также много репликации, и мы редко видим ошибки «строка не найдена» после восстановления на определенный момент времени. Мы также используем метод клонирования / моментального снимка SAN для географически удаленной копии производства, и это также хорошо работает для синхронизации баз данных.