Проверка резервного копирования, которую почти никто не делает

Вчерашнее задание резервного копирования было отмечено как «зеленое». То же самое было и с предыдущим заданием, каждую ночь на протяжении нескольких месяцев. Одна из этих машин вообще никогда не резервировалась — и ничего никогда не было отмечено как «красное», потому что для неё никогда не было написано никакого задания. 🚨 Шаблоны GitLab GitOps Pro продаются: https://payhip.com/b/EqswQ 🚨 Используйте код LAUNCH25 для скидки 25% до 30 сентября! «Есть ли у нас резервные копии?» — это три вопроса, ответы на которые совершенно разные. Должна ли эта система быть резервно скопирована? Была ли резервная копия сделана недавно? И сохранится ли эта копия после сбоя, который вы планируете, и сможет ли кто-нибудь её прочитать? Почти каждая система отвечает на второй вопрос, потому что второй вопрос ваш планировщик уже бесплатно сообщает. В этом эпизоде ​​первый вопрос становится вопросом, на который может ответить машина — намерение резервного копирования перемещается в CMDB, рядом с машиной, поэтому у вопроса «следует ли это резервировать?» появляется владелец и запрос, а не племенной ответ. Затем аудитор проверяет это в обоих направлениях. Эта обратная проверка — та, которую почти никто не проводит. В итоге все создают «заявлено, но отсутствует». В другом направлении — защищено, но никогда не заявлено — вы находите машину, которая больше никому не принадлежит. Также здесь: почему три уровня резервного копирования сделаны намеренно, и как определить, действительно ли у вас три уровня резервного копирования или это один, который тайно выходит из строя одновременно; как выглядит дамп, которому можно доверять; и ошибка в отчете, из-за которой сорок машин выглядели как одна зеленая строка. Разделы: 0:00 Зелёная задача, которая ничего не доказала 1:43 Три вопроса, а не один 2:48 Занесите намерение в CMDB 4:23 Три уровня, которые дают разные сбои 5:58 Как выглядит хороший дамп 7:07 Оглавление — это не восстановление 8:44 Проверка, которую почти никто не выполняет 10:34 На одну учетную запись меньше 11:23 Одна задача, сорок машин 12:29 Резервное копирование в область сбоя 13:19 Три вещи, которые стоит украсть ТРИ ВЕЩИ, КОТОРЫЕ СТОИТ УКРАСТИТЬ 1. Спрашивайте, какой сбой пережила каждая копия, а не сколько у вас копий. Две задачи, которые умирают одновременно, — это одна задача. 2. Объявленный, но отсутствующий — это только половина проверки. Обратное — защищённый, но необъявленный — это место, где находятся непринадлежащие вам машины. 3. Зелёный цвет описывает ваш планировщик, а не ваши данные. Задание, завершившееся с нулевым значением, доказывает, что задание было выполнено. Проверьте контрольную сумму артефакта, прочтите его оглавление и сравните время последнего резервного копирования с фактически заявленным временем. Разрыв между «задание выполнено успешно» и «данные восстанавливаемы» — это то, что лежит в основе каждой ужасной истории о резервном копировании. В ЭТОМ ВЫПУСКЕ ПОКАЗАНО: Задания резервного копирования Proxmox · NetBox как источник намерения резервного копирования · Снимки томов против копий вне кластера · pg_dump CronJobs и проверка артефакта · Аудитор, который сопоставляет заявленные и выполненные данные Это 2-й эпизод из 11. Серия разбирает инженерную среду саморазмещенной платформы по одной проблеме за раз. В следующем эпизоде: почему сертификат может идеально обновляться, а ваш сайт по-прежнему использует старый сертификат. ▸ virtualelephant.com ▸    / @virtualelephant   💡 Не забудьте: ✅ Поставить лайк этому видео, если оно вам полезно. ✅ Подпишитесь на канал, чтобы получать больше обучающих материалов по платформенной инженерии, Kubernetes и облачным технологиям, а также демонстрацию проектов. ✅ Оставляйте комментарии со своими мыслями или вопросами о проекте. #VMware #Proxmox #Резервноекопирование #платформеннаяинженерия