🔥 Пожар в дата-центре Южной Кореи: данные гос-облака безвозвратно утрачены

В конце сентября в ДЦ NIRS в Тэджоне сгорели 96 критичных систем, а облачное хранилище G-Drive — уничтожено: внешних резервных копий не было, копии в том же контуре погибли вместе с системой.

За последние 5 лет было несколько показательных катастроф с потерей данных и простоями:

🔥 Страсбург, OVHcloud в марте 2021. Пожар на кампусе SBG уничтожил часть инфраструктуры; у клиентов — утраты данных, совокупные требования по искам — > €10 млн. Среди пострадавших публично отчиталась и российская компания — её бэкапы лежали рядом с продом и сгорели вместе с ним.

🔥 Париж, Google Cloud europe-west9 в апреле 2023. Протечка воды в здании подрядчика попала в зал источников бесперебойного питания (ИБП), вызвала возгорание и многочасовое отключение одного из зданий региона; у клиентов с данными и снапшотами в одной зоне часть дисков оказалась невосстановимой.

💀 Дания, CloudNordic/AzeroCloud в августе 2023. Атака ransomware (вымогатель-шифровальщик) задела инфраструктуру и бэкапы в том же контуре — провайдер сообщил, что у большинства клиентов утрачены все данные.

⚡️ Бэкап сам по себе — не стратегия: он может сгореть вместе с продом, не влезть в окно RTO или стоить как крыло от самолёта.

Лучше соблюсти баланс между надёжностью (что поднимется и когда) и выгодностью (сколько это стоит), с регулярными тест-ресторами для подтверждения готовности и минимизацией затрат за счёт архитектуры хранения (offsite/immutable, разнесённые контуры, lifecycle-политики).

🥂 Такая схема переживёт пожар, потоп и шифровальщика — и не разорит бюджет.

🖥 Надёжный способ бэкапа PostgreSQL

pg_dump — утилита для создания логических бэкапов PostgreSQL.

В отличие от физического бэкапа, она выгружает объекты (схемы/данные) в переносимый вид. Дамп, как правило, корректно восстанавливается в такую же или более новую версию Postgres.

✅ Основные сценарии

Бэкап одной базы (plain SQL)

pg_dump mydb > backup.sql

Бэкап с компрессией «на лету» (для plain)

pg_dump mydb | gzip > backup.sql.gz

То же, но со встроенной компрессией (для custom/tar/directory)

pg_dump -Fc -Z 9 mydb > backup.dump

Только схема без данных:

pg_dump -s mydb > schema_only.sql 
# или выборочно по схемам: 
pg_dump -s -n public -N audit mydb > schema_public.sql

Бэкап конкретной таблицы:

pg_dump -t public.users mydb > users_backup.sql 
# исключение таблиц: 
pg_dump -T public.logs mydb > no_logs.sql

Параллельный бэкап (работает только с -Fd)

pg_dump -Fd /backups/mydb_$(date +%F) -j 4 mydb

Бэкап всего кластера (все БД + роли/табл.пространства)

pg_dumpall > all_databases.sql 
# только «глобалы» (роли, табличные пространства): 
pg_dumpall -g > globals.sql

Удаляем бэкапы старше 7 дней (недавний пост про find)

find /backups -type f -name "*.sql.gz" -mtime +7 -delete

👀 Дополнительно

-Fc — custom-формат: компактно, выборочное и параллельное восстановление через pg_restore.

-Fd — directory-формат: поддерживает параллельный дамп (-j) и гибкое восстановление.

--no-owner --no-privileges — удобно для переноса между серверами/окружениями.

--exclude-table-data=... — дамп схем без данных отдельных «тяжёлых» таблиц.

⚙️ pg_dump делает снапшот на момент старта дампа, поэтому данные консистентны даже при параллельных транзакциях. Это достигается через механизм MVCC PostgreSQL.
Необходимо учесть, что логические дампы не подходят для PITR — для этого нужны физические бэкапы + WAL.

🔘 Связка pg_dump(-Fc/-Fd) [| gzip] + find -delete — простой и надёжный пайплайн. Но периодически проверяйте восстановление на тестовом стенде и следите за версиями сервера/клиента.

#заметкиИнженера

⚙️ Velero
— инструмент для бэкапа, миграции и аварийного восстановления Kubernetes-кластеров и их данных.

Позволяет безопасно сохранять и восстанавливать ресурсы кластера (поды, deployment, конфигурации), включая прикреплённые тома через снапшоты.

