Резервні копії — це страховка бізнесу. Один збій диска, невдале оновлення плагіна, випадкове видалення таблиці або злам — і сайт перестає працювати. Бекап дозволяє повернутися у робочу точку за хвилини чи години замість довгих простоїв. Щоб зробити процес «безболісним», потрібні прості правила: автоматизація, чіткі RPO/RTO, регулярні тести відновлення та відповідальні ролі. Нижче — практичний чек‑лист Unihost від стратегії 3‑2‑1 до політики зберігання і моніторингу.
Що саме треба резервувати
- Файли застосунку: теми, плагіни, завантаження, статика (uploads).
- Бази даних: MySQL/MariaDB (mysqldump/XtraBackup), PostgreSQL (pg_dump/pg_basebackup).
- Конфігурації: веб‑сервер (Nginx/Apache), PHP‑пули, конфіги CMS, env‑змінні.
- Секрети і ключі: .env, токени інтеграцій — зберігати окремо і шифрувати.
- Інфраструктура: IaC (Terraform/Ansible), Docker compose, версії образів/контейнерів.
- План відновлення: ролі, доступи, місця зберігання, сценарії переключення.
RPO та RTO простими словами
RPO — скільки даних допустимо втратити (наприклад, не більше 30 хвилин).
RTO — за який час система має відновитися (наприклад, за 1 годину). Стратегія бекапів має гарантувати ці цілі: частоту знімків БД, готовність скриптів розгортання, процедури DNS/балансування.
Правило 3‑2‑1 і варіант 3‑2‑1‑1‑0
Три копії, два різні носії, одна копія поза майданчиком. Розширення — одна незмінна (immutable) копія та нуль помилок під час регулярних тестів відновлення.
Мінімальна схема: щоденні локальні копії для швидких відкатів, offsite‑копії в іншому дата‑центрі, щотижневий/щомісячний архів в об’єктному сховищі з версіонуванням.
Типи бекапів
- Повний — просто, але багато місця і часу.
- Інкрементальний — зберігає тільки зміни з останнього бекапу; економно, але довші ланцюжки.
- Диференційний — зміни з моменту останнього повного бекапу; баланс швидкості та обсягу.
Практика: раз на тиждень повний, щодня інкрементальні; для БД — журнали транзакцій і снапшоти томів.
Де зберігати: локально, offsite, object storage
- Локально — швидкі відкати, але єдина точка відмови.
- Offsite — інший сервер/ЦОД; захист від аварій майданчика.
- Об’єктне сховище (S3‑сумісне) — дешеве та гнучке, з версіонуванням і політиками життєвого циклу. Видавайте окремі ключі доступу з мінімальними правами.
Інструменти
- Панелі (cPanel/DirectAdmin/ISPmanager) — вбудовані бекапи з розкладом і вивантаженням на SFTP/S3.
- Снапшоти (гіпервізор/LVM/ZFS) — зручно для «точки в часі», але не заміна файловим бекапам.
- Rsync/Rclone — інкрементальні копії по SSH або в S3.
- Borg/Restic — дедуплікація, шифрування, перевірка цілісності, підтримка S3/SFTP.
- Бази даних: mysqldump/XtraBackup, pg_dump/pg_basebackup; дбайте про консистентність.
Шифрування та доступи
Шифруйте резервні копії, використовуйте менеджери секретів для ключів/паролів. Створіть окремі сервісні облікові записи для бекапів з мінімальними правами, увімкніть 2FA там, де можливо.
Розклад і ретенція (GFS)
Приклад: щоденні інкрементальні, щотижневі повні; БД — знімки кожні 30 хвилин, щоденний повний дамп; зберігання 14/60/90 днів. В object storage — версіонування та immutable‑політики на 7–30 днів для захисту від видалення/шифрувальників.
Перевірка та тест відновлення
Раз на місяць робіть DR‑тренування: розгорніть стенд з копій, заміряйте час, оновіть інструкції. Автоматизуйте перевірку хешів, тестове відновлення вибіркових файлів і дампів.
Моніторинг і сповіщення
Система бекапів повинна сама казати про помилки: невдалий дамп, відсутній доступ до бакету, завершився диск, прострочений ключ. Звіти надсилайте на пошту або у чат, заведіть SLA на час реакції.
Чек‑лист Unihost: крок за кроком
- Визначте RPO/RTO.
- Оберіть схему 3‑2‑1.
- Налаштуйте інструменти.
- Пропишіть розклад і ретенцію.
- Увімкніть шифрування і мінімальні права доступу.
- Додайте моніторинг.
- Проведіть тест відновлення.
- Перед великими релізами — повний бекап.
- Щокварталу — DR‑дрили.
- Навчіть команду.
Поради та особливі випадки
- E‑commerce/CRM: забезпечте консистентність транзакцій.
- Великі медіа — виносьте у CDN/S3, резервуйте метадані.
- Мультисайти — ізолюйте бекапи на рівні префіксів/прав.
- Логи — зберігайте лише необхідні за нормами.
FAQ і висновок
П: Скільки зберігати?
В: Часто 14/60/90 днів + офлайн архіви релізів.
П: Чи замінює реплікація бекап?
В: Ні, помилка реплікується теж.
П: Як боротися зі «зараженими» копіями?
В: Імутабельна політика та версія бакета допомагають відкотитися до «чистої» версії.
П: Що робити при нестачі місця?
В: Включити дедуплікацію/стиск (borg/restic), переглянути ретенцію, винести в об’єктне сховище.
П: Хто відповідає за бекапи?
В: Призначте власника процесу та чергових.
Висновок та наступний крок
Біль від втрати даних незмірно дорожчий за налаштування копій. Впровадьте просту схему 3-2-1, автоматизуйте бекапи файлів та БД, увімкніть шифрування, моніторинг та регулярні тести відновлення. Команда Unihost допоможе підібрати інфраструктуру, налаштувати розклад та політики зберігання, а також перевірити відновлення, щоб за будь-якої аварії ви повернулися до роботи у межах заявлених RPO/RTO.