Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.
Хотелось бы о них рассказать, чтобы администраторы и разработчики могли поменять свои подходы к управлению бэкапами и предупредить возможные проблемы.
Итак, приступим.
1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Чаще всего эту ошибку совершают новички, которые не понимают, что основная цель существования резервной копии БД – обеспечить минимальный простой информационной системы (важной частью которой является БД), а не просто создание копии БД.
В результате, с момента удаления последнего бэкапа до создания нового, система находится в незащищенном состоянии, потому что в этот период у базы данных нет ни одной резервной копии. Так как бэкап может создаваться достаточно долго, то это идеальное время для срабатывания закона Мерфи. Особенно хорошо этот подход работает в связке с пунктом 7 (см. ниже).
Рекомендация: не удаляйте предыдущий бэкап до того момента, как создан новый! (и не делайте новый бэкап в уже существующий файл)
2. Перезапись существующей базы данных при восстановлении из бэкапа
Эту ошибку совершают реже, но вот результаты могут быть гораздо печальнее. Если бэкап не проверялся и был поврежден (см. пункт 6), то в результате перезаписи у вас не будет ни предыдущей копии базы, ни валидного бэкапа.
Обычно это безобразие случается в пятницу вечером, в момент дерготни, неразберихи и противоречивых указаний со стороны начальства. Немного отрицательного везения и томные выходные в серверной обеспечены.
У Firebird есть некая защита от этой ошибки – создание рестора из бэкапа с помощью утилиты gbak с дефолтным ключом –create не сработает в случае, если указанное имя файла указывает на существующую БД. К сожалению, есть и обход этой защиты – переключатель –rep, который позволяет-таки переписать существующий файл.
Рекомендации: никогда не перезаписывайте файл боевой БД, не получив письменного указания руководства и, желательно, не получив предложения о новой работе.
3. Использование одношагового бэкапа-рестора, без создания промежуточного файла бэкапа
Стандартные потоки ввода-вывода позволяют провернуть с многими СУБД (с Firebird в том числе) интересный трюк: выполнять потоковый бэкап с немедленным восстановлением БД из него. В результате не создается промежуточный файл бэкапа. Это удобно для проведения регламентных работ и запуска проверочного восстановления (при наличии другой резервной копии), но ни в коем случае не надо использовать это для автоматического бэкапа!
Если в процессе такого бэкап-рестора произойдет серьёзный сбой диска, например, то может повредиться исходная база данных, а новая еще не будет создана. Конечно, если п.1 соблюдается, и есть копия БД от предыдущей попытки, то произойдет только потеря данных, которые были созданы или изменены в БД с момента создания ее копии.
Рекомендации: не используйте одношаговый бэкап-рестор в автоматическом режиме, а в ручном всегда проверяйте наличие достаточно свежей копии.
4. Хранение бэкапа и базы данных на одном и том же физическом устройстве
Тут многие могут посмеяться, что советы мы какие-то детские даем – это же азбука системного администрирования. Так-то оно так, но в связи с распространением виртуальных сред и БД, и диск могут находиться на одной СХД. А она обязательно сломается в самый неподходящий для бизнеса момент. Плюс, все еще существуют люди, которые верят в то, что если они используют RAID (от 1 и выше), то с их данными вообще ничего не может случиться. Еще есть люди, которые верят в сверхнадежность «брендового» железа, но это особый случай.
Рекомендации: не храните бэкап и БД на одном и том же физическом устройстве, каким бы надежным оно не казалась.
5. Отсутствие проверки успешного окончания бэкапа
Вот это довольно частая ошибка и администраторов, и руководителей ИТ подразделений. Если результат бэкапа не проверять, то можно бэкап не делать вообще — результат в общем тот же. Обязательно нужны нотификации по email об успешном бэкапе, а еще лучше и по СМС. Причем, отсутствие нотификации это признак проблемы!
А причем тут руководители, спросит внимательный читатель, дочитавший до этого места? А притом, что администратор обычно бэкап настроит, но вот нотификации ему проверять лень, тем более что лежат они у него в отдельной папочке, и поэтому руководителю ИТ-отдела надо периодически запрашивать дополнительный отчет о состоянии всех бэкапов. Это к вопросу, кого наказывать, если бэкапы вроде есть, но в нужный момент их не оказалось :)
! А при комбинировании с пунктом 2 получаем отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты автоматизации бэкапов, которые умеют отслеживать успешные и неуспешные бэкапы, сообщать пользователям о проблемах, и имеют обзорные средства контроля (особенно актуально, когда нужно контролировать десятки и сотни бэкапов на разных серверах).
6. Отсутствие валидации бэкапов
То, что бэкапы куда-то кладутся, не означает, что они оттуда могут быть прочитаны.
Поэтому обязательна периодическая верификация создаваемых бэкапов, чтобы быть уверенным, что создаваемые бэкапы не повреждены, не были скопированы в /dev/null
Рекомендации: никому не доверять, даже себе. Всех надо проверять.
7. Отсутствие health check базы данных при использовании неверифицированных бэкапов
Обычно СУБД имеют несколько видов бэкапа – дампы, просто бэкапы и т.д. Не вдаваясь в конкретику, можно выделить 2 категории – верифицированные и неверифицированные бэкапы. У Firebird это gbak и nbackup.
Gbak читает всю БД на уровне записей для создания файла бэкапа, и создает БД путем вставки записей в новую БД, и таким образом верифицирует и бэкап (есть варианты, как ошибки могут просочиться в отресторенную копию, но это уже другой вид факапа администратора БД, связанный с неверной миграцией), и саму базы данных (если она может быть прочитана от начала до конца, то с большой долей вероятности она не повреждена).
Nbackup (он же инкрементальный бэкап) – временно блокирует основной файл БД на запись (в консистентном состоянии), и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).
Для больших БД Firebird (более 500Гб), предпочтительно делать nbackup, чтобы не тормозить работу пользователей, но при этом нужно проверять БД, ведь созданные неверифицированные бэкапы – это страничные копии БД, и если ошибка гнездится на уровне записей (такое случается из-за сбоя RAM) или на логическом уровне, то неверифицированный бэкап будет ее содержать так же, как и оригинальная БД.
Для этого нужно использовать онлайн-валидацию исходной базы данных (в Firebird начиная с версии 2.5.4 доступна онлайн-валидация при помощи gfix, а наш инструмент FBDataGuard поддерживает онлайн-проверку БД для версий 1.5-2.5).
Также, в дополнение к неверифицированному бэкапу желательно периодически (раз в неделю, например) делать верифицированный бэкап.
Для других СУБД необходимо использовать соответствующие средства и комбинации проверок.
8. Отсутствие контроля за свободным местом для бэкапа
В общем-то, это классическая ошибка — при недостатке места бэкап занимает все свободное место и аварийно завершается. При размещении бэкапа на одном диске вместе с БД может привести к остановке работы с БД, при размещении на системном диске – к поломке системы.
В комбинации с пунктом 4 в лучшем случае получим остановку работы системы, потому что базе данных тоже нужно свободное место, а оно кончилось из-за бэкапа.
А в комбинации с пунктами 5 и 2 опять получаем в результате отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты для бэкапа, которые делают прогноз размера бэкапа и предупреждают о возможной нехватке места.
9. Отсутствие контроля времени продолжительности бэкапа
Буквально полгода назад бэкап длился 40 минут, и вдруг стал 3 часа – почему? Возможно, вырос размер БД, а может быть, выпал диск из RAID-массива, отчего скорость записи резко деградировала, и все ваши бэкапы вот-вот покинут этот бренный мир. А может быть, добрый коллега одновременно включил еще одну систему резервного копирования (кстати, в Firebird можно запустить несколько бэкапов сразу, только не очень понятно, зачем это может быть нужно).
Если не контролировать время исполнения бэкапа, то можно проглядеть возникшую проблему и упустить шанс исправить ее до того, как она станет большой.
Также, в случае, если система резервного копирования не отслеживает состояния заданий, а запускает их просто по графику, легко можно попасть на «утренний троллейбус» — это когда новый бэкап может начаться в момент, пока предыдущий еще не закончился.
Рекомендации: использовать средства контроля продолжительности процесса бэкапа.
10. Исполнение бэкапа БД во время применения апдейтов ОС
Очень частая проблема, особенно в комбинации с п.9 и включенными автоматическими апдейтами Windows (которые по умолчанию происходят в 3 ночи). В лучшем случае приводит к замедлению процесса, а если ОС перегружается для применения апдейтов, то бэкап будет испорчен. Хорошо еще, что апдейты ОС не каждый день случаются.
Рекомендации: Если нельзя отключить, то назначьте апдейты ОС на такое время, когда они не смогут помешать бэкапам.
11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Многие администраторы забывают о том факте, что любая СУБД имеет активный и сложный кэш, в котором содержатся читаемые и записываемые данные, а сами файлы БД открываются в режиме случайного доступа.
Именно поэтому необходимо использовать специальные виды бэкапа, а не простой файловый бэкап (включая простое копирование файлов БД) или бэкап виртуальной машины. Файловые средства бэкапа читают БД последовательно и, особенно для больших БД, могут идти продолжительное время, поэтому нельзя гарантировать целостность созданной копии.
Для желающих осуществлять бэкап БД с помощью файловых средств или средств бэкапа виртуальных машин можно предложить 2 способа:
- полностью выключать сервисы и процессы СУБД, чтобы ничего не находилось в кэше,
- использовать агенты и/или скрипты, переводящие базы данных в специальный режим, когда копирование файла БД последовательным образом является безопасным.
Для Firebird необходимо блокировать основной файл БД с помощью nbackup до начала резервного копирования и разблокировать после окончания, для других СУБД есть аналогичные средства включения/выключение соответствующих режимов.
Кое-кто из администраторов БД убежден, что если в СУБД есть лог транзакций, то такую БД можно безопасно бэкапить стандартными файловыми средствами, в крайнем случае будет повреждение только этого лога. Это опасное заблуждение, которое не поддерживается производителями СУБД.
Корни этого заблуждения понятны: агрессивная реклама от производителей виртуальных машин и от производителей средств бэкапа обычно умалчивает о том, что для БД и других активно изменяемых файлов необходимы дополнительные настройки. Не доверяйте рекламе — не все йогурты одинаково полезны.
Рекомендации: не используйте файловые средства бэкапа и средства бэкапа VM без соответствующих средств автоматизации.
12. Подмена бэкапа репликацией
Бэкап и репликация данных служат повышению надежности и предотвращению потери данных, но все же существенно отличаются.
Все любят репликацию за способность синхронизировать данные на другом сервере с минимальном задержкой, однако и у бэкапа есть ряд неоспоримых преимуществ. Например, в случае случайного (или намеренного) удаления данных репликация быстро и невозмутимо оттранслирует изменения на реплику, а бэкап, особенно на read-only носителе, к таким операциям невосприимчив. Настроить правильную репликацию, как и правильный бэкап, стоит определенных усилий, и вероятность ошибок там также существует.
Рекомендации: Если у вас настроена репликация, не пренебрегайте бэкапами, используйте их совместно.
Выводы
Правильно организовать резервное копирование для вашей любимой СУБД не так-то и просто, поэтому обычно администраторы БД из организаций, где ценят данные, обычно используют профессиональные инструменты для бэкапов, которые позволяют учесть и предотвратить описанные выше ошибки. Для Firebird (уж простите за рекламу) есть наш FBDataGuard, для других СУБД можно использовать DBArtisan или другие средства.
Ну, и конечно – не забывайте холить и лелеять свою админскую паранойю, например, возьмите и проверьте свои бэкапы… вот прямо сейчас!
UPDATE
Господа, просьба откликнуться в личку тех, кто использует CBT на VMWare для ВМ с БД.
Комментарии (74)
amarao
28.09.2015 22:17+4Пункт пять — точно неуниверсальный. Если есть нормальный мониторинг, то он активно проверяет, что бэкап сделался. А если проверялка ломается, то это идёт как UNKNOWN с алертом. А если мониторинг ломается, то это более общий случай, и он должен быть закрыт вторым (и даже третьим) off-site мониторингом. Можно даже (лучше) чужой компании.
Попытка масштабировать этот принцип (слать письма об успешном бэкапе) на хотя бы пару тысяч СУБД в компании, сделает так, что эти письма никто никогда ни при каких условиях читать не будет. Даже если там будет кровью и marquee написано «BACKUP FAILED».
AlexeyKovyazin
28.09.2015 22:25Согласен, но в п.5 не зря в рекомендациях упомянуты обзорные средства контроля. Это когда с сотни мониторимых БД собираются главные статусы и показываются на одной странице. Т.е. это «вторая производная» от мониторинга экземпляра.
Спасибо за идею — отмечу себе написать статью на эту тему.
navion
28.09.2015 23:12+1При таких масштабах бекап наверняка делается не скриптами, а навороченным софтом с дашбордом, отчётами и бородатым сисадмином для их чтения.
amarao
29.09.2015 13:49Появление систем управления конфигурацией делает «скрипты» очень хорошо масштабируемыми между инсталляциями, так что городить «навороченный софт» там, где справляется dump|gz|gpg |scp — смысла нет.
Keep it simple, stupid — чистой воды.AlexeyKovyazin
29.09.2015 13:59Все так, но с т.з. бизнеса приобрести систему с GUI и авторазвертыванием выглядит экономичнее и быстрее, чем нанимать/заставлять админов писать скрипты и разбираться с системами конфигураций.
Мне кажется, что именно на аллергии бизнеса к админам зиждется успех Акрониса, Виима и всех прочих.amarao
29.09.2015 14:11+1Очередное пересечение энтерпрайза и ИТ-бизнеса. У меня уже пальцы болят повторять это снова и снова. Есть бизнес, который аутсорсит ИТ-компетенцию, а есть который держит in-house. И первые вторых не разумеют, и вторые над первыми посмеиваются. Право на существование есть у обоих (рынок решает).
hint: в нормальных конторах у админов есть code review, такое же, как у программистов, так что «что попало» в продакшен не попадает.AlexeyKovyazin
29.09.2015 14:16+1Я все время держал в уме именно enterprise при написании и статьи, и комментов.
navion
29.09.2015 15:13It depends.
У хостера может быть облако из тысяч виртуалок под веб-сервера с услугой бекапа за 100 рублей и без особых требований к RPO/RTO. А в банке или страховой компании стоят штучные пешки с базой размазанной по хостам и десятками политик хранения (в том числе установленных законодательством).
Наверное можно изобрести свой велосипед для этого, но не лучше потратить ресурсы на что-то полезное?
Опять же, управление ленточными библиотеками штука весьма нетривиальная и совсем не похоже на tar с одним приводом.amarao
29.09.2015 15:28После того, как допилили swift до ума, ленточные накопители остаются либо как легаси, либо как метод «чуть-чуть сэкономить» (с чем отлично борятся производители enterprise-решений).
navion
29.09.2015 15:42Для лент остаётся долгосрочное и офлайновое хранение.
А за объектными хранилищами будущее, тут спору нет — даже IBM в последней версии софта включил такой тип пулов. Кстати, в swift уже допилили erasure code?amarao
29.09.2015 16:03У меня чешутся руки попробовать сделать шпиндели с остановкой — этакий полу-оффлайн свифт.
Но я бы на ленту всё равно сильно не надеялся — одиночная копия, всё равно может помереть.
А вот wipe'а в swift'е (по крайней мере в той, который я знаю), увы, нет, и я не понимаю как он вообще может быть. Диск может сдохнуть в любой момент и в любой момент перейти в режим «почти работаю».
Так что для чувствительных данных — шифрование, либо режим физуничтожения дисков из-под свифта.navion
29.09.2015 21:27С шифрованием теряется дедупликация, лучше писать на диски с FDE.
Без дедупликации ленты выходят сильно дешевле, даже если писать по две копии для сохранности — картридж на 2.5 ТБ стоит $30, а зимой появится LTO7 с нативной емкостью в 6.4 ТБ.amarao
29.09.2015 22:47Хм. Ленты выглядят дешевле, чем я думал. А сколько стоит библиотека на, допустим, 5Тб?
Дедупликации swift не предоставляет, так что об этом можно особо не париться. Да и «дедуплицировать бэкапы» — это такой совет из разряда «мы делали бэкапы снапшотами, а потом один-единственный массив вылетел, и теперь все наши 100500 снапшотов не доступны!»navion
30.09.2015 00:02Если имели ввиду 5 петабайт, то TS3500 на 1000 кассет с 4 драйвами по прайсу стоит около 100 килобаксов + кассеты. Но тут могу ошибаться, лучше спросить продаванов.
amarao
30.09.2015 00:21Да, 5Пб, путаюсь в префиксах.
$100k, это условно, 10 jbod-серверов с парой JBOD'ов (без самих дисков). 100 дисков на сервер, 1000 дисков. 4 Пб raw space на 4Тб дисках, 1.3Пб storage space. Плюс SSD для меты.
Пожалуй, да, кассеты звучат интересно. Весьма внезапно для меня.
Спасибо за информацию.
navion
28.09.2015 22:56На 11 бункте у меня случился фейспалм, а при упоминании nbackup вырвался истеричный смешок.
Для Firebird это может быть справедливо, а MSSQL и Oracle поддерживают VSS, который дёргает базу при бекапе виртуалки. При большой нагрузке это решается снепшотами СХД либо снятием резервной копии с реплики.AlexeyKovyazin
28.09.2015 23:36Если установить и настроить интеграцию в guest, то поддерживает. Отсюда и рекомендация — не используйте без соотв. средств.
А то ведь люди просто создают виртуалку, и бэкапят ее… как получится.
Кроме того, помимо MSSQL и Oracle есть много других СУБД, для которых pre-backup/post-backup scripts (аналогично nbackup) вполне себе решение.navion
29.09.2015 01:33Ну это прописная истина, хотя и 12 ошибок в статье недалеко от неё ушли. А с nbackup сам промахнулся, больно название похожее.
gluko
28.09.2015 23:4811. Пункт все еще вызывает у меня сомнения…
Объясните пожалуйста более доходчиво, почему нельзя бэкапить БД средствами гипервизора?
Ведь гипервизор создает моментальный снимок файловой системы и все файлы будут прочитаны как бы в один момент времени, атомарно (не зависимо от реального времени чтения). То есть в худшем случае это должно быть равносильно отключению электропитания сервера БД. Согласен, это плохо, но терпимо.AlexeyKovyazin
29.09.2015 00:16+1Нельзя бэкапить при работающем сервере СУБД в случае, если БД не находиться в специальном режиме (в Firebid это блокировка записи в основной файл средствами nbackup), или не поддерживает интеграцию с VSS (который надо установить и настроить). VSS — Volume Shadow copy Snapshot service, фреймворк, который позволяет делать безопасные снепшоты — фактически, фиксирует файл БД в консистентном состоянии на период производства снепшота.
Для каждой СУБД нужен свой VSS writer.
Из кэша в любой момент может начаться сброс страниц данных в файл БД, и попадать эти страницы будут в разные части файла БД.
О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время. Не говоря уже о том, что говоря о кэше, мы должны понимать, что существует иерархия кэшей — кэш СУБД, файловый кэш ОС, кэш контроллера/СХД.
Это действительно похоже на отключение электропитания сервера БД. На мой взгляд, это некое развитие пункта 6 — формально бэкап мы сделаем, но что в результате получится, надежным бэкапом назвать сложно.
Похоже, тема для еще одной статьи нарисовалась :).gluko
29.09.2015 08:07+1О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время.
Вот это мне и не дает покоя… Например, я точно знаю, что снимки файловой системы ZFS выполняются одной элементарной операцией в один момент времени или не выполняются вообще. Другими словами это не процесс, а действие, во время которого существование других действий невозможно. Но у ZFS иная модель нежели у NTFS, — транзакционная… Неужели NTFS не способна на атомарный снимок?
Вот ссылка на описание снимков ZFS если что… docs.oracle.com/cd/E19253-01/820-0836/gbciq/index.html
sigmatik
29.09.2015 08:31А если предварительно, перед началом создания снимка поставить ВМ на паузу, сделать снэпшот и запустить снова? Ведь при этом все операции чтения/ записи в кэш, лог и файлы бд просто приостанавливаются. Другой вопрос, не воспримет ли субд такую операцию как «зависание» системы, и не захочет ли запустить принудительную проверку целостности бд…
VolCh
29.09.2015 12:36Вот именно, что приостанавливаются, а значит файловая система находится не в консистентом состоянии. Как минимум при восстановлении как раз и начнётся проверка целостности БД и на какой момент удастся восстановиться (если удастся вообще) никто не скажет.
TaHKucT
29.09.2015 13:32есть некая СУБД, у нее есть свой кэш в оперативной памяти, СУБД думает «Мой кэш почти полон, сейчас я запишу в файл file по смещению X новую запись, а по смещению Y помечу эту запись „удаленной“, что бы потом сборщик мусора ее удалил». СУБД пишет начинает писать по смещению X и тут происходит снэпшот. Вы восстанавливаетесь из снэпшота, но ОЗУ и состояния приложения не восстанавливается. СУБД видит что по смещению X есть некая запись, по смещению Y запись на удаление не помечена, что делать «в общем случае» непонятно и начинаются варианты, которые зависят от конкретной СУБД, наличия транзакций и кучи других факторов.
Что бы сделать корректный снэпшот нужно сказать СУБД «приведи все файлы в консистентное состояние», сделать снэпшот, и сказать СУБД «Продолжай работу». Именно для этого придуман VSSVolCh
29.09.2015 14:17Ещё нужно не забыть сказать это ОС, если доступ к диску бэкапером осуществляется в обход неё.
gluko
01.10.2015 10:38+1То есть современные СУБД в момент записи новых данных «портят» старые до того как полностью запишутся новые? Просто я думал все адекватные системы (в том числе файловые системы) имеют COW архитектуру, которая как раз исключает неконсистентное состояние данных даже при жестком отключении питания. То есть сначала создаются новые данные, затем уничтожаются старые…
VolCh
01.10.2015 11:19+1Часто регулируется настройками СУБД, администратор или разработчик выбирает какой механизм записи использовать, в зависимости от допустимого компромиса между скоростью и надежностью. Далеко не всегда вопрос «а как будем обеспечивать консистентные (хотя бы на уровне схемы БД) бэкапы» при этом выборе приоритетный.
amarao
29.09.2015 13:51Обычная практика — бэкап с RO slave'а. Слейв, конечно, по синку может отстать от мастера, но если это специальная реплика для выполнения бэкапов — никаких проблем, нагонит после завершения.
AlexeyKovyazin
29.09.2015 14:02Уточню — это для клиентов slave является RO, а для процесса репликатора он вполне себе writeable. Поэтому без фриза БД и тут никак — либо скрипты, либо VSS-aware.
amarao
29.09.2015 14:14Ну, я ваши файрбёрды не знаю, я по бэкапам мускуля говорю. mysqldump со слейва работает просто «на ура».
AlexeyKovyazin
29.09.2015 14:19попробуйте дать серьезную нагрузочку на синхронизацию слейва, чтобы размер БД гигов 100, пакет синхронизации гиг-два, и чтобы апдейты в основном, да по историческим документам, и в этот момент дамп. А потом проверьте его :)
amarao
29.09.2015 14:21У нас оно очень давно в этом режиме. Слейв в момент выполнения бэкапа отстаёт от мастера (по понятным причинам), потом судорожно нагоняет. Если репликация не выдерживает нагрузки на СУБД — либо СУБД неправильно готовят, либо ресурсов выделено непропорционально задаче.
VolCh
29.09.2015 14:29Только при использовании транзакционного режима или (а в случае движков не поддерживающих транзакции — только) блокировки записи таблиц всеми, включая процесс репликатора (или его остановка), иначе дамп может быть неконсистентным.
amarao
29.09.2015 14:37Ну да. Для этого отдельная реплика и делается. А что она пыхтит потом несколько часов, нагоняя, это уже её проблемы.
navion
29.09.2015 15:18Было бы круто увидеть таблицу с разными БД/ОС и типами бекапа для них.
А VSS кроме Jet DB, MSSQL и Oracle кто-нибудь умеет? В DB2, MySQL и Postgres его точно нет, но для последней вроде бы заявлен консистентный бекап при снепшотах ФС (если охвачены все таблицы).
amarao
29.09.2015 22:51+1Кстати, насчёт бэкапа виртуалки вы не правы. Все современные гипервизоры (точнее, их управляющий софт) делают снапшот мгновенным. Чаще всего это делается через кратковременную паузу виртуалки, и переключении IO в новую дельту/снапшот/временный файл/etc.
То есть кеши у диска не скидываются, но рассказывать ужастики из разряда «бэкап виртуалки читает, в это время виртуалка пишет, и половина данных уходит в „старую“ половинку, а половина в „новую“ — не надо.
Beltoev
29.09.2015 00:39Что-то подобное уже было: habrahabr.ru/company/croc/blog/230153
AlexeyKovyazin
29.09.2015 00:47Цифра 12, наверное, что-то значит именно для темы бэкапов :) Есть похожее, согласен, но я старался написать именно про специфику бэкапов БД.
Areso
29.09.2015 07:33+1Для себя вывел правило: не делать бэкап на сетевой диск напрямую.
DmitryKuzmenko
29.09.2015 14:07а почему? например, у InterBase рекомендуется делать дамп (не бэкап) именно в сеть.
Areso
30.09.2015 06:59Есть негативный опыт, когда бэкап делался на примонтированный сетевой диск, и прямо-таки несколько случаев подряд, как бэкап делался на сетевой ресурс средствами MS SQL Server. Да, в обслуживаемой организации сеть была не самой лучшей (включая потери пакетов), но это не отменяет факта, что сделанные через сеть бэкапы были побитыми.
DmitryKuzmenko
30.09.2015 13:34спасибо, согласен. Тем не менее, бывают люди, которые хотят чтобы БД была доступна на сетевом хранилище…
minamoto
30.09.2015 16:00+1Сделайте бэкап на локальный диск и потом перенесите его хотя бы тем же robocopy с проверкой контрольных сумм. Механизм бэкапа не обязан проверять, что данные на место хранения приехали в том виде, в котором они были отправлены, а специализированные утилиты умеют это делать гораздо лучше.
VolCh
30.09.2015 20:39Доступна на сетевом хранилище и делается локально не исключает друг друга. Дамп на локальный диск, а потом копировать по сети. Если какие-то проблемы с сетью, то, как минимум один дамп будет локально.
dgstudio
29.09.2015 09:32+1Что-то совсем уж чайниковская статья.
Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?
О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?
О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».AlexeyKovyazin
29.09.2015 13:48+2Прежде всего — очень хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций. Желательно, в личку, такая информация в руках понимающих людей — прямо таки горячая и очень дорогая. Это вещь «посильнее фаустагёте».
>Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
Такие рассуждения я побоюсь опубликовать, это слишком это смело для мира реляционных БД с их старомодным ACID.
>О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт >дамп первых таблиц — последние могут противоречиво обновиться?
Думаю, от таких хостеров надо бежать, а не рассуждать. Если они про VSS не знают и вообще как бэкапы БД делать.
>О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Вот это действительно интересно, надо бы написать.
Но если Вы напишите — тоже хорошо будет.
>Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Спасибо, я учту Ваше мнение.
Но — за диском все таки последите, нелишним оно будет :)dgstudio
29.09.2015 14:10Претензиями обменялись, теперь можно говорить по делу :)
хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций
Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
для мира реляционных БД с их старомодным ACID
ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.
В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.
И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.
(конечно это решаемо тысячей разных путей, безусловно, но факт налицо)
Думаю, от таких хостеров надо бежать, а не рассуждать
Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Что ещё обсудим? :) Any comments welcome!AlexeyKovyazin
29.09.2015 14:35>кого удалось найти HR-службе
Я разделяю Вашу боль, но вот после этого описания спрошу — Вы зачем в аду работаете-то? Сколько отличных компаний нанимают, идите к ним, а ад пусть сожжет сам себя и разорится. :)
>эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
В субботу я был на ISDEF, и там Николай Мациевский из айри рассказывал про нулевую толерантность к ошибкам исполнителей (ппт пока не выложили, к сожалению). Мы там с ним поспорили, что дескать так нельзя, к людям надо «поширше и помягше», но вот то что Вы рассказываете — это просто за гранью же. Такой софт и работать не сможет в многопользовательском режиме. Проще его не делать, чем так делать.
>Всё — ваша целостность данных развалилась.
Все-таки прочтите пункт 7. Он конечно про Firebird, но в MySQL точно должна быть такая функциональность же/ Я к сожалению (или к счастью) с MySQL не работал, но это там точно должно быть.
Суть идеи — перед началом дампа база фиксируется в консистентном состоянии (т.е. все транзакции завершены), а все изменения движок пишет во внешнюю дельту. Т.е. пока идет дамп, основной файл БД не меняется. Конечно, если игнорировать транзакции, может развалиться логическая целостность БД с т.з. бизнес-задачи, но не логическая целостность с т.з. database constraints.
>Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный >сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Я с хостерами немного знаком и скажу, что проблема тут не в технологиях, и не в недостатке знаний, а в раздолбайстве :)
И совет повторю — бегите с виртуального хостинга, так как это практически вымерший вид услуг, для статики только. 10 баксов за виртуалку на DO и, при наличии аккаунта в гугле и толики хитрости, ноль баксов за бэкапспейс — вполне реально.
>Что ещё обсудим? :) Any comments welcome!
Да поработать бы надо :)
DmitryKuzmenko
29.09.2015 14:16+3>Что-то совсем уж чайниковская статья.
увы. все по реальным факапам. Я давно читал, что это психологический момент. Типа, мозг негативные мысли убирает на второй план, поэтому про вероятность возникновения плохой ситуации плохо думается, или быстро забывается.
Я собирал случаи таких факапов, в том числе из инета, но потом бросил, потому что все повторяется, и все одно и то же.
Главное, что многие сбои происходят из-за внешних, природных причин. Хранили бэкапы в специальной фирме, а ее залило наводнением. Рядом с серверной ударила молния. И т.д. Поэтому админ должен быть слегка параноиком, чтобы придумать все эти возможные случаи.
p.s. еще и вспышки на солнце влияют, как бы странно это на первый взгляд не казалось.
RicoX
29.09.2015 10:16Несколько замечаний/дополнений по пунктам:
1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Хранить единственную версию бэкапа, не лучшая идея как в принципе, если же у нас организован план бэкапов, где есть и инкрементальные и полные и архивные, то удаление (перенос в архив) до начала выполнения бэкапа вполне себе норма, т.к. затрется только самая старая копия, а не последняя.
5. Отсутствие проверки успешного окончания бэкапа
Не совсем понятна политика оповещений, когда все хорошо, оповещения должны быть когда все плохо, иначе их просто перестают читать, к тому-же есть система мониторинга, на которой вылезет алярма о проблеме если, например, бэкап невозможно восстановить, у него сильно отличается размер с предыдущим, после восстановления контрольные запросы в базу вернули непредсказуемый результат и т.п. все это задача комплексного мониторинга, а не отдельных писам в отдельной папочке админа, когда таких баз будет больше нескольких десятков письма, что все хорошо, гарантированно перестают читать уже через неделю эксплуатации.
11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Да отлично все работает, а с дуру можно и половой орган сломать, полные бэкапы виртуалки или отдельного стораджа делаются не с боевой базы, а с ее реплики, стопим реплику, делаем полный бэкап всего, стартуем реплику, она подсасывает изменения — это нужно, т.к. кроме самой базы в окружении может быть просто море тюнинга, кастомных настроек, костылей и велосипедов и бэкап просто базы, без воссоздания окружения может просто не заработать.VolCh
29.09.2015 12:49+1Не совсем понятна политика оповещений, когда все хорошо, оповещения должны быть когда все плохо, иначе их просто перестают читать
Это хорошо работает, когда комплексной многоуровневой циклической системы мониторинга нет, а следить нужно за небольшим фиксированным количеством сущностей. Да и даже если есть полноценный мониторинг, то отсутствие от него письма или смски раз сутки «я мониторю, проблем нет» скажет о наличии проблем в, как минимум, самом мониторинге.
AlexeyKovyazin
29.09.2015 13:55Зачем стопить БД, если можно реализовать пре-/пост-скрипты виртуальной машины, чтобы они БД в архивнодружелюбный режим вводили/выводили (намеренно указываю самый универсальный вариант)?
Если БД без воссоздания окружения не имеет ценности, то нужно сменить угол зрения и реализовать бэкап всей системы, в котором БД только часть. И тут сразу становится понятно, зачем нужны комплексные системы управления резервным копированием.RicoX
29.09.2015 14:25Скрипты реализуются, но суть не меняется, все равно это делается на реплике, а не на живой базе, полный стоп удобней при высокой степени сжатия, время выполнения бэкапа меньше на порядок, если нет обращений к реплике.
Ну как часто вы сможете бэкапить систему? В том то и дело что делается в комплексе, грубо говоря раз в месяц бэкапим окружение, т.к. не очень часто меняется но сложно воссоздается, бэкапы же базы делаются намного чаще итого при факапе в целом, накатываем целиком последний бэкап всего окружения и добиваем до актуального состояния бэкапом только базы, поверх суточного бэкапа базы, накатываем часовые бэкапы и т.д. в зависимости от политики резервирования.AlexeyKovyazin
29.09.2015 14:44Стратегия бэкапов зависит от стоимости потенциального простоя и потери данных. Берете листок бумаги, и накидываете вводные — 1) развал главного сервера, 2) развал главного и реплики, 3) развал СХД, 4) саботаж и т.д. рядом ставите примерную вероятность, и прикидываете как с этим бороться. Подсчитываете стоимость шагов, получаете уровни защищенности, ну и дальше бизнес решает, какой план выбрать.
Стоимость близкой к идеалу непрерывности бизнеса, основанного на сложной ИТ системе, может быть достаточно велика, но стоимость простоев может вообще убить бизнес.
minamoto
30.09.2015 16:091) Ну, например, храните вы бэкап 4 недели, и делаете раз в неделю.
Первый бэкап удалили, новый не сделался (не принципиально, по каким причинам). Уведомления о невыполнении бэкапа вы не получили. Вторую неделю та же история. Третью и четвертую — и все, вы без бэкапов. Т.е. совмещение этого пункта с некоторыми другими дает потерю бэкапов, а если соблюсти этот пункт, то бэкапы сохранятся, пусть и более старые, чем хотелось бы.RicoX
30.09.2015 16:22По вашему кейсу. Если я 4 недели не читаю оповещения мониторинга, как и весь отдел, то мне кажется — это уже не проблема удаления бэкапа заранее, а другого плана. Место в любом случае не резиновое, тогда если сначала мы делаем бэкап, а потом удаляем старый, то храним только 3 бэкапа, так как единовременно влазит только 4, что усугубляет описанный вами сценарий на 25%. В моем сценарии мы имеем 3 бэкапа только в моменты снятия нового. При условии резинового места, ваш сценарий предпочтительней — это логично, но покажите мне проект, где место резиновое.
minamoto
30.09.2015 16:37Я в общем случае тоже чаще пренебрегаю этим правилом. Особенно при условии ограничения свободного места.
Но есть кейсы, в которых это правило все же стоит выполнять — когда нет возможности получать мониторинг, например.
seventh
29.09.2015 15:46+1Вы меня пугаете.
Делаю бэкап БД своих пяти сайтов так:
mysqldump --opt -Aau backup -ppassword > /home/seventh/all.sql
Потом этот файлик отправляется далеко за пределы сервера.
Нормально?harlong
29.09.2015 20:08Вот только хотел дополнить пунктом про «за пределы сервера». Скорее в формулировке «разделяйте права на создание бэкапов и их изменение/удаление». Для начинающих админов вполне логичным является вариант, когда серверу БД (или с другой нужной информацией) дан доступ к хранилищу бэкапов на запись, и он создает там новые файлы. Логичный он ровно до того момента, когда злоумышленник, скомпрометировав основной сервер, используя этот же канал, удаляет или портит все бэкапы.
С тех пор, как проверили это на собственной шкуре — у основного сервера в хранилище бэкапов доступ create-only. А уже старые версии по мере необходимости удаляются самим бэкап-сервером.seventh
29.09.2015 20:54Понятно, спасибо.
А сам способ полноценен/достаточен для не моментального восстановления?harlong
29.09.2015 21:28+2Теоретически при большом количестве запросов на запись mysqldump без --lock-tables может выдать бэкап с поломанными логическими связями между таблицами. Собственно, вот статья на эту тему.
seventh
30.09.2015 09:39· --opt This option is shorthand. It is the same as specifying --add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset. It should give you a fast dump operation and produce a dump file that can be reloaded into a MySQL server quickly.
И даже, оказывается
The --opt option is enabled by default. Use --skip-opt to disable it.
VolCh
30.09.2015 20:43Если остановка базы не смертельна, то нормально. Единственное и сжимал бы его через пайп.
Nastradamus
30.09.2015 02:28-1Очень странная статья и странные комментарии. Никто не сделал замечание, что даже в MySQL нет такой боли при бэкапах.
Сложилось ощущение, что Firebird — это БД, а не СУБД.
vintage
Репликами точно также можно «бэкапить». Стартанули реплику, дождались синхронизации, остановили. Вот вам и бэкап, который можно заресторить практически мгновенно.
AlexeyKovyazin
Можно, конечно, но для этого надо узел репликации поднять, правильно? То есть еще одна ВМ как минимум, а для бэкапа достаточно свободного пространства. Что касается мгновенно — так неверифицированные бэкапы для того и созданы.
Все-таки репликация — это процесс, а бэкапы — вещь :)
Dreyk
можно еще сделать постоянную репликацию с намеренным лагом, например, в день. И если кто-то грознет основную базу, можно еще успеть)