MySQL проти MariaDB на VPS: mysqldump проти фізичних резервних копій

Справжня боротьба: час відновлення, консистентність і I/O

Більшість команд сперечається про бекапи, ніби це теологічна дискусія: логічні дампи портативні проти фізичні бекапи швидкі. На VPS все куди гірше і практичніше:

• Цільове час відновлення (RTO): скільки часу ви можете бути недоступні, поки відновлюєте дані.
• Цільова точка відновлення (RPO): скільки даних ви готові втратити (хвилини? години?).
• Консистентність: чи можна відновити бекап без корупції або втрачених зв’язків.
• Вплив: чи стає час бекапу «планованим простою», бо I/O насичує диск.
• Операційне тертя: чи хтось взагалі тестує відновлення, бо процес надто болісний.

mysqldump перемагає в простоті й портативності. Фізичні бекапи перемагають у швидкості й, при правильному підході, консистентності під навантаженням. Але на VPS—де сховище часто мережеве, «стрибкоподібне» й розділене—фізичні бекапи також можуть швидко виявити ваш ліміт IOPS.

Правило, якого я дотримуюся в продакшені: вибирайте метод бекапу, який ви зможете швидко і регулярно відновлювати. Усе інше — дрібниці.

Факти й історія, які важать більше, ніж здається

Це не цікаві факти для вікторини в пабі. Кожен із них пояснює, чому «простий» план бекапів ламається о 03:00.

1. MariaDB почалася як форк MySQL після того, як Oracle придбав Sun (а з ними і MySQL). Історія форку все ще проявляється у різних інструментах і налаштуваннях за замовчуванням.
2. InnoDB став движком за замовчуванням у MySQL 5.5. Багато підходів до бекапів покладаються на відновлення InnoDB і журнали редо; MyISAM так не працює.
3. Percona XtraBackup популяризував «гарячі» фізичні бекапи для InnoDB. Це сформувало очікування: «фізичний бекап має бути онлайн».
4. MariaDB постачає MariaBackup (mariabackup), походить від лінії XtraBackup, але сумісність версій важить більше за маркетингові назви.
5. MySQL 8 сильно пішов у бік GTID і більш структурованої реплікації. Це змінює підхід до точкового відновлення та зберігання binlog.
6. File-per-table (innodb_file_per_table) став поширеним, що зменшує проблему «одного великого ibdata1», але одночасно збільшує метадані файлової системи під час бекапів.
7. Формат журналів редо і словник даних змінилися, через що деякі фізичні відновлення між версіями стали болісними. Логічні дампи повільніші, але часто більш толерантні між мажорними релізами.
8. «Локальний SSD» у VPS часто насправді мережевий під капотом. Ваша стратегія бекапів має враховувати шумних сусідів і змінну затримку.

Парафраз ідеї Вернера Фогельса (reliability/operations): Все ламається постійно; проектуйте системи так, щоб вони припускали відмови і відновлювалися швидко. Це і про бекапи теж.

Типи бекапів на VPS: логічні, фізичні та знімки

Логічні бекапи (mysqldump, mysqlpump)

Логічні бекапи експортують схему й дані як SQL (або іноді текстові формати). Переваги:

• Портативні між ОС/файловими системами і часто між версіями.
• Селективні: одна база, одна таблиця, навіть фільтровані рядки (з клопотом).
• Легко переглядати стандартними інструментами.

Недоліки:

• Повільне відновлення на великих об’ємах.
• Генерують великі тимчасові I/O і навантаження на CPU; можуть знищити малий VPS.
• Консистентність залежить від движка і прапорів. За замовчуванням не варто довіряти.

Фізичні бекапи (mariabackup, xtrabackup, сире копіювання)

Фізичні бекапи копіюють фактичні файли бази даних плюс достатньо метаданих/журналів для відновлення консистентності. Переваги:

• Швидке відновлення (копіювання файлів + фаза підготовки).
• Краще підходять для великих InnoDB даних.
• Можуть бути гарячими/онлайн при правильних інструментах.

Недоліки:

• Сумісність між версіями може бути суворою.
• Інструменти можуть бути примхливими на «мінімальних» VPS-дистрибутивах.
• Бекапи менш читабельні для людини; перевірка інша.

