Що робити при пошкодженні резервної копії

Sheet happens. У минулій лекції ми також розібрали покроковий процес повного відновлення бази даних після збою. Але реальність любить підкидати сюрпризи. Що робити, якщо твоя резервна копія виявилась пошкодженою? Ось і настав час розібратись із цим.

Де краще розмістити резюме?

Жарт. Зараз будемо розглядати технічні питання. Але не забувай, що в кожному жарті лише частка жарту :)

Аналіз пошкодження резервної копії

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

• Помилки при спробі відновлення: при виконанні pg_restore ти можеш побачити помилки типу:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Частина даних відсутня або файл має некоректний розмір (наприклад, раптово маленький або дорівнює нулю).
• Розпакований файл SQL містить обрив даних, некоректні символи або порожні секції.

Пошкодження бекапів може статись з купи причин:

• Переривання процесу резервного копіювання (наприклад, вимкнення живлення або завершення роботи системи).
• Неправильна передача файлу (помилки при копіюванні на флешку або по мережі).
• Залізні збої (диски, RAM, збій у RAID-масиві).
• Помилки в налаштуванні системи або утиліти для створення резервних копій.
• Віруси, шкідливі програми і, звісно, спонтанний "клік не туди".

Відновлення даних із пошкодженої копії

Якщо файл пошкоджений, це ще не кінець. Іноді відновити щось все ж можна. Давай розглянемо кілька підходів.

Спроба відновлення за допомогою pg_restore

Якщо файл був створений через pg_dump у форматі custom або directory, спробуй виконати відновлення командою pg_restore із прапорцем --ignore-errors. Приклад команди:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Цей прапорець каже утиліті ігнорувати помилки при відновленні і йти далі. Звісно, дані в місцях пошкоджень будуть втрачені, але хоча б частину інформації можна буде повернути.

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

Використання часткових даних

Припустимо, у тебе є резервна копія у текстовому форматі SQL. Спробуй відкрити її текстовим редактором (краще чимось просунутим, наприклад, Visual Studio Code або Notepad++), щоб оцінити, де вона обривається. Якщо файл читається і більшість SQL-запитів цілі:

1. Видали пошкоджену частину файлу.
2. Виконай решту SQL-запитів вручну або через команду psql:

psql -U username -d database_name -f partial_backup.sql

Читання файлу custom-формату

Якщо твоя резервна копія у custom-форматі, можна спробувати витягти її вміст по частинах:

pg_restore --list backup_file.dump > file_list.txt

Ця команда створить список усіх об'єктів у бекапі. Потім ти можеш спробувати відновити окремі елементи (наприклад, таблиці чи схеми) наступною командою:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

Редагуючи file_list.txt, можна виключити пошкоджені елементи з відновлення.

Спроба відновлення через архівні логи (WAL)

Якщо ти використовуєш інкрементальні або диференціальні бекапи (наприклад, через pg_basebackup), у тебе, скоріш за все, є архівні логи (WAL-файли). Вони зберігають усі зміни, що відбулись з моменту попереднього бекапу. Щоб відновити дані, ти можеш:

1. Знайти останню цілу резервну копію (наприклад, повний бекап).
2. Вказати PostgreSQL, де лежать WAL-файли:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Виконати відновлення.

Використання сторонніх інструментів

Іноді пошкодження резервних копій можна мінімізувати за допомогою утиліт для відновлення файлів. Популярний інструмент — ddrescue. Приклад команди:

ddrescue --force backup_file.dump recovered_dump.file

Цей інструмент спробує відновити якомога більше даних і створити нову копію файлу.

Запобігання пошкодженням резервних копій

Так, працювати з пошкодженими файлами — це стрес. Давай подумаємо, як уникнути таких ситуацій.

Зберігання копій у кількох місцях

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

• На локальному сервері.
• У хмарі (Amazon S3, Google Cloud Storage або навіть через простий сервіс типу Dropbox).
• На зовнішніх носіях (якщо хочеш бути супер-захищеним).

Регулярна перевірка цілісності резервних копій

Є приказка у світі ІТ: "Бекап, який не тестувався, — це не бекап". Регулярно перевіряй свої резервні копії, виконуючи тестове відновлення даних. Для цього:

1. Завантажуй бекап на тестовий сервер.
2. Відновлюй із нього дані.
3. Перевіряй їхню коректність.

Використання контрольних сум

При створенні резервних копій генеруй контрольні суми файлів (наприклад, через алгоритми MD5 або SHA256):

md5sum backup_file.dump > backup_file.md5

При відновленні даних порівнюй поточну контрольну суму з оригінальною:

md5sum -c backup_file.md5

Так ти заздалегідь дізнаєшся про пошкодження файлу.

Приклади відновлення з пошкоджених копій

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

Кейс 1. Помилка перенесення файлу

Ти переносиш резервну копію через FTP, але раптом помічаєш, що файл виявився меншим за очікуваний обсяг. Ти використовував pg_dump у текстовому форматі, тому:

1. Відкрив файл у редакторі.
2. Видалив пошкоджену частину даних.
3. Виконав відновлення робочої частини файлу через psql.

Кейс 2. Часткова втрата даних у WAL

Твій сервер використовував інкрементальні бекапи і архівні WAL-файли. Раптово частина файлів зникла. Але ти зміг відновити дані за допомогою pg_basebackup і збережених WAL-файлів, вказавши їхній шлях у налаштуваннях відновлення.

Пам'ятай, що резервне копіювання — це не тільки створення копій, а й їх перевірка. Не чекай кінця світу, щоб зрозуміти, що твої бекапи марні. А якщо копія все ж пошкодилась, не панікуй: PostgreSQL дає купу способів повернути твої дані назад. Головне — діяти швидко і акуратно!

Ну, а якщо нічого не допомогло — перечитай перший пункт цієї лекції.