Мне было поручено разработать работоспособное решение аварийного восстановления для нашей среды SQL. Однако у DR-бокса есть серьезное ограничение, так как диск с данными составляет 2,25 ТБ, в отличие от диска 3,50 ТБ, используемого в производстве. Очевидно, это противоречит основополагающему принципу создания такого же оборудования для аварийного восстановления и производства.
Теперь к конкретике. У нас есть несколько больших баз данных (от 100 ГБ до 750 ГБ), которые разбиты на файловые группы по функции даты (ежемесячные файловые группы), поскольку эти базы данных содержат исторические данные за несколько лет. Следовательно, файловые группы, содержащие данные старше года, помечаются как доступные только для чтения.
Возможно ли иметь базу данных аварийного восстановления, которая является подмножеством файловых групп из более крупной производственной базы данных? Например, скажем, в производственной среде есть 3 файловые группы: 2008 (r / o), 2009 (r / o) и 2010 (r / w). Может ли база данных аварийного восстановления состоять только из одной файловой группы (2010 г.)? Если да, можно ли настроить доставку журналов для файловой группы r / w?
В противном случае обходным путем было бы создание архивной базы данных для исторических данных, которой можно было бы пожертвовать в ситуации аварийного восстановления, в то время как текущая база данных с оперативными данными может быть отправлена. FWIW, полные резервные копии базы данных делаются на ленту и хранятся вне офиса. Является ли метод файловой группы работоспособным решением?
Доставка журналов будет учитывать всю базу данных; файловые группы не имеют значения. Я согласен, что ваше решение для архивной базы данных будет работать.