Бекапы

Бекапы бывают разные, глобально они отличаются по следующим критериям:

Скоуп

Грубо говоря что мы собственно говоря бекапируем. К примеру wal-g делает бекап базы данных, а veeam делает бекап виртуальной машины целиком. У разных видов бекапов свой скоуп защищаемых данных. Скоупы которые есть сейчас:

физический сервер
виртуальная машина
база данных pimcore
файлы внутри pimcore
файлы в s3 storage

Гранулярность

С какой точностью мы можем восстановить защищаемый скоуп. К примеру используя wal-g, который сохраняет transaction log изменений в базе данных, мы можем востановится на любой момент времени. То есть гранулярность бекапов грубо говоря одна минута. Или к примеру бекапы при помощи снепшота в hyper-v мы снимаем раз в сутки. Выходит что гранулярность hyper-v бекапов у нас сутки. Гранулярности которые поддерживаются у нас:

заданный момент времени, минута
раз в сутки
раз в неделю
можно любые другие придумать

Глубина

Как далеко мы хотим хранить бекапы. Для обьектов которые небольшие мы можем к примеру хранить бекапы за месяц или даже год. Пример: тот же wal-g, он будет хранить небольшие transaction logs, которые отражают фактическое изменение данных в бд. А к примеру хранить снепшоты всей виртуальной машины будет затратно по месту, и хранить их более чем на неделю назад не оправданно обычно. Глубину хранения для каждого скоупа нужно обсудить отдельно

Тип восстановления

Глобально бекапы делятся по типу восстановления: in place и не in place. Это определяет фактическое восстановление, происходит на старое место или в новое место. Если мы восстанавливаем бекап в новое место, то во-первых нужно это место, а во вторых процесс восстановления еще нужно продолжать, перенося восстановленные бекапы к месту их применения. Пример in place restore: восстановление снепшотов в hyperv будет происходить на место существующей VM. Это очень быстро и с минимальным даунтаймом, но текущий стейт (поломанный) будет поломан.

Схема бекапов

Инкрементальные бекапы

Скоуп: база данных pimcore, файлы в pimcore Гранулярность: минута, т.к. оба инструмента работают с diff Тип восстановления: в новое место.

Используя restic и walg, мы можем в S3 делать бекапы за любой период времени, причем бекапы могут быть зашифрованы. Поскольку хранится только diff и только самих данных PIM, мы можем позволить себе большую глубину хранения, к примеру пол года. Но такой вид бекапов не есть быстрым для восстановления. Поскольку если к примеру будет утеряна виртуальная машина или физический сервер — сначала нужно будет поднять новое окружение и уже затем в него восстанавливать бекапы.

Механизм этих бекапов уже есть, для их корректной работы необходимы от вас настройки отдельного S3 бакета для их хранения.

hyper-v backups

Скоуп: виртуальная машина Гранулярность: раз в день Тип восстановления: in place restore.

Эти бекапы вы сейчас осуществляете, если мне не изменяет память раз в день. Глубина их хранения мне не известна. Основной плюс таких бекапов — возможность восстановить за пару минут. Основной минус — они занимают много места.

Эти бекапы нужно настроить с вашей стороны, в приемлемой форме.

Ситуація по application aware бекапам наступна:

production.pim.brocard.ua (10.10.125.30) — old cluster
- brd-application-production-green (old production, no CI)
  - no backups
- brd-brd-portainer-production-green (portainer bundle, no CI)
  - no backups
staging.pim.brocard.ua (10.10.125.31) - old cluster
- brd-application-feature-green (feature env, with CI)
  - no backups (credentials requested - TODO)
- brd-application-staging-green (staging env, with CI)
  - no backups (credentials requested - TODO)
- brd-brd-traefik-production-green (traefik bundle, no CI)
  - no backups
pimcore.brocard.ua (10.12.125.30) - new cluster
- brd-brd-pc-pr-gr (new production env, with CI)
  - database backups to aws s3 bucket - walg
    - on startup - full backup
    - every 5 minutes or 100mb binlog writes - delta backup (binlog)
    - every hour - full backup
    - every day at 02:00 - old backup pruning (keep 30 last full backups)
  - file backups to aws s3 bucket - restic
    - every 2 hours - incremental backup + old backup pruning (keep last 35 snapshots and keep 7 daily snapshots and keep 8 weekly snapshots and keep 12 monthly snapshots and keep 2 yearly snapshots)
    - every week on saturday at 02:00 - backup verification
