Типи бекапів у PostgreSQL: повні, інкрементальні, диференціальні

Отже, уяви, що твоя база даних — це величезний бібліотечний архів із тисячами книжок. Повний бекап — це кожної ночі відправляти кур’єра, щоб він копіював усі книжки. А якщо майже нічого не змінилося? Це не тільки повільно, а й сильно навантажує транспорт і забирає багато місця. Ось тут і з’являються інкрементальні та диференціальні підходи. Ми працюємо розумніше, а не більше, копіюючи лише те, що реально змінилося.

Сьогодні розберемо такі типи бекапів:

• Повний бекап: повне копіювання бази даних.
• Інкрементальний бекап: копіювання лише змін із моменту останнього бекапу.
• Диференціальний бекап: копіювання змін із моменту останнього повного бекапу.

Кожен із цих підходів має свої плюси, мінуси й області застосування. Давай розбиратися.

Повний бекап

Повний бекап (або Full Backup) — це резервна копія всієї бази даних на певний момент часу. Він містить як структуру бази (таблиці, індекси, схеми), так і всі наявні дані. Простіше кажучи, це "моментальний знімок" усієї бази.

Приклад команди для повного бекапу:

pg_dump -U username -d database_name -F c -f full_backup.dump

Тут:

• -U username — ім’я користувача PostgreSQL.
• -d database_name — ім’я бази даних.
• -F c — формат бекапу (custom, зручно для відновлення через pg_restore).
• -f full_backup.dump — ім’я файлу, куди зберігається резервна копія.

Детальніше про команду pg_dump і її параметри ти дізнаєшся в наступних лекціях :P

Переваги повного бекапу:

1. Простота відновлення. якщо щось пішло не так, повний бекап допоможе швидко відновити базу повністю.
2. Повний знімок даних. можна використовувати для перенесення всієї бази на інший сервер або середовище.

Недоліки повного бекапу:

1. Обсяг даних: повний бекап може бути дуже великим, особливо якщо у тебе багато даних.
2. Тривале виконання: чим більше даних, тим більше часу потрібно для створення копії.
3. Місце зберігання: кожен повний бекап займає окреме місце, що може з’їдати ресурси сховища.

Використовувати повний бекап можна:

• Під час створення першої резервної копії.
• Перед виконанням великих змін у базі даних.
• Для довгострокового архіву (зробили повний бекап і відправили його в "холодне" сховище).

Інкрементальні бекапи

Інкрементальний бекап (Incremental Backup) зберігає лише ті файли, які змінилися з моменту останнього бекапу — будь то повний чи інкрементальний. Це дозволяє суттєво зекономити дисковий простір і прискорити процес резервного копіювання.

У PostgreSQL інкрементальні бекапи можна реалізувати через інструмент pgBackRest — це потужна утиліта, призначена для створення й керування резервними копіями PostgreSQL із підтримкою повної, інкрементальної та диференціальної стратегії.

Як працює pgBackRest?

• pgBackRest використовує метадані й контрольні суми файлів для визначення змін.
• Тільки файли, які реально змінилися, включаються в інкрементальний бекап.
• Підтримується автоматичне архівування WAL-файлів, що дозволяє виконувати відновлення до потрібної точки часу.

Приклад команди для інкрементального бекапу:

pgbackrest --stanza=main --type=incr backup

Де:

• --stanza=main — ім’я конфігурації (набір параметрів для конкретної БД).
• --type=incr — вказує, що виконується інкрементальний бекап.

Перед першим інкрементальним бекапом обов’язково має бути виконаний повний (--type=full).

Переваги інкрементальних бекапів із pgBackRest:

1. Економія місця: копіюються лише змінені файли.
2. Швидке виконання: особливо при невеликій кількості змін.
3. Автоматичне керування WAL: pgBackRest сам архівує й застосовує WAL-файли.
4. Гнучкість відновлення: можна обрати точку відновлення (PITR).

Недоліки й нюанси:

1. Потрібна початкова настройка: треба сконфігурувати stanza, каталог репозиторію, права доступу.
2. Складність для новачків: вимагає розуміння WAL і архітектури PostgreSQL.
3. Залежність від репозиторію: усі бекапи зберігаються централізовано — важливо керувати сховищем.

Коли використовувати інкрементальні бекапи:

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

Диференціальні бекапи

Диференціальний бекап (Differential Backup) зберігає всі зміни, які відбулися з моменту останнього повного бекапу. Відмінність від інкрементального бекапу в тому, що кожен диференціальний бекап містить повний набір змін, починаючи з останнього повного бекапу. Тобто для відновлення бази потрібен лише останній повний бекап і останній диференціальний бекап.

Приклад процесу:

1. Перший вечір: створюється повний бекап (A).
2. Другий вечір (B): створюється диференціальний бекап — містить зміни з моменту A.
3. Третій вечір (C): створюється диференціальний бекап — також містить зміни з моменту A.

Переваги:

1. Простота відновлення: Для відновлення бази потрібен лише повний бекап і останній диференціальний бекап.
2. Швидше, ніж повний бекап: Диференціальний бекап виконується швидше, ніж повний, бо копіюються лише зміни.

Недоліки:

1. Розмір файлу бекапу: З кожним новим диференціальним бекапом його розмір збільшується, бо в нього записуються всі зміни з моменту повного бекапу.
2. Місце на диску: У довгостроковій перспективі може знадобитися більше місця, ніж для інкрементальних бекапів.

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

Порівняння типів бекапів

Вибір типу бекапу залежить від твоїх вимог до безпеки даних, частоти оновлень і доступних ресурсів. Для невеликих баз підходить регулярний повний бекап. Якщо база росте, інкрементальні бекапи допоможуть зекономити місце. А якщо тобі важливо швидко відновити дані, диференціальні бекапи можуть стати оптимальним вибором. Головне — не забувай про регулярність і налаштування автоматизації!