Файлові/блокові знімки (LVM, ZFS)

Знімки самі по собі не є бекапом. Це механізм захоплення стану. Потрібно експортувати дані зі знімка кудись ще і мати план відновлення.

На VPS у вас може бути або не бути LVM чи ZFS. Якщо є — знімки можуть зменшити час простою (або уникнути його), зробивши майже миттєву копію під час короткого блокування або принаймні скидання кешів MySQL.

MySQL vs MariaDB: інструменти для бекапів і підводні камені

На рівні «backup API» MySQL і MariaDB схожі: обидва говорять SQL, мають бінлоги, обидва можуть дампити схеми. Практичні відмінності проявляються в зрілості інструментів, пакуванні й тому, наскільки суворою є сумісність фізичних відновлень між версіями.

MariaDB: mariabackup — зазвичай пряма відповідь

Якщо ви запускаєте MariaDB і ваші дані здебільшого InnoDB, то mariabackup зазвичай є дефолтним вибором для фізичних бекапів. Він спроектований як «офіційний» інструмент гарячого бекапу і зазвичай відстежує особливості MariaDB.

MySQL: фізичні бекапи залежать від екосистеми

Oracle MySQL має продуктовий enterprise backup, але в реальному світі VPS-флотів ви будете бачити:

• mysqldump (усюди, на добре і гірше)
• Percona XtraBackup (поширений, особливо для InnoDB-навантажень)
• Знімки там, де операційна зрілість і сховище це дозволяють

Крос-сумісність: припиніть думати, що «в основному те саме»

Логічні дампи зазвичай більш портативні між MySQL і MariaDB, ніж фізичні бекапи. Фізичні бекапи прив’язані до форматів на диску, реалізацій редо/андо та поведінки, специфічної для версій. Якщо плануєте міграцію движка або мажорну версію, дампи плюс бінлоги (або cutover на основі реплікації) зазвичай надійніші, ніж спроба «підняти й перенести» сирі файли.

mysqldump: для чого підходить і де вводить в оману

mysqldump — це еквівалент ізоляційного скотчу для бекапів: негарно, не завжди доречно, але він у кожному ящику. На малому VPS це часто найменш поганий старт, бо передбачуваний і не потребує екзотичних пакетів.

Коли використовувати mysqldump

• Ваш обсяг даних достатньо малий, щоб відновлення вкладалося в RTO.
• Потрібна портативність між версіями або між MySQL і MariaDB.
• Потрібні селективні бекапи (окремі бази/таблиці).
• Ви готові прийняти вищі навантаження CPU і I/O під час вікон бекапів.

Остерігайтеся цих режимів відмов

• Незконсистентні бекапи, якщо не використовувати правильні прапори для InnoDB.
• Блокування таблиць (або метаданих), що призупиняє трафік додатка.
• Гігантські одноядерні часи відновлення, які перетворюють інциденти на довгі вихідні.
• Відсутні об’єкти, якщо забути про процедури, тригери, події або користувачів.

Жарт №1: Бекап, який ніколи не тестували, називається «оптимізм», і це не рівень зберігання.

Консистентність дампу: прапори, що мають значення

Для баз, орієнтованих на InnoDB, мінімум — --single-transaction. Але це не магічний щит. Довготривалі транзакції можуть роздувати undo/redo і роблять ваш дамп повільною катастрофою.

Що я зазвичай використовую на VPS:

• --single-transaction для консистентності InnoDB без глобальних блокувань.
• --routines --triggers --events щоб захопити нефайлові об’єкти.
• --set-gtid-purged=OFF у багатьох змішаних середовищах, щоб уникнути сюрпризів з GTID (по ситуації).
• --hex-blob щоб уникнути проблем з кодуванням.
• --master-data=2 (або принаймні координати binlog) якщо потрібен PITR.

Фізичні бекапи: mariabackup, xtrabackup і сирі копії файлів

Фізичні бекапи — це копіювання сторінок InnoDB плюс журнали, потрібні для приведення їх у консистентний стан. Обіцянка: відновлення швидке, бо ви не відтворюєте SQL; ви повертаєте файли й даєте InnoDB зробити reconciliation у стилі відновлення після аварії.

mariabackup (MariaDB)

