[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-restore-test::ru":3,"gloss-cluster-restore-test::ru":23,"gloss-next-restore-test::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"restore-test","cloud","Проверка восстановления","Проверка восстановления — это упражнение, в котором из резервной копии действительно собирают работающую систему: по расписанию, намеренно и до того, как это кому-то понадобится. Она существует потому, что резервная копия — не вещь, которая у вас есть, а утверждение о том, что вы могли бы сделать, и утверждение остаётся непроверенным, пока никто не попробовал. Режимы отказа скучны и крайне распространены. Задание пишет файлы нулевого размера с тех пор, как истёк срок у одних учётных данных, а сообщение об успехе никто внимательно не читал. Одну таблицу исключает фильтр, добавленный годы назад по причине, которую никто не помнит. Данные восстанавливаются, но сервис не запускается, потому что конфигурация, секреты и версия схемы никогда не входили в то, что копировалось. Восстановление проходит и занимает одиннадцать часов, что как инженерный результат нормально и неприемлемо против того, что предполагал бизнес. Проверка стоит того, только если измеряет то, что вас будет волновать, а это не наличие файлов, а время, за которое человек доходит до работающей системы, и то, чего в ней не хватает по прибытии. Значит, восстанавливать надо в чистую среду, а не поверх работающей; по написанной процедуре, которой следует посторонний, а не тот, кто её строил и помнит наизусть; и заканчивать явной проверкой, что данные не просто присутствуют, а актуальны и полны. Запишите затраченное время и момент, на который данные восстановлены: эти два числа — единственная честная версия обещания о восстановлении. И повторяйте регулярно, потому что каждый из перечисленных отказов заносит обычное изменение, сделанное человеком, не подозревавшим, что копия зависит от того, к чему он прикоснулся. Проверка восстановления отвечает и на вопрос, никак не связанный с оборудованием: остался ли у кого-нибудь доступ, который для неё нужен. Процедуры восстановления, написанные годы назад, регулярно предполагают человека, ключ или учётную запись, которых больше нет, и этот зазор всплывает ровно в тот день, когда обнаруживать его некогда.","Проверка восстановления собирает рабочую систему из копии намеренно. Как скучно ломаются бэкапы и какие два числа даёт проверка.",null,[11,14,17,20],{"slug":12,"name":13},"audit-log","Журнал аудита (Audit Log)",{"slug":15,"name":16},"disaster-recovery","Аварийное восстановление",{"slug":18,"name":19},"runbook","Ранбук",{"slug":21,"name":22},"silent-failure","Тихий отказ (Silent Failure)",[24,28,32,35,38,41,45,48,51,54,57,60],{"slug":25,"category":5,"name":26,"updated_at":27},"air-gapped-deployment","Развёртывание без выхода в сеть","2026-09-09T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"autoscaling","Автомасштабирование (Autoscaling)","2026-09-08T21:32:36+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"availability-zone","Зона доступности (Availability Zone)",{"slug":36,"category":5,"name":37,"updated_at":31},"block-storage","Блочное хранилище (Block Storage)",{"slug":39,"category":5,"name":40,"updated_at":27},"bring-your-own-cloud","Развёртывание в своём облаке (BYOC)",{"slug":42,"category":5,"name":43,"updated_at":44},"budget-alert","Оповещение о бюджете","2026-09-08T21:32:37+00:00",{"slug":46,"category":5,"name":47,"updated_at":27},"change-freeze","Заморозка изменений",{"slug":49,"category":5,"name":50,"updated_at":27},"control-plane","Управляющий слой и слой данных",{"slug":52,"category":5,"name":53,"updated_at":44},"cost-allocation-tag","Метка распределения затрат",{"slug":55,"category":5,"name":56,"updated_at":44},"cost-chargeback","Внутреннее перевыставление затрат",{"slug":58,"category":5,"name":59,"updated_at":44},"cost-observability","Наблюдаемость затрат",{"slug":15,"category":5,"name":16,"updated_at":31}]