Бэкап vs снапшот vs реплика — простое объяснение Зачем это знать? В реальной работе регулярно случается одно из трёх: сервер падает, кто-то удаляет данные, выходит неудачное обновление. Спасают три разных инструмента — бэкап, снапшот и реплика. Они дополняют, а не заменяют друг друга. Три понятия «на пальцах» 💾 Бэкап (backup) Это отдельная копия данных, из которой можно развернуть базу заново — даже на другом сервере, через день/неделю. 📸 Снапшот (snapshot) Это «моментальный снимок» диска/тома в текущем состоянии (LVM/ZFS/EBS и т.п.). 🔹Создаётся быстро, удобно откатиться перед апдейтом. 🔹Хранится на том же хранилище → если диск/массив сломается, снимок пропадёт вместе с ним. 🪞 Реплика (replication) Это вторая копия базы, которая почти в реальном времени «повторяет» изменения с основной. 🔹Нужна для отказоустойчивости и масштабирования чтения. 🔹Если на мастер попала ошибка/удаление, она уйдёт и на реплику. Что решает каждый инструмент Бэкап → «машина времени» 🔹Восстановить состояние за конкретный день/время. 🔹Долгое хранение (архив), юридические требования. Снапшот → «быстрый откат» 🔹Перед деплоем/миграцией: если что-то пошло не так — откат за минуты. 🔹Клонирование окружения для тестов. Реплика → «всегда доступно» 🔹Быстро переключиться при падении мастера (failover). 🔹Разгрузить чтение (направить часть трафика на реплику). Риски и подводные камни ⚠️ Бэкап 🔹«Бэкап есть» не значит «восстановится» — обязательны регулярные тесты восстановления. 🔹Нельзя хранить единственную копию рядом с базой; нужна отдельная площадка и шифрование. Снапшот 🔹Хранится на том же хранилище → общая точка отказа. Реплика 🔹Может отставать (лаг) — отчёты «сейчас» иногда смотрят на прошлое. Практические рекомендации Минимум для проекта 1️⃣ Ежедневный бэкап (полный или инкрементальный) → хранить вне сервера + шифровать. 2️⃣ Раз в неделю — проверка восстановления на тестовом стенде (restore-drill). 3️⃣ Перед любым рискованным обновлением — снапшот тома.