Как бэкапят большие объёмы?

Т.е. всё одинаково при любых объёмах или есть хитрости?

Если это именно база, можно делать репликацию на резервный сервер, бэкап будет готов к работе немедленно.

Хардварные снапшоты средствами массива.

zfs + снашоты с пересылкой дельты между снапшотами

lagged-реплика, которая фиксированно отстает на несколько часов - есичо ее можно использовать как букап.

Разные репликации (hw/sw) это не бэкапы, но в регламенте восстановлений сервисов очень полезны.

Бэкапят большие БД обычно на VTL по SAN или широкой сети. Хорошо, если VTL с online дедупликацией, но таких сейчас практически не осталось, все с отложенной. Это может быть заморочно, поэтому на отложенную лучше не расчитывать. Свежие бэкапы можно восстанавливать быстро с VTL. Старые бэкапы уходят с VTL на ленты. С лент восстанавливать долго, поэтому нужно планировать объем VTL. И не забывать про тестирование восстановлений.

Требуется понимание финансовых потерь и в зависимости от этого план DRP.

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

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

А так бэкап на ленты и т п - это когда бомба тебе в ЦОД прилетела и полный трындец.

И нет универсального метода - для каждой БД он свой, т к технологии разные

и да - бэкап лучше делать с реплики или стендбая, чтобы не нагружать основную БД

Тупая Клонеззила и диск. :) Умеет робить с раидами и жмет данные до упора.

Нужно влючить файр. Чтоб эта сволочь (клонезила) не фонтанирует своим

распостраненное мнение,что бэкап БД это просто как бэкап файлопомойки

Это не так

Ну, не обязательно всё так драматично, известны более банальные случаи. Например, прорыв горячего водопровода на техническом этаже, когда за ночь успевает залить несколько этажей. Тут «отчуждаемый» носитель и/или второй DC незаменимы.

как можно реализоват стратегию резервного копирования с минимальным временем на восстановление

репликами. количество реплик по уровню баттхерта от падения базы.

еще можно делать несколько уровней как например эластик делает. горячее складывать на N шардов, остывшее на N - M. тогда обычно восстанавливать нужно будет только горячее

Полные бекапы плюс инкрементальные. Полные бекапы делаются со снепшота. От того времени отчитывается инкрементальный.

Не ясно что значит минимальное время восстановления. Если что-то лежит отдельно, то его нужно оттуда вернуть. Если все лежит на той же распределенной ФС, то от чего бекап? От программных ошибок или ошибок кода СУБД?

Как вообще работает БД? Она sharded? Восстановление нужно всей БД сразу или отдельных шардов? Если будет outage, то его первым увидят отдельные шарды?

А чего тут многие путают репликацию и бэкапы? Это вещи перпендикулярные. Бэкап - это холодные данные. Они восстанавливаются минуты или часы. А реплика, если база высоконагруженная и латентность критична, вообще в той же стойке на соседнем сервере/серверах висит.

В общем, правильно заметили - если несколько часов простоя при восстановлении пофиг, то бэкапа достаточно. Иначе нужна еще и репликация для HA.