Здравствуйте, chaotic-kotik, Вы писали:

G>>Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную
G>>

G>>drop table main_data
G>>

G>>?
CK>Ну так можно восстановить все из снепшота, что в этом непонятного?
Ты вроде писал, что снепшот не хранит данные? Или таки хранит?

G>>Это не гарантирует что данные будут в сохранности.
CK>Так и бэкап твой тоже ничего не гарантирует.
В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.

CK>>>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.
G>>Это тот самый бекап, только дороже.
CK>Почему дороже?
Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.

CK>Начнем с того, что MSSQL не может в несколько датацентров вообще.
Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.

CK>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.

G>>Если данные нестрашно потерять, то скорее всего так и есть.
CK>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
Ты написал что данные можно восстановить из других источников. Значит не так страшно.


G>>Держать 5 реплик + копию в другом ДЦ оправдано?
CK>Ну мы не держим копию в другом ДЦ пока.
То есть катастрофоустойчивости у вас нет? Я вот запоследний год помню три падения разных хостеров с невозможностью воссановления.
Желаю тебе как можно быстрее перейти в категорию тех кто уже делает бекапы.

G>>На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты.
CK>Ну это все голословные утверждения, практика у всех разная.
http://www.overlandstorage.com/blog/?p=323


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


G>>Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов.
G>>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
CK>Это разумное время по твоему?
Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.

CK>А скажи пожалуйста, зачем нужно было делать рестор той БД и как зависит время рестора от размера базы?
Есть полезная практика тестировать рестор. Вот протестировали.
Время рестора от размера зависит линейно, потому что скорость записи на диск — ограничивающий фактор.
В твоем случае ограничивающим фактором станет канал между ДЦ, скорее всего он окажется меньше, чем скорость записи на диск.
В прикладных случаях ресторить всю базу вообще нет смысла, есть дифференциальные бекапы, бекапы логов. Поэтому откат базы в предыдущее состояние на пару дней обычно не проблема.