Девять вопросов на RPO и RTO, правило 3-2-1, снапшоты, RAID, PITR и restic. Можно перепроходить.
Что проверяем
Девять вопросов по всему треку: механизмы, которые бэкапом не являются,
RPO и RTO, правило 3-2-1, типы бэкапов, снапшоты, RAID, базы и restic.
Ошиблись — не страшно, квиз перепроходится сколько угодно раз. Прогресс
засчитывается, когда все ответы верные.
Что дальше
Схема, которую стоит унести из трека: реплика держит сервис живым при
отказе узла, снапшот отматывает неудачную миграцию, бэкап в другом
хранилище с историей версий спасает от удаления и шифровальщика, а
регулярное тестовое восстановление превращает всё это из надежды в факт.
Квиз · закрепить тему
Проверь, что запомнил
01 Сервер собран на RAID 6, диски целы. Инженер выполнил DROP TABLE не в той базе. Что даст массив?
RAID закрывает ровно один сценарий: отказ диска. Логические ошибки он дублирует на все диски массива, потому что для него это обычная запись.
02 Бэкап делается раз в сутки в 03:00. Авария в 14:00. Какой RPO фактически обеспечен?
Потеряны данные с 03:00 до 14:00, то есть 11 часов работы. Расписание раз в сутки гарантирует RPO не лучше 24 часов, но в конкретной аварии потеря равна времени, прошедшему с последней копии.
03 Что означает буква «ноль» в схеме 3-2-1-1-0?
Дополнительная единица это иммутабельная или офлайновая копия, а ноль — отсутствие ошибок при верификации: копия считается копией только после успешной проверки.
04 В чём разница между инкрементальным и дифференциальным бэкапом?
Из-за этого для восстановления из инкрементов нужна вся цепочка по порядку, а из дифференциала всего два архива: полный и последний дифференциальный.
05 Почему у инструментов с дедупликацией (restic, borg) длинная история хранения стоит недорого?
В прогоне из урока второй бэкап обработал те же 195 KiB, а добавил в репозиторий 1.76 KiB. При этом каждый снимок остаётся самодостаточным: цепочку собирать не нужно.
06 Снапшот LVM создан на работающем томе с базой. Какое утверждение верно?
Место под изменения резервируется сразу, но заполняется постепенно. Переполнение делает классический снапшот недействительным. Согласованности на уровне приложения снапшот сам по себе не даёт.
07 Что нужно, чтобы восстановить Postgres на состояние за минуту до ошибочного DELETE?
Это PITR: разворачивается базовый бэкап, поверх проигрываются журналы до нужного момента. Параметры задаются в postgresql.conf, а в каталоге данных создаётся файл recovery.signal.
08 Команда restic forget --keep-last 2 --prune на репозитории с четырьмя снимками оставила четыре. Почему?
По умолчанию restic группирует снимки по host и paths, и правило хранения работает внутри каждой группы. Снимки с разных хостов образуют разные группы. Поведение меняется флагом --group-by.
09 Реплика Postgres в другой зоне доступности. От чего она НЕ защищает?
Репликация повторяет все изменения, включая ошибочные: DELETE без WHERE доедет до реплики за миллисекунды. Промежуточный вариант это отложенная реплика через recovery_min_apply_delay.
Прогресс сохранён в этом браузере
Почистишь историю или откроешь с телефона, и отметки пропадут.
Оставь почту, они переедут в аккаунт. Пароль придумывать не нужно.
Готово. теперь в аккаунте: прогресс виден с любого устройства.
Мой прогресс
Отметка сохранена только в этом браузере.
Войди,
и прогресс переедет в аккаунт: он будет виден с телефона и не потеряется.