Бекапи PostgreSQL
Продакшен-операції включають скрипти бекапу і відновлення PostgreSQL з перевіркою контрольної суми і явним підтвердженням руйнівного відновлення.
Бекап і відновлення.
Межі бекапу, відновлення і відкату для бойових деплоїв Limvero.
Контроли бекапу
Бекап і відкат описані як реалізовані операторські процеси, а не як непідтверджені гарантії доступності або відновлення.
Бекап Redis
Бекап Redis підтримує робочі дані: кеш, ліміти запитів і стан реального часу там, де деплой використовує Redis.
Бекап перед міграцією
Бойовий деплой виконує PostgreSQL-бекап перед застосуванням змін бази даних.
Відкат релізу
Відкат використовує підписані релізні маніфести і теги образів з маніфесту, щоб узгоджено перезапустити API, web і фонові задачі.
Експорт клієнта
Експорти клієнта зберігаються з контрольними сумами й обмеженими колекціями, щоб відключення клієнта і підготовка видалення залишалися контрольованими.
Межа провайдера
Зовнішня синхронізація обʼєктного сховища залежить від провайдера і вмикається тільки після вибору та перевірки провайдера сховища.
Очікування відновлення
Відновлення навмисно потребує явних дій, тому що production-дані клієнта не можна змінювати без підтвердження.
Перевірка відновлення
Скрипти відновлення за замовчуванням потребують перевірки контрольної суми і не виконують руйнівне відновлення без явного підтвердження цілі.
Відновлення залежить від масштабу інциденту
Строк відновлення залежить від обсягу даних, хостинг-середовища, типу інциденту, доступності провайдера і договору з клієнтом.
Preflight оператора
Операційні інструменти перевіряють Docker, Compose, shell-скрипти, змінні середовища, edge-конфігурацію і бойовий захист до деплою.
Бекап і відновлення підтримують безперервність, але не замінюють SLA клієнта, договір про відновлення після аварії або перевірку провайдера сховища.
Оберіть продукт для вашого бізнесу.
Limvero Restaurant і Limvero Retail мають окремі сценарії запуску, входи й робочі процеси на спільній захищеній платформі.