mariabackup може робити гарячі бекапи InnoDB і має крок «prepare» для застосування журналів редо. Він також може стримити й стискати потік, що важливо для мереж і маленьких дисків на VPS.

xtrabackup (поширений в екосистемах MySQL)

XtraBackup — це робоча конячка для гарячих фізичних бекапів у багатьох організаціях. Операційна модель схожа: backup → prepare → restore (copy-back) → виправити права → запустити сервер.

Сирі копії файлів: тільки з потрібними запобіжниками

Копіювати /var/lib/mysql за допомогою rsync, поки MySQL запущений — це шлях до створення пошкоджених бекапів. Сирі копії мають сенс лише коли ви гарантуєте консистентність на рівні файлової системи (знімок) або зупиняєте MySQL коректно.

Жарт №2: «Я просто rsync-ну datadir живцем» — це еквівалент фрази «я просто жонглюватиму ножами, щоб заощадити час».

Болі, специфічні для VPS: вибухи I/O і шумні сусіди

Фізичні бекапи можуть надзвичайно навантажувати I/O. Це не проблема сама по собі — поки платформа не починає стравлювати вас. Результат виглядає як проблема бази, але насправді це обмеження платформи: високий iowait, завислі запити, відставання реплікації і бекапи, що тривають довше, чим більше ви їх «оптимізуєте».

На VPS плануйте під троттлінг: обмежуйте паралелізм бекапу, компресію з урахуванням компромісу CPU ↔ I/O, і запускайте з ionice/nice там, де доречно.

Бінлоги: різниця між «бекапом» і «відновленням»

Нічний повний бекап не є стратегією відновлення, якщо ваш RPO менше ніж 24 години. Бінлоги — найпростіший спосіб заповнити цю прогалину: ви відновлюєте останній повний бекап, потім програєте бінлоги до певного часу/позиції/GTID.

На VPS бінлоги також дозволяють рідше робити повні дампи. Повні бекапи важкі; інкрементальне відновлення через бінлоги значно дешевше.

Практичні поради

• Увімкніть бінлоги, якщо вам важливий PITR.
• Розрахуйте зберігання бінлогів на основі того, скільки часу ви витрачаєте, щоб помітити погані дані і зреагувати.
• Копіюйте бінлоги поза хостом. Локальна ретенція — не бекап; це зручність.
• Практикуйте одне відновлення з PITR. Воно завжди дивніше, ніж ви очікуєте.

Практичні завдання: 14 команд, виводів і рішень

Ось перевірки, які я реально виконую на VPS-системах. Кожне завдання містить: команду, приклад виводу, що означає вивід і яке рішення ухвалюєте далі.

Завдання 1: Підтвердити, який саме сервер ви запускаєте

cr0x@server:~$ mysql -e "SELECT VERSION() AS version, @@version_comment AS comment\G"
*************************** 1. row ***************************
version: 10.11.6-MariaDB-0+deb12u1
comment: Debian 12

Значення: Версія і пакування дистрибутиву. Це важливо для сумісності фізичних бекапів і налаштувань за замовчуванням.

Рішення: Якщо MariaDB — віддайте перевагу mariabackup. Якщо MySQL 8 — перевірте, чи будете використовувати mysqldump, знімки або XtraBackup.

Завдання 2: Перевірити розмір даних і розклад файлів

cr0x@server:~$ sudo du -sh /var/lib/mysql
18G	/var/lib/mysql

Значення: Орієнтовний розмір для відновлення.

Рішення: Якщо це >10–20 GB на малому VPS, дампи відновлюватимуться повільно. Плануйте фізичні бекапи або принаймні швидші робочі процеси відновлення (паралельний імпорт, більший інстанс для відновлення тощо).

Завдання 3: Визначити суміш движків (InnoDB vs MyISAM)

cr0x@server:~$ mysql -e "SELECT ENGINE, COUNT(*) tables FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY ENGINE;"
ENGINE		tables
InnoDB		312
MyISAM		4

Значення: --single-transaction захищає консистентність InnoDB; MyISAM може вимагати блокувань для консистентних дампів.

Рішення: Якщо у вас є важливі MyISAM таблиці — або погоджуйтеся на блокування таблиць під час дампу, або мігруйте їх в InnoDB.

