Что делать при повреждении резервной копии

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

Так вы заранее узнаете о повреждении файла.

Примеры восстановления из повреждённых копий

Давайте рассмотрим пару реальных кейсов.

Кейc 1. Ошибка переноса файла

Вы переносите резервную копию с помощью FTP, но вдруг заметили, что файл оказался меньше ожидаемого объёма. Вы использовали pg_dump в текстовом формате, поэтому:

1. Открыли файл в редакторе.
2. Удалили повреждённую часть данных.
3. Выполнили восстановление рабочей части файла через psql.

Кейc 2. Частичная утрата данных в WAL

Ваш сервер использовал инкрементальные бэкапы и архивные WAL-файлы. Внезапно часть файлов исчезла. Однако вы смогли восстановить данные с помощью pg_basebackup и сохранившихся WAL-файлов, указав их путь в настройках восстановления.

Помните, что резервное копирование — это не только создание копий, но и их проверка. Не ждите конца света, чтобы понять, что ваши бэкапы бесполезны. А если копия всё же повредилась, не паникуйте: PostgreSQL предоставляет множество способов вернуть ваши данные обратно. Главное — действовать быстро и аккуратно!

Ну, а если ничего не помогло — перечитайте первый пункт этой лекции.

2

Задача

SQL SELF, 44 уровень, 4 лекция

Недоступна

Восстановление базы данных с игнорированием ошибок

Восстановление базы данных с игнорированием ошибок

Открыть

1

Опрос

Настройка автоматизации бэкапов, 44 уровень, 4 лекция

Недоступен

Настройка автоматизации бэкапов

Настройка автоматизации бэкапов

Открыть