12 распространенных ошибок при резервном копировании баз данных

автор: Алексей Ковязин, 11 ноября 2015 г.

Скачать PDF (англ.) Эта статья изначально предназначалась для разработчиков и администраторов СУБД Firebird, но общение с администраторами других баз данных показало, что большинство ошибок являются общими и для них, и буквально все спотыкаются об одни и те же грабли. Если вы можете что-то добавить к этому списку (даже что-то специфичное для конкретной СУБД), свяжитесь с нами по электронной почте [email protected].

1. Удаление предыдущей резервной копии до создания новой

Эта ошибка наиболее распространена среди новичков, которые не осознают, что основная цель резервной копии базы данных - не просто создать копию базы, а сделать время простоя информационной системы (важной частью которой является база данных) как можно короче.

В результате система остаётся незащищённой с момента удаления последней резервной копии до момента создания новой, потому что в этот период у базы данных нет ни одной резервной копии. Поскольку создание резервной копии может занять довольно много времени, это идеальный момент для действия закона Мёрфи. Этот подход особенно хорошо работает в сочетании с ошибкой №7 (см. ниже).

Рекомендации: не удаляйте предыдущую резервную копию до создания новой! (и не создавайте новую резервную копию в существующий файл).

Рекомендация для Firebird: инструмент FBDataGuard, входящий в состав HQbird (расширенного дистрибутива Firebird), удаляет самую раннюю резервную копию из истории только после создания новой.

2. Перезапись существующей базы данных при восстановлении из резервной копии

Эта ошибка менее распространена, хотя последствия могут быть гораздо хуже. Если резервная копия не была проверена и оказалась повреждённой (см. ошибку №6), у вас не будет ни предыдущей копии базы данных, ни действительной резервной копии.

Такой беспорядок обычно случается вечером в пятницу, когда всё идёт кувырком и указания руководства становятся довольно противоречивыми. Немного невезения - и вам обеспечен томный уикенд в серверной.

Firebird имеет своего рода защиту от этой ошибки - невозможно восстановить базу данных из резервной копии с помощью утилиты gbak, если используется ключ по умолчанию -create и указанное имя файла указывает на существующую базу данных. К сожалению, эту защиту можно обойти: ключ -rep всё же позволяет перезаписать существующий файл.

Рекомендация: никогда не перезаписывайте файл рабочей базы данных без письменного распоряжения руководства.

Рекомендация для Firebird: используйте FBDataGuard, потому что он никогда не перезаписывает файл базы данных.

3. Использование одношагового резервного копирования/восстановления без промежуточного файла резервной копии

Стандартные потоки ввода/вывода позволяют выполнить забавный трюк со многими СУБД (включая Firebird): реализовать потоковое резервное копирование с немедленным восстановлением базы данных из него. В результате промежуточный файл резервной копии не создаётся. Это удобно для регламентных работ и для выполнения тестового восстановления (при условии наличия другой резервной копии), но нельзя использовать это для автоматического резервного копирования!

Например, если во время этого процесса резервного копирования/восстановления произойдёт серьёзный сбой диска, исходная база данных может быть повреждена, а новая база данных ещё не создана. Конечно, если учесть ошибку №1 и существует копия базы данных с предыдущей попытки, будут потеряны только данные, созданные или обновлённые в базе после создания этой копии.

Рекомендации: не используйте одношаговое резервное копирование/восстановление в автоматическом режиме и всегда проверяйте наличие достаточно свежей копии в ручном режиме.

4. Хранение резервных копий и базы данных на одном физическом устройстве

Многим из вас может показаться забавным, что наши советы какие-то детские - азбука резервного копирования. Да, это так, но из-за популярности виртуальных сред база данных и диск могут оказаться в одной системе хранения данных. И она обязательно откажет в самый неподходящий момент. Плюс до сих пор есть люди, которые верят, что с их данными ничего не может случиться, если они используют RAID-массивы (версии 1 и выше :)). Кроме того, есть люди, которые верят, что некоторые «брендовые» серверы не отказывают, но это уже особый случай.

Рекомендации: не храните резервные копии и базу данных на одном устройстве, каким бы надёжным оно ни казалось.

5. Отсутствие контроля за успешным завершением процесса резервного копирования

Это довольно распространённая ошибка как среди администраторов, так и среди руководителей ИТ-отделов. Если вы не проверяете результаты процесса резервного копирования, можете вообще его не выполнять. Вы должны получать уведомления об успешно завершённом процессе резервного копирования по электронной почте или, что ещё лучше, также и по SMS. И отсутствие таких уведомлений - признак проблемы!

Внимательный читатель, дошедший до этого места в нашей статье (хотя пока рано вручать приз), может спросить: «А какое отношение это имеет к руководству?» Вот какое - администратор обычно настраивает процесс резервного копирования, но ему слишком скучно проверять уведомления, особенно если они хранятся в отдельной папке, поэтому никогда не лишним будет запросить дополнительные отчёты о состоянии процесса. Это касается вопроса о том, кто виноват, когда кажется, что резервные копии есть, а в нужный момент их на самом деле нет :)