Завдання 4: Перевірити налаштування binlog і GTID

cr0x@server:~$ mysql -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'gtid_mode'; SHOW VARIABLES LIKE 'server_id';"
Variable_name	Value
log_bin		ON
Variable_name	Value
gtid_mode	OFF
Variable_name	Value
server_id	1

Значення: Бінлоги увімкнені, GTID вимкнено (поширено для MariaDB або старіших MySQL), server_id встановлено.

Рішення: Якщо log_bin=OFF і вам потрібен PITR — увімкніть його (з плануванням дискового простору). Якщо GTID увімкнено — відрегулюйте прапори дампу і кроки відновлення відповідно.

Завдання 5: Отримати поточну позицію binlog для прив’язки PITR

cr0x@server:~$ mysql -e "SHOW MASTER STATUS\G"
*************************** 1. row ***************************
File: binlog.000214
Position: 90123318
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:

Значення: Це ваша «стартова лінія» для програвання, якщо ви робите знімок або фізичний бекап прямо зараз.

Рішення: Запишіть це в метадані бекапу. Якщо не можете зв’язати бекапи з координатами binlog (або GTID), PITR стає гаданням.

Завдання 6: Виміряти тиск на I/O під час вікна бекапу

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 	12/31/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.21    0.00    2.33   41.18    0.72   49.56

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              9.00  210.00  512.0  6144.0   12.40  58.30  99.80

Значення: 40%+ iowait, 99% завантаження диска і високий await. Це насичення сховища, а не «повільний SQL».

Рішення: Тротлити бекапи, перемістити ціль бекапу поза хост, планувати інакше або апгрейднути диск/клас I/O. Також розгляньте фізичні бекапи з контрольованим паралелізмом замість величезних логічних дампів.

Завдання 7: Подивитися, чи бекапи блокуються на метаданих

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;"
Id	User	Host	db	Command	Time	State	Info
42	root	localhost	NULL	Query	12	Waiting for table metadata lock	FLUSH TABLES WITH READ LOCK
87	app	10.0.2.10:51234	prod	Query	12	Sending data	SELECT ...

Значення: Крок бекапу, що вимагає блокування, очікує — ймовірно, його блокує DDL або довгий запит.

Рішення: Уникайте FTWRL на гарячих шляхах. Віддавайте перевагу --single-transaction для дампів і гарячим фізичним бекапам для InnoDB. Якщо блокування необхідні — плануйте вікно для DDL.

Завдання 8: Запустити відносно безпечний mysqldump з мінімумом пасток

cr0x@server:~$ mysqldump --single-transaction --routines --triggers --events --hex-blob --master-data=2 --databases prod | gzip -1 > /backups/prod.sql.gz
cr0x@server:~$ ls -lh /backups/prod.sql.gz
-rw-r--r-- 1 root root 1.9G Dec 31 02:14 /backups/prod.sql.gz

Значення: Бекап створено. Розмір дає уявлення про час відновлення і коефіцієнт стиснення. --master-data=2 вбудовує координати binlog як коментар.

Рішення: Якщо це займає занадто багато часу або шкодить продуктивності — перейдіть на фізичні бекапи і/або робіть дампи з репліки.

Завдання 9: Перевірити, що дамп містить те, що ви очікуєте

cr0x@server:~$ zgrep -m1 -E "MASTER_LOG_FILE|CHANGE MASTER" /backups/prod.sql.gz
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000214', MASTER_LOG_POS=90123318;

Значення: Координати binlog записано.

Рішення: Якщо відсутні — ви не зможете виконати чистий PITR з цього дампу. Виправте прапори і перезапустіть.

Завдання 10: Створити фізичний бекап за допомогою mariabackup (MariaDB)

cr0x@server:~$ sudo mariabackup --backup --target-dir=/backups/mariabackup/full --user=backup --password='***'
[00] 2025-12-31 02:10:11 Backup created in directory '/backups/mariabackup/full'
[00] 2025-12-31 02:10:11 Writing backup-my.cnf
[00] 2025-12-31 02:10:11 Completed OK!

Значення: Зібрано сирі файли і метадані.

Рішення: Негайно виконайте підготовку. Непідготовлений фізичний бекап не готовий до відновлення.

