Які бувають типи бекапів MySQL і як обрати стратегію резервного копіювання?

Логічний бекап - дані у вигляді SQL чи CSV (mysqldump, утиліти MySQL Shell):

• переносимий між версіями й платформами, можна відновити окрему таблицю, легко переглянути;
• повільне відновлення - SQL виконується заново, індекси перебудовуються;
• для бази на сотні гігабайтів відновлення займає години.

Фізичний бекап - копія файлів даних (Percona XtraBackup, MySQL Enterprise Backup, знімки диска):

• швидке відновлення - файли просто повертаються на місце;
• прив'язаний до версії MySQL і конфігурації;
• копія займає стільки ж, скільки дані, включно з фрагментацією.

Гарячий, теплий, холодний:

• гарячий - база працює, читання й запис дозволені (mysqldump --single-transaction для InnoDB, XtraBackup);
• теплий - читати можна, писати ні (дамп з блокуванням таблиць);
• холодний - сервер зупинено, копіюються файли. Найпростіший, але з простоєм.

Повний та інкрементний: інкрементний містить лише зміни з попереднього бекапу. У MySQL роль інкрементних бекапів часто виконують бінарні журнали: повний бекап раз на добу + безперервне копіювання журналів = відновлення на будь-яку секунду.

Знімки файлової системи (LVM, ZFS, хмарні диски) - миттєвий фізичний бекап. Щоб знімок був узгодженим, InnoDB має бути готовий: знімок робиться при FLUSH TABLES WITH READ LOCK або покладається на відновлення після збою (InnoDB відновиться, як після раптового вимкнення).

Як обрати стратегію - від вимог, а не від інструментів:

• RPO (recovery point objective) - скільки даних можна втратити. «Нічого» - потрібні бінарні журнали, що безперервно копіюються за межі сервера;
• RTO (recovery time objective) - скільки триває відновлення. «15 хвилин» для бази на 500 ГБ - фізичний бекап чи готова репліка, але не mysqldump.

Типова схема для середнього проєкту:

• щоденний фізичний чи логічний бекап (знятий з репліки, щоб не навантажувати джерело);
• бінарні журнали, що копіюються в об'єктне сховище;
• зберігання поза основною інфраструктурою (інший регіон, інший обліковий запис хмари), з шифруванням;
• кілька поколінь: щоденні за тиждень, щотижневі за місяць, щомісячні за рік.

Репліка - не бекап. Випадковий DROP TABLE миттєво реплікується на всі репліки. Від помилок людей захищають бекапи й відкладені репліки.

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

Докладніше в документації: Типи бекапів