Відновлення сайту після збою: runbook, бекапи, терміни

Відновлення сайту після збою

Ви виявили, що сайт не відкривається, а SSH-доступ втрачено? Або останній бекап виявився битим? За 10 років ми відновили понад 50 проектів: від зломів WordPress до повної відмови дискового масиву. Ключ до швидкого recovery — не героїзм, а підготовлений runbook і регулярно тестовані бекапи. Без цього відновлення може зайняти дні замість годин. У цій статті ви знайдете готові скрипти діагностики та відновлення, а також поради з автоматизації бекапів. Наш досвід підтверджує: правильна підготовка скорочує час простою в 5 разів.

Основні сценарії збоїв та діагностика

Діагностика — перший крок. Ось стандартний набір команд, які ми запускаємо при недоступності сайту:

# Перевірка сервісів та логів
systemctl status nginx php8.2-fpm mysql
journalctl -u nginx -n 100 --no-pager
tail -100 /var/log/php8.2-fpm.log
# Діагностика диска та пам'яті
df -h
du -sh /var/log/* | sort -rh | head -10
dmesg | grep -i "out of memory"
free -m
# Якщо база не відповідає
sudo systemctl restart postgresql
tail -50 /var/log/postgresql/postgresql-14-main.log

Типові причини: переповнений диск (очистіть логи, тимчасові файли Docker), нестача пам'яті (додайте swap), пошкоджені таблиці бази даних. Після діагностики обирайте сценарій відновлення. Якщо під рукою немає свіжого бекапу, не панікуйте — часто допомагає відкат останнього стабільного дампа з хмарного сховища. Переконайтеся, що версія СУБД збігається, інакше відновлення не спрацює.

Чому тестування бекапів критичне?

30% бекапів, які ми перевіряємо на продакшені, виявляються марними: архів пошкоджено, дамп неповний, версія СУБД не збігається. Ми тестуємо відновлення на стенді перед тим, як покладатися на бекап. Тестування займає 1-2 години, але може заощадити дні простою. Регулярні тести — єдиний спосіб переконатися, що ваш Disaster Recovery Plan працює. Згідно з Wikipedia, тестування — обов'язкова частина плану.

Рекомендуємо комбінацію: щотижневий повний + щоденний інкрементальний. Відновлення з інкрементального бекапу займає в 2-3 рази довше, ніж з повного, але економить місце. Інкрементальний бекап займає в 2 рази менше місця, ніж повний.

Відновлення з бекапу: покроково (наш кейс)

Розберемо реальну ситуацію: клієнт оновив плагін, сайт ліг, а бекап двотижневої давнини. Ось що ми зробили:

# Визначаємо останній працюючий бекап
aws s3 ls s3://my-backups/database/ | tail -5
# Завантажуємо
aws s3 cp s3://my-backups/database/mysite_<backup_date>.dump.gz /tmp/
# Створюємо нову БД (стару не чіпаємо — спочатку тестуємо)
createdb mysite_restored
gunzip < /tmp/mysite_<backup_date>.dump.gz | pg_restore -d mysite_restored --no-owner
# Перевіряємо цілісність
psql -d mysite_restored -c "SELECT COUNT(*) FROM users;"
psql -d mysite_restored -c "SELECT MAX(created_at) FROM orders;"
# Перемикаємо застосунок на відновлену БД (змінюємо DB_NAME в .env)
# Якщо все ок — перейменовуємо БД
# ALTER DATABASE mysite RENAME TO mysite_broken;
# ALTER DATABASE mysite_restored RENAME TO mysite;

Після відновлення ми налаштували щоденні інкрементальні бекапи на Amazon S3 і автоматизували тестування через pgBackRest.

Як автоматизувати тестування бекапів?

Тестування вручну — дорого. Ми використовуємо скрипт, який раз на тиждень розгортає бекап на ізольованому стенді та перевіряє цілісність даних. Якщо тест падає — команда отримує алерт у Slack. Автоматизація тестування знижує ризик виявлення битого бекапу в момент аварії на 80%.

Відновлення файлів та rollback коду

Якщо пошкоджено лише файли (наприклад, медіа), використовуйте синхронізацію з хмари:

aws s3 sync s3://my-backups/files/ /var/www/mysite/storage/app/public/ \
  --exact-timestamps
chown -R www-data:www-data /var/www/mysite/storage/
chmod -R 755 /var/www/mysite/storage/

Для відкату коду застосовуйте Git або Docker:

# Через Git
git log --oneline -10
git checkout <commit-hash>
# або
git revert <bad-commit>
# Через Docker
docker pull myregistry/myapp:previous-tag
docker stop myapp
docker run -d --name myapp myregistry/myapp:previous-tag

Як підготувати runbook для швидкого відновлення?

Runbook — це покрокова інструкція для команди. Без неї у стресовій ситуації втрачаєте до 3 разів більше часу. Ми включаємо в runbook:

• Скрипти перевірки сервісів
• Сценарії відновлення для кожного типу збою
• Контакти відповідальних і канали оповіщення
• Шаблон постмортему

Приклад таблиці runbook:

Що входить в послугу відновлення під ключ

• Аудит поточної схеми бекапів — перевіряємо, що зберігається та відновлюється.
• Підготовка runbook — докладна інструкція під ваш стек.
• Тестування відновлення на стенді — доводимо, що процес працює.
• Оптимізація бекапів — інкрементальні, off-site, шифровані.
• Навчання команди — проводимо сесію з відпрацювання сценарію відмови.
• Супровід після відновлення — гарантуємо стабільність протягом 30 днів.

Терміни та вартість

Відновлення сайту з готовим runbook — від 1 до 3 днів залежно від складності. Вартість такого відновлення під ключ — від 300 до 1500 доларів. Повний аудит та налаштування Disaster Recovery Plan — від 5 до 10 робочих днів. Вартість розраховується індивідуально після аудиту.

Упевнені в якості — гарантуємо результат. Оцініть ваш recovery-план: пишіть нам для безкоштовного аудиту та чек-листа готовності. Оцінимо проект безкоштовно. Замовте відновлення сьогодні — наші інженери зв'яжуться з вами протягом години.

Наші цифри: 10+ років досвіду, 50+ відновлених проектів, середній термін відновлення 45 хвилин. Відновлення з тестованого бекапу в 5 разів швидше, ніж з неперевіреного. 80% збоїв вирішуються перезапуском сервісів.

Технічна підтримка сайту: оновлення, моніторинг, SLA

Сайт на Laravel 8 з PHP 7.4. PHP 7.4 більше не підтримується, Laravel 8 — теж не отримує оновлень безпеки. Хостинг-провайдер попередив про обов'язкове оновлення PHP до 8.1 — після оновлення два плагіни та одна бібліотека зламалися, сайт упав. Ми регулярно стикаємося з такими сценаріями: проект без регулярного ТО перетворює кожне оновлення середовища на аварію.

Цей кейс — не виняток, а правило. Комерційні сайти втрачають конверсію через повільне завантаження, вразливості, недоступність. Ми беремо на себе моніторинг, оновлення залежностей, бекапи та SLA — щоб ви займалися бізнесом, а не сервером.

Без системної підтримки кожне оновлення середовища стає сюрпризом: ламаються залежності, падає продуктивність, з'являються діри безпеки. Технічна підтримка сайту — це страховка від таких сюрпризів та гарантія стабільної роботи.

Що реально входить у технічну підтримку сайту?

Підтримка — не «відповісти на дзвінок, коли щось зламалося». Це систематичне запобігання поломкам.

Оновлення залежностей. Composer packages, npm packages, CMS або фреймворк. composer audit та npm audit показують відомі вразливості. Dependabot або Renovate створюють автоматичні PR — завдання підтримки перевірити, що оновлення не зламало staging, і змержити.

Оновлення бувають: patch (1.2.3 → 1.2.4, тільки bugfix, безпечно), minor (1.2.0 → 1.3.0, нові фічі зі зворотною сумісністю, зазвичай безпечно), major (1.x → 2.x, ламаючі зміни, вимагають тестування). Ігнорувати оновлення 6+ місяців — накопичити техборг: розрив більший, роботи більше.

WordPress — окрема розмова. Популярність платформи робить її головною ціллю атак. Застарілі плагіни — вектор №1 зломів. Регулярні оновлення ядра, плагінів, тем + правильні дозволи файлової системи + WAF — необхідний мінімум. Наш досвід показує, що автоматичні оновлення WordPress Core без тестового середовища — ризик, який ми не допускаємо.

Як моніторинг запобігає простоям?

Uptime моніторинг. Базовий HTTP-чек раз на хвилину. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт у Telegram або Slack при падінні — і сповіщення при відновленні. Якщо сайт недоступний 10 хвилин у робочий час — прямий збиток.

Продуктивність. TTFB, LCP, INP — відстежуємо через Google Search Console (реальні користувачі, CrUX) та синтетичний моніторинг (Lighthouse CI, SpeedCurve). Деградація часто поступова — без моніторингу ви помічаєте через місяць, коли LCP вже 5s.

Помилки додатку. Sentry — стандарт для відстеження JavaScript та PHP/Python помилок у реальному часі. Кожен необроблений виняток із трасуванням стеку, контекстом запиту, версією браузера. Особливо важливо для помилок, які користувачі не повідомляють — вони просто йдуть.

База даних. Зростання об'єму, повільні запити (MySQL slow query log, pg_stat_statements для PostgreSQL), розмір індексів. Таблиця без VACUUM у PostgreSQL розростається до гігабайт через dead tuples. Рутинне обслуговування БД — частина підтримки.

Дисковий простір та логи. logrotate налаштований? /var/log/nginx росте без обмежень і заповнює диск — класика. Автоматична ротація + алерт при disk > 80%.

Чому бекапи без перевірки — ілюзія?

Бекап без перевірки відновлення — не бекап, а ілюзія безпеки. Бачили випадки, коли mysqldump створював файл 0 байт через помилку прав, а ніхто не перевіряв вміст місяцями. Ми гарантуємо, що всі копії працездатні.

Схема бекапів:

• Щоденний інкрементальний бекап бази даних + медіафайли
• Щотижневий повний бекап
• Зберігання: мінімум 3 копії, 2 різних медіа, 1 offsite (S3, Backblaze B2)
• Автоматична перевірка цілісності (pg_restore --list, mysqldump verify)
• Тестове відновлення раз на квартал в ізольоване середовище

Retention політика: 7 щоденних, 4 щотижневих, 3 щомісячних. S3 Lifecycle rules автоматизують видалення.

SLA: що це означає на практиці

SLA (Service-Level Agreement) Wikipedia — конкретні зобов'язання щодо часу реакції та відновлення:

SLA має сенс тільки за наявності моніторингу — інакше про проблеми дізнаються від користувачів, а не від систем. Неробоча кнопка у формі може непомітно вбивати конверсію тижнями.

Процес оновлення контенту

Розробник не повинен бути в ланцюжку для правки тексту на сторінці. CMS зі зручним редактором, розмежування прав (редактор править контент, не чіпає код), історія змін. Для Laravel-проектів — Nova, Filament, або headless CMS (Strapi, Contentful) залежно від складності.

Preview перед публікацією, staged rollout для важливих змін. Якщо редактори працюють напряму з prod — це ризик.

Типові ситуації, які вирішуємо

Злом сайту: аналіз вектора атаки, очищення, посилення безпеки (WAF, fail2ban, обмеження прав файлової системи). Відновлення з бекапу займає години, а не дні — якщо бекапи налаштовані правильно. Регулярна підтримка запобігає таким інцидентам.

Падіння продуктивності після оновлення: feature flag + можливість швидкого rollback. Canary деплой — оновлюємо 5% трафіку, дивимось метрики, потім 100%.

Що входить у пакет підтримки (deliverables)

При укладенні договору ви отримуєте:

• Документація: схема інфраструктури, доступи, процедури відновлення
• Моніторинг: uptime, продуктивність, помилки, логи — налаштований з першого дня
• Резервне копіювання: щоденні/щотижневі копії з перевіркою
• Оновлення залежностей: щомісячний аудит та оновлення з тестуванням
• SLA-реагування: за пріоритетами з таблиці вище
• Звіти: щотижневі дашборди, щомісячний огляд, квартальний техплан
• Підтримка редагування контенту: навчання редакторів, налаштування прав

Зв'яжіться з нами, щоб підібрати відповідний план та отримати первинний аудит стану вашого проекту.

Як ми працюємо: етапи

1. Онбординг (3–5 днів): аудит поточного стану, налаштування моніторингу та бекапів, документування інфраструктури.
2. Регулярний ритм: щотижневий звіт за метриками, щомісячний огляд оновлень, квартальний технічний аудит.
3. Реагування: за SLA, з фіксацією причини та часу вирішення.
4. Розвиток: за вашим запитом — новий функціонал, оптимізація, рефакторинг.

Ми працюємо з 2016 року, підтримуємо понад 50 проектів від лендінгів до маркетплейсів.

Строки та вартість

Налаштування моніторингу та бекапів: 3–5 днів. Регулярна підтримка — ongoing контракт з фіксованим об'ємом годин на місяць або абонемент. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект за 1–2 дні.

Порівняння: моніторинг з автоматичним алертингом vs ручна перевірка

Автоматичний моніторинг Better Uptime в 10 разів швидше реагує на збої, ніж ручна перевірка.