Завдання 11: Підготувати фізичний бекап (застосувати журнали редо)

cr0x@server:~$ sudo mariabackup --prepare --target-dir=/backups/mariabackup/full
[00] 2025-12-31 02:13:52 Starting to apply redo log
[00] 2025-12-31 02:14:20 Redo log applied
[00] 2025-12-31 02:14:20 Completed OK!

Значення: Бекап тепер консистентний і готовий до copy-back.

Рішення: Якщо prepare довго триває — ви обмежені I/O; розгляньте швидші диски для етапу підготовки або відвантаження підготовки на хост відновлення.

Завдання 12: Перевірити здоров’я InnoDB і тиск на чекпоінти

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,60p'
=====================================
2025-12-31 02:15:02 INNODB MONITOR OUTPUT
=====================================
...
Log sequence number          128392001928
Log flushed up to            128392001928
Last checkpoint at           128391771200
...

Значення: Якщо чекпоінт відстає сильно, бекапи і великі записи можуть створити тиск на відновлення/скидання.

Рішення: Якщо бачите хронічний лаг чекпоінта — налаштуйте розмір журналів редо (залежить від двигуна/версії), buffer_pool і поведінку flush; також уникайте запуску бекапів під піковим записом.

Завдання 13: Перевірити відставання реплікації (якщо бекап робиться з репліки)

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep "Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 57

Значення: Репліка відстає приблизно на 1 хвилину.

Рішення: Якщо відставання в межах вашого RPO — робити бекапи з репліки зменшує навантаження на продакшн. Якщо відставання зростає під час бекапу — ви насичуєте I/O або CPU; тротліть.

Завдання 14: Репетиція відновлення на тому ж хості (санітарна перевірка)

cr0x@server:~$ zcat /backups/prod.sql.gz | head -n 20
-- MySQL dump 10.13  Distrib 8.0.36, for Linux (x86_64)
--
-- Host: localhost    Database: prod
-- ------------------------------------------------------
-- Server version	10.11.6-MariaDB-0+deb12u1
...

Значення: Ви перевіряєте, що можете прочитати бекап і він містить очікувані шапки. Це не повний тест, але ловить помилки «порожній файл» і «неправильна ціль».

Рішення: Заплануйте реальний тест відновлення на тимчасовий інстанс. Якщо ніколи цього не робите — навчитеся під час інциденту, коли адреналін руйнує клавіатурну точність.

Швидкий план діагностики: знайти вузьке місце за хвилини

Коли бекапи повільні або додаток падає під час бекапів, не починайте зі зміни інструментів бекапу. Почніть з визначення, якого ресурсу вам бракує.

Перше: доведіть, чи це насичення сховища

• Перевірте iowait і disk await (iostat -xz). Високий await і %util близько 100% означає, що ви обмежені I/O.
• Перевірте місце на файловій системі і інодіти тиск інодів (df -h, df -i).
• Перевірте, чи VPS не тротлить IOPS (симптом: періодичні паузи, «пилкоподібна» пропускна здатність).

Що робити далі: тротліть компресію/паралелізм, перемістіть ціль бекапу поза основний диск або апгрейдніть клас сховища VPS. Якщо не можете — використайте репліку для бекапів.

Друге: перевірте блокування і довгі транзакції

• SHOW PROCESSLIST для метаданих блокувань.
• Статус двигуна для довгого history list / purge lag (InnoDB).
• Шукайте DDL під час бекапів.

Що робити далі: плануйте бекапи не під час міграцій, встановіть вікна для DDL і уникайте підходів на основі FTWRL, якщо не можете терпіти затримки.

Третє: перевірте CPU-конкуренцію (компресія і одноядерні дампи)

• Перевірте top або pidstat для mysqldump і gzip, які вантажать CPU.
• На крихітних VPS рівень компресії — це налаштування продакшну.

Що робити далі: зменшіть рівень стиснення, стискуйте поза хостом або перейдіть на стримінг фізичних бекапів з контрольованим використанням CPU.

Четверте: перевірте мережу (бекупи поза хостом і стримінг)

