12 erreurs courantes lors de la sauvegarde de bases de données

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

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

Les machines virtuelles peuvent utiliser les mécanismes de snapshots et de suivi des blocs modifiés (Changed Block Tracking), mais il est nécessaire de synchroniser les copies de sauvegarde créées afin d’obtenir une copie de sauvegarde cohérente de la base de données, car la copie de sauvegarde sera incohérente en cas d’opérations d’écriture actives avec la base de données au moment du tri de la collection des blocs modifiés.

Pour ceux qui souhaitent sauvegarder leurs bases de données à l’aide d’outils de sauvegarde de fichiers ou de machines virtuelles, nous pouvons proposer deux méthodes :

1. arrêter complètement les services et processus du SGBD afin qu’il n’y ait rien dans le cache,
2. utiliser des agents et/ou des scripts qui basculent la base de données dans un mode spécial qui rend la copie séquentielle du fichier de base de données sûre. Par exemple, il existe un mécanisme appelé VSS writer pour les bases de données MSSQL. Sur demande, il bascule la base de données en mode compatible snapshot au moment où un snapshot est effectué. Si vous utilisez des mécanismes basés sur le suivi des blocs modifiés, vous devez vous-même vous assurer que la base de données est cohérente au moment de la synchronisation.

Si vous ne basculez pas la base de données en mode compatible sauvegarde, la copie de base de données résultante ressemblera à une réinitialisation matérielle (par exemple, une coupure de courant) sur l’ordinateur hôte. Ce niveau de fiabilité est absolument insuffisant pour la plupart des entreprises. Vous pouvez en apprendre davantage à ce sujet dans l’article « Particularités du travail avec les bases de données sur les machines virtuelles ».

Pour Firebird, il est nécessaire de verrouiller le fichier principal de la base de données à l’aide de nbackup avant le début du processus de sauvegarde et de le déverrouiller après la fin du processus. Pour les autres SGBD, il existe des outils similaires pour activer/désactiver les modes correspondants.

Certains administrateurs de bases de données sont convaincus qu’ils peuvent sauvegarder leurs bases de données en toute sécurité à l’aide d’outils de sauvegarde de fichiers standard si le SGBD dispose d’un journal de transactions, car au pire, seul ce journal sera corrompu. C’est une idée fausse et dangereuse que les développeurs de SGBD ne soutiennent pas.

Les racines de cette idée fausse sont claires : la publicité agressive des développeurs de machines virtuelles et d’outils de sauvegarde omet généralement de mentionner que les bases de données, ainsi que d’autres fichiers intensivement mis à jour, nécessitent une configuration avancée. Ne croyez pas le battage médiatique - tous les yaourts ne se valent pas.

Recommandations : n’utilisez pas d’outils de sauvegarde de fichiers et de machines virtuelles sans les outils d’automatisation correspondants pour les bases de données.

Recommandation pour Firebird : utilisez FBDataGuard (du package de distribution HQbird), il fournit une intégration avec les outils de sauvegarde compatibles VSS.

12. Remplacer la sauvegarde par la réplication

La sauvegarde des données et la réplication des données sont utilisées pour augmenter la fiabilité et prévenir la perte de données, mais elles sont néanmoins assez différentes.

Tout le monde aime la réplication pour la capacité de synchroniser les données sur un autre serveur avec un délai minimal, mais la sauvegarde présente également des avantages incontestables. Par exemple, en cas de suppression accidentelle (ou intentionnelle) de données, la réplication enverra rapidement et imperturbablement les modifications à la réplique, tandis que la sauvegarde (surtout avec des copies sur des supports en lecture seule) est immunisée contre de telles opérations. Il faut un certain effort pour configurer correctement à la fois la réplication et la sauvegarde, et la possibilité d’erreurs existe de toute façon.

Recommandations : Si vous avez configuré la réplication, ne négligez pas les copies de sauvegarde, utilisez les deux.

Recommandation pour Firebird : utilisez le package de distribution HQbird Enterprise, il comprend à la fois des outils de sauvegarde et de réplication.

Résumé

Il n’est pas si facile de configurer la sauvegarde pour votre SGBD préféré, c’est pourquoi les administrateurs de bases de données des organisations qui accordent de la valeur à leurs données utilisent généralement des outils de sauvegarde professionnels qui leur permettent de prendre en compte les problèmes mentionnés ci-dessus et de prévenir les problèmes.

Pour Firebird (pardonnez la publicité), il existe un package appelé HQbird qui comprend FBDataGuard.

De plus, notre entreprise fournit un support complet de sauvegarde et de maintenance pour Firebird et d’autres bases de données, c’est un bon choix pour ceux qui ne connaissent pas tous les détails techniques des sauvegardes.

Et, bien sûr, continuez à chérir votre paranoïa d’administrateur, par exemple, levez-vous et vérifiez vos copies de sauvegarde dès maintenant :)

Contacts

N’hésitez pas à poser vos questions : [email protected]

Vous voulez recevoir des nouvelles et des articles sur Firebird ? Rejoignez-nous sur Telegram https://t.me/firebirdsql