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


CK>Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL.
NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска. Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.

Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.

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

Это кстати вообще, на мой взгляд, общее место какое-то. Т.е. к примеру крайне популярна тема сравнения надёжности (fault tolerance) и доступности (availability) разных решений — SQL там, NoSQL, и т.п. — при этом, что характерно, никаких разговоров о времени восстановления из бэкапа не ведётся в принципе. На мой взгляд, это профанация — потому, что двухмашинный active-passive кластер при смерти активной ноды превращается в одномашинный кластер. Если восстановление второй ноды занимает неделю, то у нас есть все шансы нарваться на второй фолт и получить полную потерю данных.
В SQL Azure, насколько я знаю, по этой причине используется три реплики базы, и коммит требует кворума "2 из 3х". Благодаря этому при единичном сбое мы всё ещё имеем избыточность, и можно продолжать работать. Если у нас осталась единственная реплика данных, то по идее надо всё тихонечко выключать и молиться, что за время подготовки второй реплики в первую не шарахнет метеорит