• Якщо ви стримуєте бекапи в об’єктне сховище або на інший вузол — перевірте стабільність пропускної здатності.
• Втрати пакетів і ретрансляції перетворюють «стримінг бекапу» на «випадковий лімітатор швидкості».

Типові помилки: симптом → причина → виправлення

1) Бекап пройшов, але відновлення не вдається через відсутні процедури/тригери

Симптом: Помилки додатка після відновлення: відсутні збережені процедури, тригери не спрацьовують, розклади подій відсутні.

Причина: Дамп виконано без --routines --triggers --events.

Виправлення: Додайте прапори, перезапустіть бекапи і протестуйте відновлення. Також включіть системні об’єкти mysql, якщо покладаєтеся на користувачів/привілеї.

2) mysqldump призводить до зупинок у продакшні

Симптом: Запити зависають; ви бачите «Waiting for table metadata lock».

Причина: DDL під час дампу або опції дампу, які примушують блокування (або таблиці MyISAM).

Виправлення: Встановіть вікна для міграцій, конвертуйте MyISAM, використовуйте --single-transaction, і розгляньте бекапи з репліки.

3) Фізичний бекап відновлюється, але InnoDB не стартує

Симптом: MySQL/MariaDB не стартує після copy-back; InnoDB скаржиться на файли журналів або словник даних.

Причина: Несумісність версій, пропущений крок prepare, неправильні права або змішування файлів з різних серверів.

Виправлення: Переконайтеся, що версія інструменту бекапу відповідає очікуванням мажорної версії сервера, виконайте prepare, виставте правильного власника (mysql:mysql) і відновлюйте весь datadir консистентно.

4) Бекапи «швидкі», але відставання реплікації вибухає

Симптом: Seconds_Behind_Master зростає під час вікна бекапу.

Причина: I/O бекапу конкурує з аплай-реплікацією; VPS диск досягає капу IOPS.

Виправлення: Тротліть бекап, змініть розклад, перемістіть бекапи на інший диск/том або апгрейдніть клас I/O. За можливості розміщуйте relay logs на окремому сховищі.

5) Можете відновити, але це займає вічність і додатки таймаутять

Симптом: Відновлення дампу триває години; додатки таймаутять навіть після «підняття» БД.

Причина: Логічне відновлення одно-потокове, індекси перебудовуються, buffer pool холодний, і ви на малому VPS.

Виправлення: Віддавайте перевагу фізичним відновленням для великих наборів; інакше відновлюйте на більший тимчасовий інстанс, розігрівайте кеші і лише потім переключайте трафік.

6) «Ми маємо бекапи», але вони на тому самому VPS

Симптом: Диск VPS виходить з ладу; бекапи гинуть разом з ним.

Причина: Зберігання бекапів лише локально.

Виправлення: Копії поза хостом. Інша домен відмови. Завжди.

7) Знімки відновлюються неконсистентно

Симптом: Відновлена БД має корупцію або відсутні останні підтверджені транзакції.

Причина: Знімок зроблено без коректного скидання/блокування; ви захопили стан під час аварійного запису без покриття редо-журналом.

Виправлення: Поєднуйте знімки з координацією MySQL (flush, lock стратегії, що відповідають двигуну), або використовуйте гарячі фізичні інструменти, які включають redo/prepare кроки.

Три корпоративні історії з польових бекапів

Міні-історія 1: Інцидент через хибне припущення

Вони запускали середній SaaS на одному «потужному» VPS. Бекапи були нічним mysqldump на другий диск, змонтований у /backups. Команда відчувала себе відповідальною. У них навіть була ретенція: сім днів. Це завжди звучить заспокійливо на зустрічах.

Потім провайдер VPS мав подію зі сховищем. Інстанс перезавантажився, повернувся, але MySQL не стартував. Їхня реакція була спокійна: «Не проблема, відновимо з вчорашнього.» Однак диск для бекапів був тією ж віртуальною групою блоків на тому ж фізичному сховищі. Він був приєднаний, але файлову систему було знищено. Файли бекапу «існували» так само, як існує зруйнована будівля.

Хибне припущення було тонким: вони вірили, що другий змонтований том — це друга домен відмови. У цього провайдера — ні. Це була просто інша частина того ж пулу. Постмортем не був драматичним. Він був гіршим: тихим приниженням і повністю запобіжним.