📍 Основной функционал:
— Резервное копирование ресурсов кластера и их восстановление в том же или другом кластере
— Снапшоты постоянных томов (PV)
— Миграция ресурсов между кластерами и облачными платформами
— Планирование бэкапов по расписанию
— Выборочное восстановление ресурсов с фильтрацией по namespace, меткам

📍 Ключевые особенности:
— Поддержка Restic для бэкапа любых томов (включая NFS, hostPath)
— Интеграция с облачными хранилищами (S3, GCS, Azure Blob)
— Расширяемая архитектура через плагины
— Ролевая модель доступа для безопасного использования

Velero превращает сложную задачу резервного копирования Kubernetes в предсказуемый и управляемый процесс.

👉 Git
#полезное

📸 LVM Snapshot: быстрые снимки без простоя

Снимок LVM — это точное состояние логического тома (LV) на момент создания. Он занимает место только для изменённых блоков и создаётся без остановки сервиса.

✅ Как это работает (Copy-on-Write, CoW)

— При создании снимка исходный том и снимок ссылаются на одни и те же данные

— При изменении данных в исходном томе, старые блоки копируются в область снимка перед записью

— Таким образом, снимок хранит только те данные, которые были изменены после его создания

*Речь про «классические» снимки LVM. У thin-томов механика и команды отличаются.

🧑‍💻 Практика

Создать снимок (2 ГиБ под изменения)

lvcreate -s -n my_lv_snapshot -L 2G /dev/my_vg/my_lv

Паспорт snapshot через lvdisplay

lvdisplay /dev/my_vg/my_lv_snapshot

  --- Logical volume ---
  LV Path                /dev/my_vg/my_lv_snapshot
  LV Name                my_lv_snapshot
  VG Name                my_vg
  LV UUID                y9FV7q-8UxB-7MmE-S8No-5A3F-2QJi-8x9LAD
  LV Write Access        read/write
  LV snapshot status     active destination for my_lv
  LV Status              available
  # open                 0
  LV Size                3.00 GiB
  Current LE             768
  COW-table size         2.00 GiB
  COW-table LE           512
  ...

Смонтировать для проверки (читать безопаснее в ro)

mkdir -p /mnt/snapshot
mount -o ro /dev/my_vg/my_lv_snapshot /mnt/snapshot
# Для XFS добавьте: -o ro,nouuid

Откат к снимку (merge)

# Если origin смонтирован, снимите его:
umount /mnt/data

# Запустить merge:
lvconvert --merge /dev/my_vg/my_lv_snapshot

# Если origin был активен/смонтирован, merge произойдёт при следующей активации LV
# (часто это выглядит как "после перезапуска сервиса/узла").

После успешного merge сам snapshot-LV исчезает — это нормально.

Удалить снимок (если не нужен)

lvremove /dev/my_vg/my_lv_snapshot

Важные нюансы

✅ Размер снимка должен покрывать ожидаемый объём изменений. Если CoW-область переполнится, снимок станет неконсистентным и будет потерян.

✅ Снимки читаются и монтируются как обычные тома; писать в snapshot можно, но обычно это не требуется.

✅ Производительность: CoW даёт накладные расходы на запись в origin.

✅ Merge требует, чтобы origin был не смонтирован/не активен; иначе откат откладывается до следующей активации.

✅ Thin LVM: у thin-томов своя логика снапшотов и квот; команды и возможности merge отличаются от classic snapshots.

👍 Отличный способ создать точку возврата перед обновлениями/миграциями: быстрый откат без полного бэкапа и долгого восстановления. (Бэкапы всё равно нужны — снапшоты не заменяют резервное копирование.)

#линуксятина

📚 Книги про бэкапы

Помогут разобраться в бэкапах от базовой механики и утилит — к стратегиям для гибридной инфраструктуры, облаков, SaaS и Kubernetes.

🤓 Backup & Recovery

Практический справочник по планированию и внедрению резервного копирования в смешанных средах с акцентом на Unix/Linux и open-source.

🔎 Рассматривается:

— инвентаризация, расписания, ротации, offsite и регулярные тесты восстановления;
— базовые утилиты: tar/cpio/dump/restore/dd/rsync;
— Amanda, BackupPC, Bacula: архитектура, конфигурации, сценарии восстанавления;
— near-CDP на базе rsync/snapshots (rsnapshot, rdiff-backup);
— носители: ленты/VTL, bare-metal восстановление, бэкап баз данных.