- brd-brd-gf-pr-gr (grafana bundle, with CI)
  - database backups to aws s3 bucket - walg
    - on startup - full backup
    - every 5 minutes or 16mb wal writes - delta backup (wal)
    - every day at 01:00 - full backup
    - every week on saturday at 02:00 - full backup + pruning (keep last 20 full backups)
    - 03:00 on the first day of the month - full backup + pruning (keep last 10 full backups)
  - file backups to aws s3 bucket - restic
    - every 30 minutes - incremental backup + old backup pruning (keep last 35 snapshots and keep 7 daily snapshots and keep 8 weekly snapshots and keep 12 monthly snapshots and keep 2 yearly snapshots)
    - every week on saturday at 02:00 - backup verification
- brd-brd-lk-pr-gr (loki bundle, with CI)
  - no backups
- brd-brd-pr-pr-gr (prometheus bundle, with CI)
  - no backups
- brd-brd-pt-pr-gr (portainer bundle, with CI)
  - no backups
- brd-brd-tr-pr-gr (traefik bundle, with CI)
  - no backups

Для налаштування бекапу для баз даних та файлового бекапу для feature та staging оточень я, раніше, просив по пошті бакет та креди для доступу, проте мені їх не дали, тож, якщо будуть - то зможу доналаштувати. Інструменти для бекапу баз даних та файлового бекапу підтримують бекап у віддалене сховище по s3 проколу, підтримують архівацію, дедуплікацію та шифрування (усе це ввімкнено). По інфраструктурі - бекапи є у grafana, а інші сервіси не мають бекапів. Поточні бекапи розраховані на відновлення на випадок повної втрати VM. Якщо буде треба - то можна налаштувати бекап і для інших інфраструктурних сервісів.

Базова, верхньорівнева процедура відновлення на випадок втрати VM:

автоматизоване налаштування нової VM після отримання доступу
ручне відновлення секретів
автоматичний деплой сервісів на CI
автоматизоване відновлення останнього бекапу бази данних та останнього файлового снапшоту
перевірка корректності роботи після відновлення

Плюси поточної реалізації application aware backup:

Бекап бази данних відбувається максимально корректно, за допомогою стабільного протоколу, який використовується для master-slave реплікації
Для бази доступне point-in-time-recovery
За рахунок дедуплікації, архівації, та дельта бекапів - займається мало місця на мережевому диску
Усі дані на мережевому диску зашифровані
Інструменти мають підтримку prometheus exporters, за допомогою яких можна відслідковувати стан бекапів, та надсилати сповіщення у випадку блокування віддаленого сховища, чи затримці останнього бекапу (зараз не зроблено, можна доналаштувати)
Інструменти мають підтримку різних протоколів для доступу до віддаленого сходища, як то sftp \ rest \ s3 \ swift \ rclone
За рахунок дельта бекапів і їх малого розміру, ми можемо збільшити частоту бекапів до раз на 5 хвилин
Використання віддаленого сховища у стороннього вендора (s3), яке не має vendor lock, тож можемо мігрувати між провайдерами
Можливість майже безкоштовного бекапу через free tier у сторонніх вендорів
Можливість on-demand відновлення із бекапу конкретного оточення на комп'ютері розробника
Можливість налаштування fallback backup storage для бекапу у резервне сховище, якщо основне недоступне (walg)
Можливість верифікувати коректність даних шляхом вичитування по розкладу вмісту усіх файлів, що попадають у snapshot (restic)
Малий розмір бінарних файлів ~ 20mb, та підтримка amd64 та arm64, бінарні файли доступі на github
Використовувані інструменти мають відкритий вихідний код

Мінуси поточної реалізації application aware backup:

Бекап тільки даних, тож якщо VM втрачено, ми вимушені її переналаштовувати, використовуючи автоматизовані рішення (ansible)
Бекап секретів для swarm cluster відсутній, тож вони бекапуються та відновлюються вручну
Процедура відновлення автоматизована, проте не автоматична (що можна додатково покращити)
Бекап включений тільки для частини оточень
ВІдсутнє погодження на проведення випробувань відновлення із бекапів

Також, додам що наявність зовнішніх бекапів на рівні гіпервізору дає можливість пришвидшити відновлення, тобто можна буде відкотити VM на останній бекап у гіпервізорі, і далі, відновити дані із бекапу бази та файлового бекапу.

По поточним політикам зберігання та автоматичного видалення старих бекапів - можно зручно через репозиторій вносити зміни. Якщо немає якихось суттєвих обмежень по розміру бекапів - то можна буде запусти їх створення частіше.

Інструменти для автоматичного application aware бекапу інтегровані для оточень як окремі swarm services, що дає можливість їх швидко активувати для нових оточень. Скрипти та розклад запуску - знаходяться у репозиторії, бінарні файли запаковані у образи контейнерів, і можуть автоматично оновлюватися на CI, при збірці коду для pimcore. Для прискорення та спрощення процесу відновлення із бекапів були підготовлення окремі swarm services, де вже є потрібні бінарні файли, конфігураційні файли та секрети.