Виправлення було нудним: бекапи після створення перемістили поза хост, а відновлення проганяли щомісяця на тимчасовому інстансі. Також вони почали документувати місце зберігання у термінах провайдера — регіон, пул і тип приєднання — бо «том» у світі VPS може означати що завгодно.

Міні-історія 2: Оптимізація, що обернулась проти

Інша компанія хотіла швидших бекапів. Вони перейшли з дампів на фізичні бекапи зі стримінговим стисненням. Інженер, який це робив, був компетентним і агресивним — найкращий тип, поки ним не стане. Вони ввімкнули паралельні потоки бекапу і підвищили стиснення, бо зберігання «дороге». На папері виглядало чудово: менші бекапи, швидше передача, менше грошей.

У продакшні VPS мав два vCPU. Стиснення почало їсти CPU, наче йому заборгували. MySQL почав конкурувати за CPU, потім за I/O, бо бекап також агресивно читав з datadir. Затримки зросли. Відставання репліки зросло. Їхні воркери черги таймаутнули. Інцидент оголошено.

Болісний урок: «швидший бекап» може означати «швидше споживати ваші єдині ресурси». Оптимізація була локально раціональною і глобально катастрофічною. На VPS немає «додаткового CPU» за кулісами.

Виправлення було поміркованим: зменшили паралельність, знизили рівень стиснення і запускали бекапи з репліки з трохи більшим CPU. Також ввели тротлінг I/O і припинили намагання робити бекапи «безкоштовними». Бекапи коштують ресурсів. Ви вирішуєте, де платити: під час бекапу, під час відновлення або під час інцидентів.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда зробила непопулярну річ: квартальні повні відпрацювання відновлення. Не стілова вправа. Реальне відновлення на чисту VM, додаток підключено, виконуються базові перевірки цілісності, і людина підписує. Ніхто не хвалився цим, бо це не блискуча архітектура.

Потім деплой додатку ввів руйнівну міграцію. Було видалено стовпець, і ORM охоче записав null-значення. Вони помітили це протягом години. Питання було не в тому, чи мають бекапи — а в тому, як швидко можна перемотати назад без втрати легітимних записів після деплойменту.

Вони відновили вчорашній повний бекап на тестовому хості, програли бінлоги до п’яти хвилин перед деплоєм і експортували лише уражені таблиці назад у продакшн. Це було брудно, але контрольовано. Команда знала кроки, бо практикувала їх, коли ще не було пожежі.

Вони все одно написали постмортем і покращили рев’ю міграцій. Але справжня причина, чому це не стало багатоденним провалом — їхній процес бекапів був відрепетированим, документованим і нудним. В операціях нудність — це перевага.

Контрольні списки / покроковий план

Покроково: оберіть підхід до бекапів на VPS

1. Виміряйте розмір набору даних (datadir і логічний розмір). Якщо відновлення з SQL перевищить RTO — в пріоритеті фізичні бекапи.
2. Підтвердьте суміш двигунів. Якщо переважно InnoDB — підходять гарячі фізичні інструменти; якщо значний MyISAM — плануйте блокування або міграцію.
3. Визначте RPO. Якщо потрібна втрата даних <24h — увімкніть і зберігайте бінлоги поза хостом.
4. Виберіть основний повний бекап:
   • Мала БД: mysqldump + binlogs підходять.
   • Середня/велика БД: mariabackup/xtrabackup + binlogs.
5. Виберіть механізм захоплення:
   • Інструментований гарячий бекап (рекомендовано для InnoDB).
   • Знімок + координація (тільки якщо вмієте це робити правильно).
6. Виберіть зберігання поза хостом. Інша домен відмови. Шифруйте, якщо потрібно.
7. Напишіть ранбук відновлення з командами, очікуваними таймінгами і перевірочними запитами.
8. Плануйте відпрацювання відновлення мінімум щоквартально. Якщо БД критична — щомісяця.

Операційний чекліст: що має робити кожна задача бекапу

• Записувати метадані бекапу (версія сервера, binlog файл/позиція або GTID set, час, версія інструмента).
• Перевіряти цілісність файлів (контрольна сума) після передачі.
• Повідомляти про помилки і про незвичну тривалість/зміни розміру.
• Тримати ретенцію згідно часу виявлення (скільки часу ви помічаєте корупцію або випадкове видалення).
• Доводити життєздатність відновлення через періодичні вправи.