Автор: W. Curtis Preston · Издательство: O’Reilly, 2007

🤓 Modern Data Protection

Руководство по современной стратегии бэкапа и DR: процессы, метрики и инструменты для инфраструктуры.

🔎 Рассматривается:

— RPO/RTO, runbook’и, регулярные проверки восстановления;
— 3-2-1, неизменяемые копии, air-gap, шифрование;
— full/incremental, дедупликация, snapshots, репликация, (near)-CDP;
— защита VMware/Hyper-V, физических серверов, NAS, рабочих станций и мобильных;
— базы данных on-prem и PaaS; SaaS (M365, Google Workspace, Salesforce);
— контейнеры/Kubernetes; модели DR (cold/warm/hot), DRaaS.

Автор: W. Curtis Preston · Издательство: O’Reilly, 2021

✔️ Полезно ИТ-руководителям и архитекторам, которые обновляют стратегию защиты данных под облака и контейнеры; инженерам бэкапа/ИБ, SRE и DevOps, кому важно понимать устройство решений «на земле» и уверенно проводить восстановления; системным администраторам, строящим надёжный бэкап из доступных инструментов в смешанных средах.

#книги #полезное

🛒 Кейс: бэкапы как основа DR для дистрибьютора

Клиент: крупный дистрибьютор продуктов питания с круглосуточной работой и «тяжёлой» ERP.

🔵 Проблема:
при серьёзном сбое компания не была уверена, что сможет быстро восстановить работу из резервных копий — риск простоя, потери данных и денег.

🔵 Почему такие риски:

— не было удалённой DR-площадки, откуда гарантированно подниматься;

— метрики RPO/RTO с бизнесом не были формально согласованы;

— регламенты и тестовые восстановления требовали доработки;

— репликация «журналами» периодически давала расхождения в данных.

🤝 Совместно с заказчиком выстроили DR-процесс «под ключ»:
согласовали RPO/RTO, определили стратегию бэкапов, развернули удалённую площадку, зафиксировали регулярные test-restore и обновляемый runbook — всё, что превращает копии в гарантированное и предсказуемое восстановление.

🔵 Что сделали

✅ Развернули географически удалённую DR-площадку в облаке CORTEL.

✅ Согласовали с бизнесом RPO/RTO и настроили под них стратегию резервного копирования:
— базы данных — онлайн-обновления + полные бэкапы;
— виртуальные машины — ежедневные копии;
— мониторинг успешности бэкапов и регулярные test-restore.

✅ Обеспечили консистентные копии ERP и ускорили восстановление критичных сервисов (в т.ч. за счёт SSD на DR-стороне).

✅ Подготовили DR-план и runbook, распределили роли и ответственность, зафиксировали SLA/поддержку.

🔵 Что получили

👀 Подтверждённые метрики: RTO ≤ 4 часа, RPO < 24 часов.

👀 Предсказуемый подъём из резервных копий по отработанному сценарию.

👀 Снижение операционных рисков и прозрачные процессы восстановления.

➡️Подробную архитектуру, шаги и нюансы читайте в кейсе.

#изПрактики

➡️ Основные стратегии действий в момент аварии и восстановления (DR) в облаке:

➡️ Backup & Restore — просто достаём бэкап и поднимаем систему.
➡️ Pilot Light — заранее подготовлено ядро системы, остальное разворачиваем при аварии.
➡️ Warm Standby — почти рабочая копия, быстрое переключение.
➡️ Multi-Site — всё работает параллельно, авария почти не ощущается.

*чем ниже RTO/RPO — тем выше стоимость.

#полезное #красивое

🔍 Навигация по каналу

Друзья, вы же заметили, что у нас появилось несколько новых регулярных рубрик 🤗

🫥 Чтобы быстро находить нужные материалы — кейсы, инструменты, лайфхаки и т.д. — мы собрали всё по хэштегам.

➡️ #изПрактики — реальные кейсы и результаты проектов.

➡️ #заметкиИнженера — практические лайфхаки от DevOps-инженеров.

➡️ #гайды — пошаговые инструкции и чек-листы “как сделать”.

➡️ #полезное — инструменты, сервисы, песочницы.

➡️ #проИБ — всё, что касается информационной безопасности.

➡️ #линуксятина — всё про Linux.

➡️ #ИТиЗАКОН — регуляторка, изменения, соблюдение требований.

➡️ #книги — то, что стоит прочитать.

➡️ #MentalDebug — поддержка ментального здоровья в ИТ.