Как делать дампы правильно: etcd (Kubernetes), rsync, копирование и архивирование
Есть два типа людей: те, кто делает бэкап, и тех, кто будет делать бекапы!
Зачем вообще делать “дампы”, если сейчас всё работает? Потому что бэкап — это не «файл на всякий случай», который лежит где-то в углу и успокаивает совесть. Бэкап — это ваш план возвращения к жизни, когда что-то пошло не так. А «не так» рано или поздно случается у всех: неудачное обновление, человеческая ошибка, внезапно умерший диск, переполненный том, баг в автоматизации, случайный kubectl delete не в том namespace — и вот уже “стабильная” система превращается в гонку на выживание.
Поэтому мы делаем дампы не ради галочки, а ради понятного результата:
- Чтобы восстанавливаться быстро (это про RTO — сколько времени мы готовы быть “в простое”)
- Чтобы не потерять больше данных, чем допустимо (это про RPO — насколько “свежими” должны быть данные после восстановления)
- Самое важное — чтобы заранее проверить, что из этих дампов действительно можно подняться, а не обнаружить в критический момент, что бэкап “есть”, но он битый, неполный или восстановление никто ни разу не делал.
Дамп Kubernetes через snapshot etcd
Что именно мы бэкапим, когда делаем snapshot etcd
etcd — это key-value база, где лежит “мозг” Kubernetes: объекты API (Deployments, Services, Secrets, ConfigMaps, CRDs и т.д.).
Snapshot etcd — это точка во времени состояния API.
Важно: snapshot etcd НЕ заменяет бэкап данных приложений (БД, файлов, PVC) — он про состояние control plane.
Подготовка: что проверить перед snapshot
1. Кластер и etcd “живые”;
2. Есть доступ к сертификатам etcd (обычно на control-plane ноде);
3. Есть место, куда сохранить файл снапшота (желательно не на тот же диск).
На control-plane обычно есть сертификаты etcd в /etc/kubernetes/pki/etcd/.
sudo -i export ETCDCTL_API=3 TS="$(date +%F-%H%M%S)" DIR="$HOME/dump/etcd" mkdir -p "$DIR" etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ snapshot save "$DIR/snapshot-$TS.db"
Проверяем snapshot
etcdctl snapshot status "$DIR/snapshot-$TS.db" --write-out=table sha256sum "$DIR/snapshot-$TS.db" > "$DIR/snapshot-$TS.db.sha256"
Данными командами вы получите файл snapshot-YYYY-MM-DD-HHMMSS.db и контрольную сумму sha256
Главная ошибка в бэкапах: “дамп лежит рядом — значит его нет”
Самая частая и самая дорогая ошибка в резервном копировании звучит невинно:
«Я сделал дамп и положил его в соседнюю папку на этом же сервере».
На практике это почти то же самое, что вообще не сделать бэкап.
Почему? Потому что в реальных инцидентах чаще всего “умирает” не файл, а носитель или сама машина:
- диск внезапно выходит из строя
- файловая система повреждается
- сервер падает и требует переустановки
- администратор чистит место и “случайно” удаляет папку с дампами
- ransomware/вирус шифрует всё, до чего дотянулся
- перепад питания, пожар, кража оборудования
Если дамп лежит на том же диске и на том же хосте, он пропадает вместе с причиной аварии.
Именно поэтому грамотное правило от Оберсет звучит так:
Дамп должен жить на другом физическом сервере
Сделал snapshot / архив / копию — сразу же унеси её:
- на отдельный backup-сервер
- на NAS
- на внешний накопитель
- в удалённое хранилище
Бэкап должен пережить смерть сервера, на котором он был сделан!
rsync
rsync — это утилита для надёжного копирования и синхронизации файлов между серверами (чаще всего поверх SSH). Её любят админы, потому что она умеет переносить данные аккуратно и предсказуемо: сохраняет структуру каталогов, права и даты файлов, показывает прогресс, а главное — при повторном запуске копирует только то, что изменилось (то есть не гоняет заново одинаковые гигабайты). Поэтому rsync отлично подходит именно для бэкапов и “выноса” дампов на отдельный физический сервер: быстро, безопасно и без лишней ручной возни.
Ниже — простая команда, которая отправит файлы snapshot etcd на backup-сервер и удалит их с текущей машины после успешной передачи:
rsync -av --remove-source-files ~/dump/etcd/snapshot-*.db \ username@host:/backup/etcd/ # username — имя пользователя НА удалённом backup-сервере (куда копируем) # host — адрес этого backup-сервера (hostname или IP), куда копируем
Даже опытные администраторы иногда откладывают бэкапы “на потом” — не потому что не понимают их важность, а потому что в ежедневной рутине кажется, что времени ещё много, а система и так работает стабильно. Проблема в том, что сбои почти никогда не происходят “по расписанию”: одна неудачная правка, обновление, сбой диска или человеческий фактор — и выясняется, что последняя рабочая копия лежала в соседней папке на том же сервере. Правильно настроенные дампы — это не пара команд, а привычка: снять, проверить, и сразу унести на другой физический узел, чтобы бэкап действительно пережил аварию. Когда этот процесс отлажен, администрирование становится спокойнее: можно экспериментировать, обновляться и развиваться без постоянного страха “а если всё упадёт”. Если вы хотите внедрить бэкапы без боли и сделать так, чтобы они реально восстанавливались, команда Oberset поможет настроить надёжную схему дампов и хранения под вашу инфраструктуру — от Kubernetes/etcd до файлов, архивов и регулярных проверок восстановления.