Відновлення даних після збою

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

Давай почнемо розбирати процес відновлення по кроках, як би ми збирали IKEA-шкаф: без паніки і строго по інструкції.

Крок 1. Аналіз причини збою

Перш ніж мчати на всіх парах відновлювати дані, важливо зрозуміти, що саме сталося.

1. Помилка додатку чи бази даних?
   Перевір логи свого додатку і PostgreSQL (зазвичай їх можна знайти в /var/log/postgresql/ або аналогічній директорії в залежності від твоєї ОС). Знайди індикатори помилок.

2. Апаратна несправність?
   Якщо сервер фізично пошкоджений (наприклад, проблеми з жорстким диском), то спочатку переконайся, що обладнання справне. Якщо твій диск пошкоджений, підключи інший і віднови все з нього.

3. Проблеми з мережею чи доступом?
   Якщо збій викликаний мережею — твій сервер, скоріш за все, поки не потребує відновлювальних операцій.

4. Людський фактор:
   Зізнайся... хтось виконав DROP DATABASE? Якщо так, у нас ще є шанс відновити дані з резервної копії.

Пам’ятай, що точне розуміння причин збою допоможе уникнути його в майбутньому.

Крок 2. Перевірка доступності резервних копій

Настав час переконатися, що у нас є правильний бекап. Знайди останні резервні копії бази даних, які ти створював за допомогою pg_dump або pg_basebackup. Перевір їх цілісність. Якщо ти ще не знаєш, як це зробити, ось коротке нагадування:

• Використовуй команду ls -l для перевірки розміру твоїх файлів. Якщо файл підозріло маленький, це може бути ознакою проблеми.
• Перевір файл за допомогою команди file. Наприклад:

  file backup_file.sql
  

  Ти повинен побачити інформацію про файл, яка вказує, що це SQL-дамп.

Для архіву tar перевір його на можливість розпакування:

tar -tf backup.tar

Жодних помилок? Круто! Можемо рухатись далі.

Крок 3. Зупинка PostgreSQL

Перед початком відновлення важливо зупинити сервер PostgreSQL, щоб убезпечити процес. Зробити це можна за допомогою наступної команди (під адміном сервера):

sudo systemctl stop postgresql

Зупинка бази даних гарантує, що жодні процеси не заважають відновленню.

Крок 4. Підготовка нової бази даних для відновлення

Якщо твоя база даних була повністю видалена або пошкоджена, спочатку створи її заново. Приклад команди:

createdb -U postgres new_database

Заміні new_database на ім’я своєї бази.

Крок 5. Відновлення резервної копії

Розглянемо два основних сценарії відновлення:

1. Якщо ти використовуєш бекап SQL (pg_dump): Для відновлення використовуй команду

   psql -U username -d new_database -f backup_file.sql
   

• username — твій користувач PostgreSQL.
• new_database — база даних, куди будуть імпортовані дані.
• backup_file.sql — твій файл резервної копії.

2. Якщо ти використовуєш бінарний бекап (pg_basebackup або pg_dump з custom):
   Для відновлення використовуй:
   

   pg_restore -U username -d new_database backup_file.dump
   

   Зверни увагу, що ці бекапи не в текстовому форматі, а містять "упаковані" дані.

Додатково:

• Якщо в бекапі тільки дані, використовуй --data-only.
• Якщо треба відновити тільки структуру, додай --schema-only.

Крок 6. Запуск PostgreSQL і тестування

Після виконання команди відновлення запусти сервер:

sudo systemctl start postgresql

Тепер треба провести тести. Спробуй підключитися до відновленої бази даних через psql або pgAdmin. Виконай кілька вибірок, щоб перевірити коректність даних:

SELECT * FROM your_table_name LIMIT 10;

Якщо все виглядає нормально, вітаю: дані відновлені!

Крок 7. Перевірка цілісності даних

Після відновлення важливо перевірити, що дані цілісні. Наприклад:

1. Порівняй кількість рядків у таблицях з бекапами:

   SELECT COUNT(*) FROM your_table_name;
   

   Порівняй результат із записами в резервній копії (якщо є).

2. Використовуй контрольні суми: Якщо ти раніше створював контрольні суми для таблиць, зараз саме час звірити їх:

   md5sum backup_file.sql
   

3. Перевір зв’язки між таблицями: Переконайся, що відновлені зв’язки FOREIGN KEY працюють коректно.

Крок 8. Тестування додатку

Тепер перевір працездатність свого додатку, який використовує цю базу даних. Пройдися по основних сценаріях роботи. Є помилки? Все коректно відображається?

Приклади реальних помилок відновлення

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

1. Несумісність версій PostgreSQL.
   Уяви, що бекап був зроблений на версії 12, а сервер оновився до версії 15. При відновленні ти зустрінеш помилки.
   Рішення: використовуй ту ж версію PostgreSQL, що й для створення бекапу, або звернись до документації про сумісність: PostgreSQL Documentation.

2. Пошкоджений бекап . Якщо твій бекап був пошкоджений, частина даних може бути втрачена.
   Рішення: використовуй реплікацію бекапів (наприклад, зберігання кількох версій).

3. Помилка при відновленні конкретної таблиці.
   Якщо ти відновлюєш конкретну таблицю, але інші залежності (наприклад, зовнішні ключі) відсутні, процес може завершитися помилкою.
   Рішення: завжди відновлюй таблиці у правильному порядку, починаючи з батьківських.