Доброго времени суток!
Несколько вопросов от начинающего DBA.
Вроде бы первая задача, и ничего сложного в ней нет, но хочется быть уверенным, что все делаю правильно)

В организации имеем 2 кластера AlwaysOn.
Нужно:
1.) Организовать резервное копирование со вторичных реплик (модель FULL). Сейчас делается с первичных.
2.) Нужно иметь по 1-й копии full-бекапа за сегодня на каждом хранилище + по 1-й за вчерашний день. Раз в час делать бекапы логов всех баз
3.) Нужно разделить расписание, ибо сейчас все бекапится в одно время
4.) Базы в кластерах по размерам разные. Есть несколько по 700+ ГБ и с десяток маленьких (10 ГБ)
5.) Иметь представление о состоянии бекапов в течение дня

Что планирую сделать:
1 - настраиваем в AlwaysOn предпочтительную реплику для бекапа (не первичная, но только когда доступны вторичные)
2 - разделяем бекапы по времени. Мониторим среднее время бекапа и распределяем в течение дня
3 - бекапы больших БД ложим на 1-е файловое хранилище, далее планировщиком на самом файловом хранилище копируем вчерашний бекап на второе файловое хранилище. Все что старше, чем вчера - удаляем.
4 - маленькие БД копируем сразу на 2 файловых хранилища
5 - организуем систему оповещений на всех этапах резервного копирования / копирования файлов бекапа

Вопросы:
1 - При бекапе логов со вторичных реплик, размер лога ужимается на всех БД кластера?
2 - В случае, если бекап со вторичной реплики идет несколько часов, на момент окончания бекапа -
какую версию БД мы будем иметь в бекапе? На начало бекапа или на конец. Про обычные бекапы я в курсе - на конец.

Прошу оценить алгоритм, если есть замечания - озвучьте)
спасибо!

Andy_OLAP"AlwaysOn does not ship individual log records, it ships log blocks. The log block is used as a container for log records so by virtue of the log block tracking the individual LSN tracking also occurs"

Тут нужно мат.часть подучить. Не совсем понимаю, что имеется ввиду под фразой "BACKUP LOG поддерживает только обычное резервное копирование журналов" и "Обеспечивается последовательная цепочка журналов по всем резервным копиям журналов в любой реплике".

p.s. Получается, что на репликах FULL-бекап делается только в режиме COPY_ONLY.
Исходя из этой логики, чтобы обеспечить полную модель восстановления БД, бекапится нужно только с первичной реплики?

Andy_OLAPЧто означает "на всех БД кластера" - это некорректная постановка вопроса, БД то одна на всех репликах. Поэтому корректный ответ "нет". А теперь ждем более подробного пояснения пункта 2 "разделяем бекапы по времени" от автора темы. И как он собирается контролировать, когда, кто и где запустил бэкап.
Странно, но от Вас какая-то агрессия исходит, хотя я предупредил, что я в этом деле новичек.

Про БД - имелось ввиду экземпляры одной БД на всех репликах.
Про разделение бекапов - мониторинг среднего времени выполнения каждого бекапа. После этого нужно распределить время в шедулере, чтобы бекап одной БД по минимуму затрагивал бекап другой.

Andy_OLAPВы так фразу изначально написали, что можно было как угодно трактовать.

В первом сообщении я описал задачи, которые передо мной стоят. Более кратко о них:
1) Разгрузить первичную реплику
2) Разгрузить принимающие хранилища, ибо сейчас в 00:00 на них обрушивается шквал бекапов всех БД в обоих кластеров
3) Желательно этот процесс как то отслеживать, чтобы вовремя среагировать на ошибки.

Далее я описал свое видение решения этих задач, при этом уведомив, что делаю я это впервые ( со всеми бывает в первый раз) )
Естественно, в силу опыта я мог не учесть многих нюансов - иначе, зачем мне создавать эту тему?
Как раз затем, чтобы спросить совета у более опытных товарищей.

Andy_OLAPAngryError,
Коллега, расшифруйте фразу "настраиваем в AlwaysOn предпочтительную реплику для бекапа" - Вы один раз выберете, какая реплика будет использоваться для бэкапов, или несколько раз в течение дня будете определять, какая теперь предпочтительная.
Больше нюансов - больше ответов от участников, как это все настроить.

В каждом кластере по 4 реплики.
Хотелось бы, чтобы бекапы делались с одной и той же реплики (вторичной), но если она в DOWN'е - бекап переключался на другую вторичную реплику. Если реплика стала первичной - бекап так же переключался на другую по приоритету вторичную реплику.