Резервное копирование репликации sql server

Я предполагаю, что у Вас уже есть хорошие Стратегии резервного копирования на месте Вашего DB OLTP и Вашего Создания отчетов DB, которые счастливо работали в Производстве. Я действительно не вижу, что у Вас есть любые дополнительные проблемы по поводу исправления их пострепликация.

Можно просто генерировать Сценарии Установки Репликации через Мастер SSMS. Это позволит Вам настраивать и настраивать свои Параметры репликации в любых будущих средах Dev/Test и давать Вашему Резервное копирование своей текущей конфигурации.

Репликация может известно поесть через Ваш Диск ЖУРНАЛА если по некоторым причинам Остановы Репликации.. но если Вы имеете вручную или Автоматизированные Предупреждения, отслеживающие Дисковое пространство и Состояние репликации, у Вас не должно быть проблем.

Удачи - но в моем уме Резервные потребности в основной Репликации транзакций не должны требовать никаких дополнительных стратегий.

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

В течение времени это берет, чтобы генерировать и передать полный снимок (8 часов в нашем случае), я могу восстановить статическую копию базы данных отчета с другим именем через 30 минут и указать на приложение отчета на ту базу данных для предотвращения слишком большого количества времени простоя для моих пользователей отчета, тот способ, которым пользователи могут выполнить свои отчеты о данных со вчерашнего дня, пока дублируемая база данных не в порядке.