! в сочетании с ошибкой №2 получаем ни базы данных, ни её резервной копии.

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

Рекомендация для Firebird: FBDataGuard проверяет, завершён ли процесс резервного копирования, и отправляет соответствующее уведомление. Для систем с большим количеством баз данных существует сводный мониторинг второго уровня с помощью инструмента Control Center, который позволяет видеть статусы всех контролируемых серверов и баз данных на одной странице.

6. Отсутствие проверки резервных копий

Тот факт, что резервные копии где-то хранятся, не означает, что их можно оттуда прочитать.

Поэтому необходимо регулярно проверять создаваемые резервные копии, чтобы убедиться, что они не повреждены и не скопированы в /dev/null.

Рекомендация для Firebird: можно автоматизировать проверку резервных копий с помощью FBDataGuard.

7. Отсутствие проверки целостности базы данных при использовании непроверенных резервных копий

Обычно в базах данных используется несколько типов резервного копирования - дампы, обычные резервные копии и т.д. Не вдаваясь в подробности, можно выделить две категории: проверенные и непроверенные. В случае Firebird это gbak и nbackup.

Gbak читает всю базу данных на уровне записей для создания файла резервной копии и создаёт базу данных путём вставки записей в новую базу, таким образом проверяя резервную копию (существуют способы, которыми ошибки могут проникнуть в восстановленную копию, но это уже другой способ для администратора базы данных навредить, связанный с плохо организованной миграцией) и саму базу данных (если её можно прочитать от начала до конца, она, скорее всего, не повреждена).

Nbackup (также известный как инкрементальное резервное копирование) временно блокирует основной файл базы данных для обновлений (в согласованном состоянии) и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).

В случае больших баз данных Firebird (более 500 ГБ) целесообразно использовать nbackup, чтобы не замедлять операции пользователей, но при этом необходимо проверять базу данных, потому что непроверенные резервные копии, которые он создаёт, являются копиями страниц базы данных, и если ошибка находится на уровне записей (из-за сбоя оперативной памяти) или на логическом уровне, непроверенная резервная копия будет содержать её так же, как и исходная база данных.

Чтобы избежать этого, используйте онлайн-проверку исходной базы данных (онлайн-проверка с помощью gfix доступна начиная с версии Firebird 2.5.4, а наш инструмент FBDataGuard поддерживает онлайн-проверку базы данных для версий 1.5-2.5).

Кроме того, рекомендуется время от времени выполнять проверенную резервную копию (например, раз в неделю) в дополнение к непроверенной.

Рекомендация для Firebird: помимо онлайн-проверки состояния, FBDataGuard позволяет тестировать процесс восстановления резервной копии в автоматическом режиме.

8. Отсутствие контроля за свободным местом для резервных копий

На самом деле это классическая ошибка: если места недостаточно, резервные копии занимают всё свободное пространство, и процесс завершается ошибкой. Хранение резервных копий на одном диске с базой данных может привести к прерыванию работы базы данных, а хранение их на системном диске - к сбою системы.

В сочетании с проблемой 4 лучший возможный исход - это когда система перестаёт функционировать, потому что базе данных также нужно свободное место, но оно занято резервными копиями. Что касается сочетания с проблемами 5 и 2, это снова оставляет нас без базы данных и без её резервной копии.

Рекомендации: используйте инструменты резервного копирования, которые прогнозируют размер резервной копии и предупреждают о возможной нехватке свободного места.

Рекомендация для Firebird: FBDataGuard контролирует размер свободного места для целей резервного копирования, а также размер свободного места на диске с базами данных и на системном диске.

9. Отсутствие контроля за временем создания резервной копии

Процесс резервного копирования занимал 40 минут буквально полгода назад, а теперь внезапно уже три часа - почему? Размер базы данных мог увеличиться, или диск мог выпасть из вашего RAID-массива, что привело к значительно более медленной записи, и все ваши резервные копии могут быть на грани гибели. Или ваш хороший коллега мог запустить ещё одну систему резервного копирования одновременно (кстати, Firebird позволяет запускать несколько процессов резервного копирования одновременно, хотя не совсем понятно, зачем это вообще может понадобиться). Если вы не контролируете время создания резервной копии, вы можете упустить новую возникшую проблему и потерять шанс исправить её до того, как она станет масштабной.

Кроме того, если система резервного копирования не отслеживает статусы задач резервного копирования и запускает их просто по расписанию, вы можете легко «выстрелить в молоко», что означает ситуацию, когда система запускает новый процесс резервного копирования, а предыдущий ещё не завершён.

Рекомендации: используйте инструменты, которые контролируют время выполнения процесса резервного копирования!

Рекомендация для Firebird: FBDataGuard контролирует время выполнения процесса резервного копирования.

10. Резервное копирование базы данных во время установки обновлений операционной системы

Это очень распространённая проблема, особенно в сочетании с проблемой 9 и включёнными автоматическими обновлениями Windows (по умолчанию обновления применяются в 3 часа ночи). В лучшем случае это приводит к замедлению работы, но если операционная система перезагружается для применения обновлений, резервная копия будет повреждена. По крайней мере, хорошая новость в том, что операционная система обновляется не каждый день.

