ЛП10 минут - это, пардон, typically
Я например не вижу ничего страшного в том, чтобы в зависимости от criticality of the data делать бекапы чаще, чем раз в 10 минут (хотя это уже и не typically)

Вы сами так делаете на рабочем сервере?
И потом раз в 10 минут и раз в минуту разница большая - в 10 раз!

2 andsm и ЛП

И еще вопрос, если такая задача критичная, то сколько времени уходит на восстановление БД при такой стратегии резервного копирования? Это важный показатель.

А может проще реплицировать данные на другой сервер? Если раз в 10 минут мало и RAIDу не верим.

tygra авторИ еще вопрос, если такая задача критичная, то сколько времени уходит на восстановление БД при такой стратегии резервного копирования? Это важный показатель.
Зависит от скорости сервера по поднятию бэкапа БД и логов и от количества данных. И никак не зависит от количества бэкапов лога.
Подъем 30-и гиговой базы на одном железе у нас было полтора-два часа, на более мощном 45 минут.
Если у вас еще более мощный сервак, то еще меньше будет.

авторА может проще реплицировать данные на другой сервер? Если раз в 10 минут мало и RAIDу не верим.
Вы всю базу будете реплицировать? А зачем? Есть более простой и менее загружающий сервер метод - бэкапы. Причем метод в отличие от репликации, не требующий еще одного мощного сервера и частенько танца с бубнами. :)

-- Tygra's --
Предположим 1 полный бекап ежедневно в полночь и по бекапу лога каждую минуту. Краш случился в 17-00. Итак поднимаем - полный бекап и накатываем 17*60 = 1020 бекапов лога. Кстати, вопрос как и где они лежат. Ежесекундно у нас 10 000 транзакций. И сколько у нас уйдет на это времени?

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

2 тигра

Вы сами с какой частотой делаете бекапы лога?

Пардон! Транзакций в секунду не 10 000, а всего лишь 1000 :)
То есть 60*1000= 60 000 в минуту.

lockyа вот для быстрого подъема базы по случае падения можно также применять лог-шиппинг - как дароваванный MS (если деньги позволяют) так и сбацанный на коленке. у нас работает сбацанный на коленке - примерно с теми же результатами, по итогу подъем сервера занимает около 15 минут. можно было бы и меньше, но, чтобы не пудрить себе мозги, мы подымаем не только рабочую базу, но и мастер, т.е. практически весь сервер целиком.
а еще есть differential backup. его если делать раз в, скажем, 3 часа, то надо будет накатывать максимум 180 лого.
Согласен, можно и лог-шиппинг.

Но раз в минуту лог писать это очень уж квадратно.

lockyесли твоя минута стоит массу денег - то стоит делать так...
у одного перца в сети стоит не один резервный сервер, а 3.
на вопрос "Нафига?" он сказал, что час простоя - это как раз такой сервер, так что для надежности....
Поэтому я и удивлен выбранной стратегией "копия лога каждую минуту". Долго поднимать. И не факт, что все поднимешь. Где копии-то лежат, надеюсь на другом сервере.

lockyесли логи подымать сразу после бэкапа, то время восстановления не очень большое. примерно 3-х кратное от времени бэкапа (это для минутных).
Для того, чтобы восстановить базу на ДРУГОМ сервере надо поднять там полный бекап+все логи.
Вы предложили log shipping - это хороший способ. А ежеминутный бекап - это для тонких ценителей.

Вообще, необходимо проводить на предприятии что-то вроде учений. Случился краш - восстанавливаем все базы, расшаренные файлы документов, списки логинов ОС и т. д. Тогда все сразу становится понятным. Что было продумано, а что надуманно.