Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
Репликами точно также можно «бэкапить». Стартанули реплику, дождались синхронизации, остановили. Вот вам и бэкап, который можно заресторить практически мгновенно.
Можно, конечно, но для этого надо узел репликации поднять, правильно? То есть еще одна ВМ как минимум, а для бэкапа достаточно свободного пространства. Что касается мгновенно — так неверифицированные бэкапы для того и созданы.
Все-таки репликация — это процесс, а бэкапы — вещь :)
Все-таки репликация — это процесс, а бэкапы — вещь :)
можно еще сделать постоянную репликацию с намеренным лагом, например, в день. И если кто-то грознет основную базу, можно еще успеть)
Пункт пять — точно неуниверсальный. Если есть нормальный мониторинг, то он активно проверяет, что бэкап сделался. А если проверялка ломается, то это идёт как UNKNOWN с алертом. А если мониторинг ломается, то это более общий случай, и он должен быть закрыт вторым (и даже третьим) off-site мониторингом. Можно даже (лучше) чужой компании.
Попытка масштабировать этот принцип (слать письма об успешном бэкапе) на хотя бы пару тысяч СУБД в компании, сделает так, что эти письма никто никогда ни при каких условиях читать не будет. Даже если там будет кровью и marquee написано «BACKUP FAILED».
Попытка масштабировать этот принцип (слать письма об успешном бэкапе) на хотя бы пару тысяч СУБД в компании, сделает так, что эти письма никто никогда ни при каких условиях читать не будет. Даже если там будет кровью и marquee написано «BACKUP FAILED».
Согласен, но в п.5 не зря в рекомендациях упомянуты обзорные средства контроля. Это когда с сотни мониторимых БД собираются главные статусы и показываются на одной странице. Т.е. это «вторая производная» от мониторинга экземпляра.
Спасибо за идею — отмечу себе написать статью на эту тему.
Спасибо за идею — отмечу себе написать статью на эту тему.
При таких масштабах бекап наверняка делается не скриптами, а навороченным софтом с дашбордом, отчётами и бородатым сисадмином для их чтения.
Появление систем управления конфигурацией делает «скрипты» очень хорошо масштабируемыми между инсталляциями, так что городить «навороченный софт» там, где справляется dump|gz|gpg |scp — смысла нет.
Keep it simple, stupid — чистой воды.
Keep it simple, stupid — чистой воды.
Все так, но с т.з. бизнеса приобрести систему с GUI и авторазвертыванием выглядит экономичнее и быстрее, чем нанимать/заставлять админов писать скрипты и разбираться с системами конфигураций.
Мне кажется, что именно на аллергии бизнеса к админам зиждется успех Акрониса, Виима и всех прочих.
Мне кажется, что именно на аллергии бизнеса к админам зиждется успех Акрониса, Виима и всех прочих.
Очередное пересечение энтерпрайза и ИТ-бизнеса. У меня уже пальцы болят повторять это снова и снова. Есть бизнес, который аутсорсит ИТ-компетенцию, а есть который держит in-house. И первые вторых не разумеют, и вторые над первыми посмеиваются. Право на существование есть у обоих (рынок решает).
hint: в нормальных конторах у админов есть code review, такое же, как у программистов, так что «что попало» в продакшен не попадает.
hint: в нормальных конторах у админов есть code review, такое же, как у программистов, так что «что попало» в продакшен не попадает.
It depends.
У хостера может быть облако из тысяч виртуалок под веб-сервера с услугой бекапа за 100 рублей и без особых требований к RPO/RTO. А в банке или страховой компании стоят штучные пешки с базой размазанной по хостам и десятками политик хранения (в том числе установленных законодательством).
Наверное можно изобрести свой велосипед для этого, но не лучше потратить ресурсы на что-то полезное?
Опять же, управление ленточными библиотеками штука весьма нетривиальная и совсем не похоже на tar с одним приводом.
У хостера может быть облако из тысяч виртуалок под веб-сервера с услугой бекапа за 100 рублей и без особых требований к RPO/RTO. А в банке или страховой компании стоят штучные пешки с базой размазанной по хостам и десятками политик хранения (в том числе установленных законодательством).
Наверное можно изобрести свой велосипед для этого, но не лучше потратить ресурсы на что-то полезное?
Опять же, управление ленточными библиотеками штука весьма нетривиальная и совсем не похоже на tar с одним приводом.
После того, как допилили swift до ума, ленточные накопители остаются либо как легаси, либо как метод «чуть-чуть сэкономить» (с чем отлично борятся производители enterprise-решений).
Для лент остаётся долгосрочное и офлайновое хранение.
А за объектными хранилищами будущее, тут спору нет — даже IBM в последней версии софта включил такой тип пулов. Кстати, в swift уже допилили erasure code?
А за объектными хранилищами будущее, тут спору нет — даже IBM в последней версии софта включил такой тип пулов. Кстати, в swift уже допилили erasure code?
У меня чешутся руки попробовать сделать шпиндели с остановкой — этакий полу-оффлайн свифт.
Но я бы на ленту всё равно сильно не надеялся — одиночная копия, всё равно может помереть.
А вот wipe'а в swift'е (по крайней мере в той, который я знаю), увы, нет, и я не понимаю как он вообще может быть. Диск может сдохнуть в любой момент и в любой момент перейти в режим «почти работаю».
Так что для чувствительных данных — шифрование, либо режим физуничтожения дисков из-под свифта.
Но я бы на ленту всё равно сильно не надеялся — одиночная копия, всё равно может помереть.
А вот wipe'а в swift'е (по крайней мере в той, который я знаю), увы, нет, и я не понимаю как он вообще может быть. Диск может сдохнуть в любой момент и в любой момент перейти в режим «почти работаю».
Так что для чувствительных данных — шифрование, либо режим физуничтожения дисков из-под свифта.
С шифрованием теряется дедупликация, лучше писать на диски с FDE.
Без дедупликации ленты выходят сильно дешевле, даже если писать по две копии для сохранности — картридж на 2.5 ТБ стоит $30, а зимой появится LTO7 с нативной емкостью в 6.4 ТБ.
Без дедупликации ленты выходят сильно дешевле, даже если писать по две копии для сохранности — картридж на 2.5 ТБ стоит $30, а зимой появится LTO7 с нативной емкостью в 6.4 ТБ.
Хм. Ленты выглядят дешевле, чем я думал. А сколько стоит библиотека на, допустим, 5Тб?
Дедупликации swift не предоставляет, так что об этом можно особо не париться. Да и «дедуплицировать бэкапы» — это такой совет из разряда «мы делали бэкапы снапшотами, а потом один-единственный массив вылетел, и теперь все наши 100500 снапшотов не доступны!»
Дедупликации swift не предоставляет, так что об этом можно особо не париться. Да и «дедуплицировать бэкапы» — это такой совет из разряда «мы делали бэкапы снапшотами, а потом один-единственный массив вылетел, и теперь все наши 100500 снапшотов не доступны!»
На 11 бункте у меня случился фейспалм, а при упоминании nbackup вырвался истеричный смешок.
Для Firebird это может быть справедливо, а MSSQL и Oracle поддерживают VSS, который дёргает базу при бекапе виртуалки. При большой нагрузке это решается снепшотами СХД либо снятием резервной копии с реплики.
Для Firebird это может быть справедливо, а MSSQL и Oracle поддерживают VSS, который дёргает базу при бекапе виртуалки. При большой нагрузке это решается снепшотами СХД либо снятием резервной копии с реплики.
Если установить и настроить интеграцию в guest, то поддерживает. Отсюда и рекомендация — не используйте без соотв. средств.
А то ведь люди просто создают виртуалку, и бэкапят ее… как получится.
Кроме того, помимо MSSQL и Oracle есть много других СУБД, для которых pre-backup/post-backup scripts (аналогично nbackup) вполне себе решение.
А то ведь люди просто создают виртуалку, и бэкапят ее… как получится.
Кроме того, помимо MSSQL и Oracle есть много других СУБД, для которых pre-backup/post-backup scripts (аналогично nbackup) вполне себе решение.
11. Пункт все еще вызывает у меня сомнения…
Объясните пожалуйста более доходчиво, почему нельзя бэкапить БД средствами гипервизора?
Ведь гипервизор создает моментальный снимок файловой системы и все файлы будут прочитаны как бы в один момент времени, атомарно (не зависимо от реального времени чтения). То есть в худшем случае это должно быть равносильно отключению электропитания сервера БД. Согласен, это плохо, но терпимо.
Объясните пожалуйста более доходчиво, почему нельзя бэкапить БД средствами гипервизора?
Ведь гипервизор создает моментальный снимок файловой системы и все файлы будут прочитаны как бы в один момент времени, атомарно (не зависимо от реального времени чтения). То есть в худшем случае это должно быть равносильно отключению электропитания сервера БД. Согласен, это плохо, но терпимо.
Нельзя бэкапить при работающем сервере СУБД в случае, если БД не находиться в специальном режиме (в Firebid это блокировка записи в основной файл средствами nbackup), или не поддерживает интеграцию с VSS (который надо установить и настроить). VSS — Volume Shadow copy Snapshot service, фреймворк, который позволяет делать безопасные снепшоты — фактически, фиксирует файл БД в консистентном состоянии на период производства снепшота.
Для каждой СУБД нужен свой VSS writer.
Из кэша в любой момент может начаться сброс страниц данных в файл БД, и попадать эти страницы будут в разные части файла БД.
О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время. Не говоря уже о том, что говоря о кэше, мы должны понимать, что существует иерархия кэшей — кэш СУБД, файловый кэш ОС, кэш контроллера/СХД.
Это действительно похоже на отключение электропитания сервера БД. На мой взгляд, это некое развитие пункта 6 — формально бэкап мы сделаем, но что в результате получится, надежным бэкапом назвать сложно.
Похоже, тема для еще одной статьи нарисовалась :).
Для каждой СУБД нужен свой VSS writer.
Из кэша в любой момент может начаться сброс страниц данных в файл БД, и попадать эти страницы будут в разные части файла БД.
О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время. Не говоря уже о том, что говоря о кэше, мы должны понимать, что существует иерархия кэшей — кэш СУБД, файловый кэш ОС, кэш контроллера/СХД.
Это действительно похоже на отключение электропитания сервера БД. На мой взгляд, это некое развитие пункта 6 — формально бэкап мы сделаем, но что в результате получится, надежным бэкапом назвать сложно.
Похоже, тема для еще одной статьи нарисовалась :).
О мгновенном снимке говорить не приходится, ведь это физическая операция, которая занимает какое-то время.
Вот это мне и не дает покоя… Например, я точно знаю, что снимки файловой системы ZFS выполняются одной элементарной операцией в один момент времени или не выполняются вообще. Другими словами это не процесс, а действие, во время которого существование других действий невозможно. Но у ZFS иная модель нежели у NTFS, — транзакционная… Неужели NTFS не способна на атомарный снимок?
Вот ссылка на описание снимков ZFS если что… docs.oracle.com/cd/E19253-01/820-0836/gbciq/index.html
А если предварительно, перед началом создания снимка поставить ВМ на паузу, сделать снэпшот и запустить снова? Ведь при этом все операции чтения/ записи в кэш, лог и файлы бд просто приостанавливаются. Другой вопрос, не воспримет ли субд такую операцию как «зависание» системы, и не захочет ли запустить принудительную проверку целостности бд…
Вот именно, что приостанавливаются, а значит файловая система находится не в консистентом состоянии. Как минимум при восстановлении как раз и начнётся проверка целостности БД и на какой момент удастся восстановиться (если удастся вообще) никто не скажет.
есть некая СУБД, у нее есть свой кэш в оперативной памяти, СУБД думает «Мой кэш почти полон, сейчас я запишу в файл file по смещению X новую запись, а по смещению Y помечу эту запись „удаленной“, что бы потом сборщик мусора ее удалил». СУБД пишет начинает писать по смещению X и тут происходит снэпшот. Вы восстанавливаетесь из снэпшота, но ОЗУ и состояния приложения не восстанавливается. СУБД видит что по смещению X есть некая запись, по смещению Y запись на удаление не помечена, что делать «в общем случае» непонятно и начинаются варианты, которые зависят от конкретной СУБД, наличия транзакций и кучи других факторов.
Что бы сделать корректный снэпшот нужно сказать СУБД «приведи все файлы в консистентное состояние», сделать снэпшот, и сказать СУБД «Продолжай работу». Именно для этого придуман VSS
Что бы сделать корректный снэпшот нужно сказать СУБД «приведи все файлы в консистентное состояние», сделать снэпшот, и сказать СУБД «Продолжай работу». Именно для этого придуман VSS
Ещё нужно не забыть сказать это ОС, если доступ к диску бэкапером осуществляется в обход неё.
То есть современные СУБД в момент записи новых данных «портят» старые до того как полностью запишутся новые? Просто я думал все адекватные системы (в том числе файловые системы) имеют COW архитектуру, которая как раз исключает неконсистентное состояние данных даже при жестком отключении питания. То есть сначала создаются новые данные, затем уничтожаются старые…
Часто регулируется настройками СУБД, администратор или разработчик выбирает какой механизм записи использовать, в зависимости от допустимого компромиса между скоростью и надежностью. Далеко не всегда вопрос «а как будем обеспечивать консистентные (хотя бы на уровне схемы БД) бэкапы» при этом выборе приоритетный.
Обычная практика — бэкап с RO slave'а. Слейв, конечно, по синку может отстать от мастера, но если это специальная реплика для выполнения бэкапов — никаких проблем, нагонит после завершения.
Уточню — это для клиентов slave является RO, а для процесса репликатора он вполне себе writeable. Поэтому без фриза БД и тут никак — либо скрипты, либо VSS-aware.
Ну, я ваши файрбёрды не знаю, я по бэкапам мускуля говорю. mysqldump со слейва работает просто «на ура».
попробуйте дать серьезную нагрузочку на синхронизацию слейва, чтобы размер БД гигов 100, пакет синхронизации гиг-два, и чтобы апдейты в основном, да по историческим документам, и в этот момент дамп. А потом проверьте его :)
Только при использовании транзакционного режима или (а в случае движков не поддерживающих транзакции — только) блокировки записи таблиц всеми, включая процесс репликатора (или его остановка), иначе дамп может быть неконсистентным.
Было бы круто увидеть таблицу с разными БД/ОС и типами бекапа для них.
А VSS кроме Jet DB, MSSQL и Oracle кто-нибудь умеет? В DB2, MySQL и Postgres его точно нет, но для последней вроде бы заявлен консистентный бекап при снепшотах ФС (если охвачены все таблицы).
А VSS кроме Jet DB, MSSQL и Oracle кто-нибудь умеет? В DB2, MySQL и Postgres его точно нет, но для последней вроде бы заявлен консистентный бекап при снепшотах ФС (если охвачены все таблицы).
Кстати, насчёт бэкапа виртуалки вы не правы. Все современные гипервизоры (точнее, их управляющий софт) делают снапшот мгновенным. Чаще всего это делается через кратковременную паузу виртуалки, и переключении IO в новую дельту/снапшот/временный файл/etc.
То есть кеши у диска не скидываются, но рассказывать ужастики из разряда «бэкап виртуалки читает, в это время виртуалка пишет, и половина данных уходит в „старую“ половинку, а половина в „новую“ — не надо.
То есть кеши у диска не скидываются, но рассказывать ужастики из разряда «бэкап виртуалки читает, в это время виртуалка пишет, и половина данных уходит в „старую“ половинку, а половина в „новую“ — не надо.
Что-то подобное уже было: habrahabr.ru/company/croc/blog/230153
Для себя вывел правило: не делать бэкап на сетевой диск напрямую.
а почему? например, у InterBase рекомендуется делать дамп (не бэкап) именно в сеть.
Есть негативный опыт, когда бэкап делался на примонтированный сетевой диск, и прямо-таки несколько случаев подряд, как бэкап делался на сетевой ресурс средствами MS SQL Server. Да, в обслуживаемой организации сеть была не самой лучшей (включая потери пакетов), но это не отменяет факта, что сделанные через сеть бэкапы были побитыми.
спасибо, согласен. Тем не менее, бывают люди, которые хотят чтобы БД была доступна на сетевом хранилище…
Сделайте бэкап на локальный диск и потом перенесите его хотя бы тем же robocopy с проверкой контрольных сумм. Механизм бэкапа не обязан проверять, что данные на место хранения приехали в том виде, в котором они были отправлены, а специализированные утилиты умеют это делать гораздо лучше.
Доступна на сетевом хранилище и делается локально не исключает друг друга. Дамп на локальный диск, а потом копировать по сети. Если какие-то проблемы с сетью, то, как минимум один дамп будет локально.
Что-то совсем уж чайниковская статья.
Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?
О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?
О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?
О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?
О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Прежде всего — очень хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций. Желательно, в личку, такая информация в руках понимающих людей — прямо таки горячая и очень дорогая. Это вещь «посильнее фаустагёте».
>Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
Такие рассуждения я побоюсь опубликовать, это слишком это смело для мира реляционных БД с их старомодным ACID.
>О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт >дамп первых таблиц — последние могут противоречиво обновиться?
Думаю, от таких хостеров надо бежать, а не рассуждать. Если они про VSS не знают и вообще как бэкапы БД делать.
>О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Вот это действительно интересно, надо бы написать.
Но если Вы напишите — тоже хорошо будет.
>Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Спасибо, я учту Ваше мнение.
Но — за диском все таки последите, нелишним оно будет :)
>Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?
Такие рассуждения я побоюсь опубликовать, это слишком это смело для мира реляционных БД с их старомодным ACID.
>О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт >дамп первых таблиц — последние могут противоречиво обновиться?
Думаю, от таких хостеров надо бежать, а не рассуждать. Если они про VSS не знают и вообще как бэкапы БД делать.
>О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?
Вот это действительно интересно, надо бы написать.
Но если Вы напишите — тоже хорошо будет.
>Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
Спасибо, я учту Ваше мнение.
Но — за диском все таки последите, нелишним оно будет :)
Претензиями обменялись, теперь можно говорить по делу :)
Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.
В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.
И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.
(конечно это решаемо тысячей разных путей, безусловно, но факт налицо)
Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Что ещё обсудим? :) Any comments welcome!
хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций
Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
для мира реляционных БД с их старомодным ACID
ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.
В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.
И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.
(конечно это решаемо тысячей разных путей, безусловно, но факт налицо)
Думаю, от таких хостеров надо бежать, а не рассуждать
Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Что ещё обсудим? :) Any comments welcome!
>кого удалось найти HR-службе
Я разделяю Вашу боль, но вот после этого описания спрошу — Вы зачем в аду работаете-то? Сколько отличных компаний нанимают, идите к ним, а ад пусть сожжет сам себя и разорится. :)
>эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
В субботу я был на ISDEF, и там Николай Мациевский из айри рассказывал про нулевую толерантность к ошибкам исполнителей (ппт пока не выложили, к сожалению). Мы там с ним поспорили, что дескать так нельзя, к людям надо «поширше и помягше», но вот то что Вы рассказываете — это просто за гранью же. Такой софт и работать не сможет в многопользовательском режиме. Проще его не делать, чем так делать.
>Всё — ваша целостность данных развалилась.
Все-таки прочтите пункт 7. Он конечно про Firebird, но в MySQL точно должна быть такая функциональность же/ Я к сожалению (или к счастью) с MySQL не работал, но это там точно должно быть.
Суть идеи — перед началом дампа база фиксируется в консистентном состоянии (т.е. все транзакции завершены), а все изменения движок пишет во внешнюю дельту. Т.е. пока идет дамп, основной файл БД не меняется. Конечно, если игнорировать транзакции, может развалиться логическая целостность БД с т.з. бизнес-задачи, но не логическая целостность с т.з. database constraints.
>Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный >сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Я с хостерами немного знаком и скажу, что проблема тут не в технологиях, и не в недостатке знаний, а в раздолбайстве :)
И совет повторю — бегите с виртуального хостинга, так как это практически вымерший вид услуг, для статики только. 10 баксов за виртуалку на DO и, при наличии аккаунта в гугле и толики хитрости, ноль баксов за бэкапспейс — вполне реально.
>Что ещё обсудим? :) Any comments welcome!
Да поработать бы надо :)
Я разделяю Вашу боль, но вот после этого описания спрошу — Вы зачем в аду работаете-то? Сколько отличных компаний нанимают, идите к ним, а ад пусть сожжет сам себя и разорится. :)
>эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.
В субботу я был на ISDEF, и там Николай Мациевский из айри рассказывал про нулевую толерантность к ошибкам исполнителей (ппт пока не выложили, к сожалению). Мы там с ним поспорили, что дескать так нельзя, к людям надо «поширше и помягше», но вот то что Вы рассказываете — это просто за гранью же. Такой софт и работать не сможет в многопользовательском режиме. Проще его не делать, чем так делать.
>Всё — ваша целостность данных развалилась.
Все-таки прочтите пункт 7. Он конечно про Firebird, но в MySQL точно должна быть такая функциональность же/ Я к сожалению (или к счастью) с MySQL не работал, но это там точно должно быть.
Суть идеи — перед началом дампа база фиксируется в консистентном состоянии (т.е. все транзакции завершены), а все изменения движок пишет во внешнюю дельту. Т.е. пока идет дамп, основной файл БД не меняется. Конечно, если игнорировать транзакции, может развалиться логическая целостность БД с т.з. бизнес-задачи, но не логическая целостность с т.з. database constraints.
>Окей. Но покажите мне хоть одного хостера, предоставляющего услугу «виртуальный хостинг» (т.е. не виртуальный и не выделенный >сервер), который бэкапит как-то иначе. Я за свою карьеру не встречал.
Я с хостерами немного знаком и скажу, что проблема тут не в технологиях, и не в недостатке знаний, а в раздолбайстве :)
И совет повторю — бегите с виртуального хостинга, так как это практически вымерший вид услуг, для статики только. 10 баксов за виртуалку на DO и, при наличии аккаунта в гугле и толики хитрости, ноль баксов за бэкапспейс — вполне реально.
>Что ещё обсудим? :) Any comments welcome!
Да поработать бы надо :)
>Что-то совсем уж чайниковская статья.
увы. все по реальным факапам. Я давно читал, что это психологический момент. Типа, мозг негативные мысли убирает на второй план, поэтому про вероятность возникновения плохой ситуации плохо думается, или быстро забывается.
Я собирал случаи таких факапов, в том числе из инета, но потом бросил, потому что все повторяется, и все одно и то же.
Главное, что многие сбои происходят из-за внешних, природных причин. Хранили бэкапы в специальной фирме, а ее залило наводнением. Рядом с серверной ударила молния. И т.д. Поэтому админ должен быть слегка параноиком, чтобы придумать все эти возможные случаи.
p.s. еще и вспышки на солнце влияют, как бы странно это на первый взгляд не казалось.
увы. все по реальным факапам. Я давно читал, что это психологический момент. Типа, мозг негативные мысли убирает на второй план, поэтому про вероятность возникновения плохой ситуации плохо думается, или быстро забывается.
Я собирал случаи таких факапов, в том числе из инета, но потом бросил, потому что все повторяется, и все одно и то же.
Главное, что многие сбои происходят из-за внешних, природных причин. Хранили бэкапы в специальной фирме, а ее залило наводнением. Рядом с серверной ударила молния. И т.д. Поэтому админ должен быть слегка параноиком, чтобы придумать все эти возможные случаи.
p.s. еще и вспышки на солнце влияют, как бы странно это на первый взгляд не казалось.
Несколько замечаний/дополнений по пунктам:
Хранить единственную версию бэкапа, не лучшая идея как в принципе, если же у нас организован план бэкапов, где есть и инкрементальные и полные и архивные, то удаление (перенос в архив) до начала выполнения бэкапа вполне себе норма, т.к. затрется только самая старая копия, а не последняя.
Не совсем понятна политика оповещений, когда все хорошо, оповещения должны быть когда все плохо, иначе их просто перестают читать, к тому-же есть система мониторинга, на которой вылезет алярма о проблеме если, например, бэкап невозможно восстановить, у него сильно отличается размер с предыдущим, после восстановления контрольные запросы в базу вернули непредсказуемый результат и т.п. все это задача комплексного мониторинга, а не отдельных писам в отдельной папочке админа, когда таких баз будет больше нескольких десятков письма, что все хорошо, гарантированно перестают читать уже через неделю эксплуатации.
Да отлично все работает, а с дуру можно и половой орган сломать, полные бэкапы виртуалки или отдельного стораджа делаются не с боевой базы, а с ее реплики, стопим реплику, делаем полный бэкап всего, стартуем реплику, она подсасывает изменения — это нужно, т.к. кроме самой базы в окружении может быть просто море тюнинга, кастомных настроек, костылей и велосипедов и бэкап просто базы, без воссоздания окружения может просто не заработать.
1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Хранить единственную версию бэкапа, не лучшая идея как в принципе, если же у нас организован план бэкапов, где есть и инкрементальные и полные и архивные, то удаление (перенос в архив) до начала выполнения бэкапа вполне себе норма, т.к. затрется только самая старая копия, а не последняя.
5. Отсутствие проверки успешного окончания бэкапа
Не совсем понятна политика оповещений, когда все хорошо, оповещения должны быть когда все плохо, иначе их просто перестают читать, к тому-же есть система мониторинга, на которой вылезет алярма о проблеме если, например, бэкап невозможно восстановить, у него сильно отличается размер с предыдущим, после восстановления контрольные запросы в базу вернули непредсказуемый результат и т.п. все это задача комплексного мониторинга, а не отдельных писам в отдельной папочке админа, когда таких баз будет больше нескольких десятков письма, что все хорошо, гарантированно перестают читать уже через неделю эксплуатации.
11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Да отлично все работает, а с дуру можно и половой орган сломать, полные бэкапы виртуалки или отдельного стораджа делаются не с боевой базы, а с ее реплики, стопим реплику, делаем полный бэкап всего, стартуем реплику, она подсасывает изменения — это нужно, т.к. кроме самой базы в окружении может быть просто море тюнинга, кастомных настроек, костылей и велосипедов и бэкап просто базы, без воссоздания окружения может просто не заработать.
Не совсем понятна политика оповещений, когда все хорошо, оповещения должны быть когда все плохо, иначе их просто перестают читать
Это хорошо работает, когда комплексной многоуровневой циклической системы мониторинга нет, а следить нужно за небольшим фиксированным количеством сущностей. Да и даже если есть полноценный мониторинг, то отсутствие от него письма или смски раз сутки «я мониторю, проблем нет» скажет о наличии проблем в, как минимум, самом мониторинге.
Зачем стопить БД, если можно реализовать пре-/пост-скрипты виртуальной машины, чтобы они БД в архивнодружелюбный режим вводили/выводили (намеренно указываю самый универсальный вариант)?
Если БД без воссоздания окружения не имеет ценности, то нужно сменить угол зрения и реализовать бэкап всей системы, в котором БД только часть. И тут сразу становится понятно, зачем нужны комплексные системы управления резервным копированием.
Если БД без воссоздания окружения не имеет ценности, то нужно сменить угол зрения и реализовать бэкап всей системы, в котором БД только часть. И тут сразу становится понятно, зачем нужны комплексные системы управления резервным копированием.
Скрипты реализуются, но суть не меняется, все равно это делается на реплике, а не на живой базе, полный стоп удобней при высокой степени сжатия, время выполнения бэкапа меньше на порядок, если нет обращений к реплике.
Ну как часто вы сможете бэкапить систему? В том то и дело что делается в комплексе, грубо говоря раз в месяц бэкапим окружение, т.к. не очень часто меняется но сложно воссоздается, бэкапы же базы делаются намного чаще итого при факапе в целом, накатываем целиком последний бэкап всего окружения и добиваем до актуального состояния бэкапом только базы, поверх суточного бэкапа базы, накатываем часовые бэкапы и т.д. в зависимости от политики резервирования.
Ну как часто вы сможете бэкапить систему? В том то и дело что делается в комплексе, грубо говоря раз в месяц бэкапим окружение, т.к. не очень часто меняется но сложно воссоздается, бэкапы же базы делаются намного чаще итого при факапе в целом, накатываем целиком последний бэкап всего окружения и добиваем до актуального состояния бэкапом только базы, поверх суточного бэкапа базы, накатываем часовые бэкапы и т.д. в зависимости от политики резервирования.
Стратегия бэкапов зависит от стоимости потенциального простоя и потери данных. Берете листок бумаги, и накидываете вводные — 1) развал главного сервера, 2) развал главного и реплики, 3) развал СХД, 4) саботаж и т.д. рядом ставите примерную вероятность, и прикидываете как с этим бороться. Подсчитываете стоимость шагов, получаете уровни защищенности, ну и дальше бизнес решает, какой план выбрать.
Стоимость близкой к идеалу непрерывности бизнеса, основанного на сложной ИТ системе, может быть достаточно велика, но стоимость простоев может вообще убить бизнес.
Стоимость близкой к идеалу непрерывности бизнеса, основанного на сложной ИТ системе, может быть достаточно велика, но стоимость простоев может вообще убить бизнес.
У меня окружение в cvs, а cvs и база уже бэкапятся.
1) Ну, например, храните вы бэкап 4 недели, и делаете раз в неделю.
Первый бэкап удалили, новый не сделался (не принципиально, по каким причинам). Уведомления о невыполнении бэкапа вы не получили. Вторую неделю та же история. Третью и четвертую — и все, вы без бэкапов. Т.е. совмещение этого пункта с некоторыми другими дает потерю бэкапов, а если соблюсти этот пункт, то бэкапы сохранятся, пусть и более старые, чем хотелось бы.
Первый бэкап удалили, новый не сделался (не принципиально, по каким причинам). Уведомления о невыполнении бэкапа вы не получили. Вторую неделю та же история. Третью и четвертую — и все, вы без бэкапов. Т.е. совмещение этого пункта с некоторыми другими дает потерю бэкапов, а если соблюсти этот пункт, то бэкапы сохранятся, пусть и более старые, чем хотелось бы.
По вашему кейсу. Если я 4 недели не читаю оповещения мониторинга, как и весь отдел, то мне кажется — это уже не проблема удаления бэкапа заранее, а другого плана. Место в любом случае не резиновое, тогда если сначала мы делаем бэкап, а потом удаляем старый, то храним только 3 бэкапа, так как единовременно влазит только 4, что усугубляет описанный вами сценарий на 25%. В моем сценарии мы имеем 3 бэкапа только в моменты снятия нового. При условии резинового места, ваш сценарий предпочтительней — это логично, но покажите мне проект, где место резиновое.
Вы меня пугаете.
Делаю бэкап БД своих пяти сайтов так:
Потом этот файлик отправляется далеко за пределы сервера.
Нормально?
Делаю бэкап БД своих пяти сайтов так:
mysqldump --opt -Aau backup -ppassword > /home/seventh/all.sql
Потом этот файлик отправляется далеко за пределы сервера.
Нормально?
Вот только хотел дополнить пунктом про «за пределы сервера». Скорее в формулировке «разделяйте права на создание бэкапов и их изменение/удаление». Для начинающих админов вполне логичным является вариант, когда серверу БД (или с другой нужной информацией) дан доступ к хранилищу бэкапов на запись, и он создает там новые файлы. Логичный он ровно до того момента, когда злоумышленник, скомпрометировав основной сервер, используя этот же канал, удаляет или портит все бэкапы.
С тех пор, как проверили это на собственной шкуре — у основного сервера в хранилище бэкапов доступ create-only. А уже старые версии по мере необходимости удаляются самим бэкап-сервером.
С тех пор, как проверили это на собственной шкуре — у основного сервера в хранилище бэкапов доступ create-only. А уже старые версии по мере необходимости удаляются самим бэкап-сервером.
О! Вот эту тему надо замутить!
Понятно, спасибо.
А сам способ полноценен/достаточен для не моментального восстановления?
А сам способ полноценен/достаточен для не моментального восстановления?
Теоретически при большом количестве запросов на запись mysqldump без --lock-tables может выдать бэкап с поломанными логическими связями между таблицами. Собственно, вот статья на эту тему.
· --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.
Если остановка базы не смертельна, то нормально. Единственное и сжимал бы его через пайп.
Очень странная статья и странные комментарии. Никто не сделал замечание, что даже в MySQL нет такой боли при бэкапах.
Сложилось ощущение, что Firebird — это БД, а не СУБД.
Сложилось ощущение, что Firebird — это БД, а не СУБД.
Еще забыли упомянуть про security2.fdb
Юзеров тоже бекапить надо.
Юзеров тоже бекапить надо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
12 типичных ошибок при бэкапе баз данных