Рекомендации: планируйте обновления операционной системы так, чтобы они не мешали процессу резервного копирования.

11. Резервное копирование базы данных с помощью инструментов файлового резервного копирования или резервного копирования виртуальных машин при работающем сервере базы данных

Многие администраторы забывают, что любая СУБД имеет активный и сложный кэш, содержащий данные, которые читаются и записываются, в то время как сами файлы базы данных открыты в режиме произвольного доступа. Поэтому необходимо использовать специальные типы резервного копирования вместо простого файлового копирования (включая простое копирование файлов базы данных) или резервного копирования виртуальных машин. Инструменты файлового резервного копирования читают базу данных последовательно, и это может занять довольно много времени, особенно в случае больших баз данных, поэтому невозможно гарантировать целостность создаваемой резервной копии.

Виртуальные машины могут использовать механизмы снимков и отслеживания изменённых блоков, но необходимо синхронизировать создаваемые резервные копии, чтобы получить согласованную резервную копию базы данных, потому что резервная копия будет несогласованной в случае любых активных операций записи в базу данных в момент сортировки набора изменённых блоков.

Для тех, кто хочет создавать резервные копии своих баз данных с помощью инструментов файлового резервного копирования или резервного копирования виртуальных машин, мы можем предложить два метода:

1. полностью остановить службы и процессы СУБД, чтобы в кэше ничего не осталось,
2. использовать агенты и/или скрипты, которые переводят базу данных в специальный режим, делающий безопасным последовательное копирование файла базы данных. Например, для баз данных MSSQL существует механизм под названием VSS writer. По запросу он переводит базу данных в режим, удобный для создания снимков, в момент создания снимка. Если вы используете механизмы на основе отслеживания изменённых блоков, вы сами должны убедиться, что база данных согласована в момент синхронизации.

Если вы не переведёте базу данных в режим, удобный для резервного копирования, полученная копия базы данных будет выглядеть так, как будто на хост-компьютере произошла жёсткая перезагрузка (например, отключение питания). Такой уровень надёжности абсолютно недостаточен для большинства предприятий. Подробнее об этом можно узнать в статье «Особенности работы с базами данных на виртуальных машинах».

Для Firebird необходимо заблокировать основной файл базы данных с помощью nbackup перед началом процесса резервного копирования и разблокировать его после завершения процесса. Для других СУБД существуют аналогичные инструменты для включения/выключения соответствующих режимов.

Некоторые администраторы баз данных уверены, что могут безопасно создавать резервные копии своих баз данных с помощью стандартных инструментов файлового резервного копирования, если у СУБД есть журнал транзакций, потому что в худшем случае будет повреждён только этот журнал. Это опасное заблуждение, которое разработчики СУБД не поддерживают.

Корни этого заблуждения ясны: агрессивная реклама разработчиков виртуальных машин и инструментов резервного копирования обычно умалчивает, что базы данных, как и другие интенсивно обновляемые файлы, требуют расширенной настройки. Не верьте рекламе - не все йогурты одинаково полезны.

Рекомендации: не используйте инструменты файлового резервного копирования и резервного копирования виртуальных машин без соответствующих инструментов автоматизации для баз данных.

Рекомендация для Firebird: используйте FBDataGuard (из дистрибутива HQbird), он обеспечивает интеграцию с инструментами резервного копирования, поддерживающими VSS.

12. Замена резервного копирования репликацией

Резервное копирование данных и репликация данных используются для повышения надёжности и предотвращения потери данных, но всё же это совершенно разные вещи.

Все любят репликацию за возможность синхронизировать данные на другом сервере с минимальной задержкой, но у резервного копирования также есть неоспоримые преимущества. Например, в случае случайного (или намеренного) удаления данных репликация быстро и невозмутимо отправит изменения на реплику, в то время как резервное копирование (особенно с копиями на носителях, доступных только для чтения) невосприимчиво к таким операциям. Настройка как репликации, так и резервного копирования требует определённых усилий, и тем не менее возможность ошибок всё равно существует.

Рекомендации: если у вас настроена репликация, не пренебрегайте резервными копиями, используйте и то, и другое.

Рекомендация для Firebird: используйте дистрибутив HQbird Enterprise, он включает как инструменты резервного копирования, так и репликации.

Итог

Настроить резервное копирование для вашей любимой СУБД не так просто, поэтому администраторы баз данных в организациях, где ценят свои данные, обычно используют профессиональные инструменты резервного копирования, которые позволяют учитывать упомянутые выше проблемы и предотвращать их.

Для Firebird (простите за рекламу) существует пакет под названием HQbird, который включает FBDataGuard.

Кроме того, наша компания предоставляет полную поддержку резервного копирования и обслуживания для Firebird и других баз данных - это хороший выбор для тех, кто не знаком со всеми техническими деталями резервного копирования.

И, конечно, продолжайте лелеять свою административную паранойю - например, прямо сейчас встаньте и проверьте свои резервные копии :)

Контакты

Не стесняйтесь задавать любые вопросы: [email protected]

Хотите получать новости и статьи о Firebird? Присоединяйтесь к нам в Telegram https://t.me/firebirdsql