12 errori comuni durante il backup dei database

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

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

Le macchine virtuali possono utilizzare i meccanismi di snapshot e Changed Block Tracking, ma è necessario sincronizzare le copie di backup create per ottenere una copia di backup coerente del database, perché la copia di backup risulterà incoerente in caso di operazioni di scrittura attive sul database al momento dell’ordinamento della raccolta dei blocchi modificati.

Per coloro che desiderano eseguire il backup dei propri database con l’aiuto di strumenti di backup di file o macchine virtuali, possiamo offrire due metodi:

1. spegnere completamente i servizi e i processi del DBMS in modo che non ci sia nulla nella cache,
2. utilizzare agenti e/o script che commutano il database in una modalità speciale che rende sicura la copia sequenziale del file di database. Ad esempio, esiste un meccanismo chiamato VSS writer per i database MSSQL. Su richiesta, commuta il database in modalità compatibile con gli snapshot nel momento in cui viene creato uno snapshot. Se si utilizzano meccanismi basati su Changed Block Tracking, è necessario assicurarsi personalmente che il database sia coerente al momento della sincronizzazione.

Se non si commuta il database in modalità compatibile con il backup, la copia del database risultante apparirà come se si fosse verificato un hard reset (ad esempio, un’interruzione di corrente) sul computer host. Questo livello di affidabilità è assolutamente insufficiente per la maggior parte delle aziende. Puoi saperne di più in questo articolo “Peculiarità del lavoro con i database su macchine virtuali”.

Per Firebird, è necessario bloccare il file principale del database con l’aiuto di nbackup prima dell’avvio del processo di backup e sbloccarlo al termine del processo. Per altri DBMS esistono strumenti simili per attivare/disattivare le modalità corrispondenti.

Alcuni amministratori di database sono sicuri di poter eseguire il backup dei propri database in modo sicuro con gli strumenti standard di backup dei file se il DBMS dispone di un log delle transazioni, perché al massimo verrà corrotto solo questo log. È una pericolosa convinzione errata che gli sviluppatori di DBMS non supportano.

Le radici di questa convinzione errata sono chiare: la pubblicità aggressiva degli sviluppatori di macchine virtuali e strumenti di backup di solito non menziona che i database, così come altri file aggiornati intensivamente, richiedono una configurazione avanzata. Non credere al clamore pubblicitario: non tutti gli yogurt hanno gli stessi benefici.

Raccomandazioni: non utilizzare strumenti di backup di file e VM senza i corrispondenti strumenti di automazione per i database.

Raccomandazione per Firebird: utilizzare FBDataGuard (dal pacchetto di distribuzione HQbird), che fornisce integrazione con strumenti di backup compatibili con VSS.

12. Sostituire il backup con la replica

Il backup dei dati e la replica dei dati vengono utilizzati per aumentare l’affidabilità e prevenire la perdita di dati, ma sono comunque piuttosto diversi.

Tutti amano la replica per la capacità di sincronizzare i dati su un altro server con il minimo ritardo, ma il backup ha anche alcuni vantaggi indiscutibili. Ad esempio, in caso di cancellazione accidentale (o intenzionale) dei dati, la replica invierà rapidamente e imperturbabilmente le modifiche alla replica, mentre il backup (soprattutto con copie su supporti di sola lettura) è immune a tali operazioni. È necessario un certo sforzo per configurare correttamente sia la replica che il backup, e comunque esiste sempre la possibilità di errori.

Raccomandazioni: se hai configurato la replica, non trascurare le copie di backup, usa entrambe.

Raccomandazione per Firebird: utilizzare il pacchetto di distribuzione HQbird Enterprise, che include sia strumenti di backup che di replica.

Riepilogo

Non è così facile configurare il backup per il tuo DBMS preferito, quindi di solito gli amministratori di database di organizzazioni che tengono ai propri dati utilizzano strumenti di backup professionali che consentono di tenere conto dei problemi sopra menzionati e prevenire i problemi.

Per Firebird (scusa per la pubblicità) esiste un pacchetto chiamato HQbird che include FBDataGuard.

Inoltre, la nostra azienda fornisce supporto completo per backup e manutenzione per Firebird e altri database; questa è una buona scelta per coloro che non conoscono tutti i dettagli tecnici dei backup.

E, naturalmente, continua a coltivare la tua paranoia da amministratore: ad esempio, alzati e controlla le tue copie di backup proprio ora :)

Contatti

Non esitare a porre qualsiasi domanda: [email protected]

Vuoi ricevere notizie e articoli su Firebird? Unisciti a noi su Telegram https://t.me/firebirdsql