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. Отсутствие контроля над успешным завершением процесса резервного копирования

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

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

! в сочетании с Проблемой 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. Резервное копирование базы данных с помощью инструментов файлового резервного копирования или инструментов резервного копирования виртуальных машин при работающем сервере базы данных

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

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

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

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