Чекліст валідації відновлення (мінімум)

• Сервер стартує чисто; InnoDB recovery завершується.
• Кількість рядків співпадає для ключових таблиць (приблизна перевірка як перша стадія).
• Критичні індекси існують; стан міграцій коректний.
• Додаток може аутентифікуватися і виконати топ-3 робочих сценаріїв.
• Реплікація (якщо використовується) може бути відновлена зі стану бекапу.

Питання та відповіді

1) Чи підходить mysqldump для продакшну?

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

2) Який один найважливіший прапор mysqldump для InnoDB?

--single-transaction. Він дає консистентний знімок без блокування таблиць (для InnoDB). Він не вирішує консистентність MyISAM і все ще може навантажувати undo/redo, якщо транзакції довгі.

3) Чи можна бекапити, копіюючи /var/lib/mysql, поки MySQL працює?

Не безпечно, якщо тільки ви не використовуєте координований метод знімків, що гарантує консистентність, або не зупиняєте MySQL. Живий rsync datadir — класичний шлях до бекапів, які відновлюються в сумнівах.

4) Чи слід компресувати бекапи на VPS?

Іноді. Стиснення обмінює CPU на I/O і мережу. На малих VPS використовуйте низькі рівні стиснення і вимірюйте. Якщо CPU-конкуренція викликає сплески затримки — компресуйте поза хостом або менше стискайте.

5) Чи замінюють фізичні бекапи бінлоги?

Ні. Фізичні бекапи дають швидку точку повного відновлення. Бінлоги дають точкове відновлення між повними бекапами. Якщо вам потрібен низький RPO — потрібні обидва.

6) Чи портативні фізичні бекапи між MySQL і MariaDB?

Загалом ні. Фізичні бекапи прив’язані до форматів на диску і версій. Логічні дампи — портативний варіант для крос‑движкових переходів, хоч і повільніший.

7) Чи варто робити бекапи з репліки?

Так, якщо можете. Це зменшує навантаження на primary і дає безпечніше місце для важких читань. Але слідкуйте за відставанням реплікації: запізніла репліка може тихо порушити ваш RPO.

8) Як часто тестувати відновлення?

Щонайменше щоквартально для «важливих» БД, щомісяця для критично бізнес-важливих, а також після мажорних оновлень або змін інструментів бекапу. Тестування відновлення — це те, що перетворює файли бекапу на здатність відновлювати.

9) Який найшвидший метод відновлення на VPS?

Фізичне відновлення (підготовлений бекап + copy-back) зазвичай найшвидше для наборів, орієнтованих на InnoDB. Справжній ліміт — пропускна здатність диска під час відновлення, а не краса інструмента.

10) Як зрозуміти, чи вузьке місце — CPU, диск чи блокування?

Диск: високий iowait/await/%util у iostat. CPU: процеси бекапу/стиснення завантажують ядра у top. Блокування: очікування метаданих у SHOW PROCESSLIST.

Наступні кроки: що зробити цього тижня

• Визначте RTO/RPO письмово. Якщо ви не можете їх визначити — ви не зможете раціонально вибрати між дампом і фізичними бекапами.
• Увімкніть бінлоги (якщо потрібен PITR) і сплануйте ретенцію поза хостом.
• Запустіть Завдання 2 і Завдання 6 на вашому VPS під час вікна бекапу. Якщо ви насичуєте I/O — припиніть гадати і тротліть або перемістіть бекапи з основного диска.
• Якщо MariaDB і набір середній/великий: реалізуйте mariabackup + prepare + копію поза хост, з метаданими, що фіксують координати binlog.
• Якщо залишаєтеся на mysqldump: стандартизируйте прапори, захоплюйте координати binlog і виконайте одне повне відновлення на чисту VM.
• Заплануйте тест відновлення і зробіть це чієюсь рутинною відповідальністю, а не героїчним актом.

Бекапи — це не про сам бекап. Вони про відновлення. Побудуйте відновлення, яке ви хочете, а потім робіть бекапи так, щоб це відновлення було нудним.