Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 69
MySQL лучше бэкапить не копированием базы, а с помощью mysqldump, а полученный дамп архивировать.
Это спасет от конфликта версий MySQL-сервера. Мало ли какие ситуации бывают)
Это спасет от конфликта версий MySQL-сервера. Мало ли какие ситуации бывают)
Это тоже можно реализовать с powerbackup. Но дело в том, что у меня есть большие таблицы в разных базах, которые являются справочниками и не меняются. В этих условиях инкрементальный tar забакапит базу намного быстрее. Да, это мой частный случай — но ведь о том и речь в статье! :)
А конфликт версий при восстановлении из бакапа не очень актуален. Восстановление из бакапа операция очень редкая, вероятность что именно с этим бакапом будет конфликт версий MySQL — минимальная. Но даже если и будет — можно при восстановлении бакапа временно поставить предыдущую версию MySQL и сделать дамп. Это займёт дополнительное время, но IMHO эта проблема не стоит того, чтобы замедлять ежедневные бакапы.
А конфликт версий при восстановлении из бакапа не очень актуален. Восстановление из бакапа операция очень редкая, вероятность что именно с этим бакапом будет конфликт версий MySQL — минимальная. Но даже если и будет — можно при восстановлении бакапа временно поставить предыдущую версию MySQL и сделать дамп. Это займёт дополнительное время, но IMHO эта проблема не стоит того, чтобы замедлять ежедневные бакапы.
mysqldump работает медленно и блокирует таблицы. Архивировать большие таблицы данным способом совершенно невозможно.
Мм… а чем не устраивает схема —
1. MySQL -> репликация
Никаких блокировок и стопов не надо. Если нет второй машины — можно поднять реплику на той же, на другом порту и с данными на другом винте, например (хотя конечно лучше другую машину)
2. Скрипты и пр. файлы (хоть весь каталог проекта) — SVN (по крону svn update)
Опять же ничего стопить не надо (если конечно нет залоченных файлов). Бэкап не просто инкрементный, но еще и с контролем версий, т. е. с возможностью откатиться не только на последнее состояние, но и на более раннее. Так же можно как локальный репозиторий организовать, так и удаленный
1. MySQL -> репликация
Никаких блокировок и стопов не надо. Если нет второй машины — можно поднять реплику на той же, на другом порту и с данными на другом винте, например (хотя конечно лучше другую машину)
2. Скрипты и пр. файлы (хоть весь каталог проекта) — SVN (по крону svn update)
Опять же ничего стопить не надо (если конечно нет залоченных файлов). Бэкап не просто инкрементный, но еще и с контролем версий, т. е. с возможностью откатиться не только на последнее состояние, но и на более раннее. Так же можно как локальный репозиторий организовать, так и удаленный
1. Репликация — это не бакап. Кроме того, в реализации репликации в MySQL хватает багов — почитайте ChangeLog MySQL.
2. Контроль версий — это не бакап. Контроль версий у нас есть отдельно, но из него можно вытащить только базовую версию проекта, без накопленных в процессе работы данных. И svn update никоим образом не гарантирует целостность полученной ревизии.
Бакап — это такой сильно ужатый файлик, который можно закатать на ленту, или DVD, или залить на резервный ftp-сервер. И из которого можно будет гарантированно восстановить Вашу систему.
А то, что предлагаете Вы — это подобие raid0. Если думать о том, как нужно делать бакап Ваших данных нет желания, то можно сделать какое-нибудь быстрое решение вроде реплики+svn или raid0 и надеяться, что этого хватит. Я об этом подходе писал в начале статьи.
2. Контроль версий — это не бакап. Контроль версий у нас есть отдельно, но из него можно вытащить только базовую версию проекта, без накопленных в процессе работы данных. И svn update никоим образом не гарантирует целостность полученной ревизии.
Бакап — это такой сильно ужатый файлик, который можно закатать на ленту, или DVD, или залить на резервный ftp-сервер. И из которого можно будет гарантированно восстановить Вашу систему.
А то, что предлагаете Вы — это подобие raid0. Если думать о том, как нужно делать бакап Ваших данных нет желания, то можно сделать какое-нибудь быстрое решение вроде реплики+svn или raid0 и надеяться, что этого хватит. Я об этом подходе писал в начале статьи.
Ну во первыз если уж сравниваете с райдом то это raid1, а не 0
Во вторых, каюсь совершил две ошибки в своем комментарии, во первых svn commit в репозиторий (а не update), а во вторых не договорил следующий шаг. Дальше делается любой совершенно тупой и не критичный к скорости бэкап реплики(dump.gz) и репозитория файлов (я просто считал это очевидным. поэтому и не написал).
>> Репликация — это не бакап.
Это зеркалирование, разумеется, разновидность резервного копирования. При падении мастера поднять на его место реплику — тривиальная задача (порой решается за несколько минут, если Mysql-сервера выделенные)
>> в реализации репликации в MySQL хватает багов
чтобы так говорить, надо быть уверенным, что в вашем софте багов нет. я сомневаюсь
>> Если думать о том, как нужно делать бакап Ваших данных нет желания
Думать желание есть, и здравое размышление приводит к тому, что есть уже существующие решения с помощью которых реально сделать надежную схему резервирования+быстрого восстановления данных
Во вторых, каюсь совершил две ошибки в своем комментарии, во первых svn commit в репозиторий (а не update), а во вторых не договорил следующий шаг. Дальше делается любой совершенно тупой и не критичный к скорости бэкап реплики(dump.gz) и репозитория файлов (я просто считал это очевидным. поэтому и не написал).
>> Репликация — это не бакап.
Это зеркалирование, разумеется, разновидность резервного копирования. При падении мастера поднять на его место реплику — тривиальная задача (порой решается за несколько минут, если Mysql-сервера выделенные)
>> в реализации репликации в MySQL хватает багов
чтобы так говорить, надо быть уверенным, что в вашем софте багов нет. я сомневаюсь
>> Если думать о том, как нужно делать бакап Ваших данных нет желания
Думать желание есть, и здравое размышление приводит к тому, что есть уже существующие решения с помощью которых реально сделать надежную схему резервирования+быстрого восстановления данных
Лучший способ резервирования базы данных — это репликация, с которой делаются дискретные копии.
Сама репликация даёт моментальный сиюминутный бэкап всех данных, но не спасает от их потери в результате ошибочного действия человека.
Сама репликация даёт моментальный сиюминутный бэкап всех данных, но не спасает от их потери в результате ошибочного действия человека.
Я разве не тоже самое написал?
Это — в теории. А на практике, как я уже упоминал, реплика глючит. Я думал log-bin заюзать для бабэкапа, почитал доку, поэкспериментировал… не помню уже какие конкретно были проблемы, но пришлось от этой идеи, с глубоким сожаленим, отказаться. Вообще, tar значительно проще, стабильнее и универсальнее, чем реплика и log-bin. Что упаковано tar-ом — гарантированно распакуется без изменений. А при попытке восстановить базу из log-bin могут всплыть самые разные грабли. Хотя, если теоретически, мне идея log-bin для бэкапов весьма симпатична.
Было бы круто, если проект на заполонялся псевдо-научными изысканиями, в той мере, в которой это происходит. Тихий ужас, который на фоне изобилия толковой справочной информации, давно и доступно опубликованной в сети, выглядит ужасающе.
Если у вас не получается обуздать репликацию и восстановить данные из текстового дампа, разве это повод обращать других людей в вашу веру?
Если у вас не получается обуздать репликацию и восстановить данные из текстового дампа, разве это повод обращать других людей в вашу веру?
> Если у вас не получается обуздать репликацию
Не смешите меня. Понадобится репликация — всё обуздаем! Дело в другом: когда я последние разы заглядывал в ChangeLog MySQL, там было много исправлений достаточно серьёзных проблем в репликации. Причём эта ситуация сохранялась на протяжении нескольких лет — как ни гляну в ChangeLog, так натыкаюсь на фиксы репликации.
Лично мне это говорит о том, что в репликации были, есть и будут баги, причём достаточно много и достаточно критичных. Я такие потенциальные «минные поля» в своём проекте без сильной нужды стараюсь не заводить.
Я прекрасно понимаю, что как-то репликация работает. На простых типовых запросах она даже, наверное, работает хорошо. Но баги там есть… И если репликацию использовать не в конкретном своём проекте (где Вы контролируете все SQL-запросы, и можете их подобрать так, чтобы на них реплика не глючила), а для бакапа всех баз на сервере, всех проектов — которые абсолютно без понятия что их будут реплицировать и которые могут использовать как раз те SQL-запросы, на которых реплика будет глючить — вероятность нарвать на баг в репликации сильно возрастает.
А, как чётко сказано в статье, я категорически против багов в процессе бакапа! Гарантировать отсутствие багов не может никто, но я любыми средствами стараюсь минимизировать вероятность столкнутся с багом.
Ну и последнее. Ситуации бывают разные, и подходы к бакапу должны это учитывать. Представьте себе базу данных, таблицы в которой не большие, но очень часто обновляющиеся. Например, накапливающие статистику по трафику: сетевых интерфейсов пара сотен, а UPDATE для них выполняется каждую секунду. В этом случае запаковать tar-ом эти таблицы можно за доли секунды, а поддержание репликации потребует нехилых ресурсов и заметно скажется на нагрузке сервера. Глубо выполнять сотню лишних UPDATE-ов в секунду вместо того, чтобы раз в сутки запаковать файл размером несколько мегабайт.
Не смешите меня. Понадобится репликация — всё обуздаем! Дело в другом: когда я последние разы заглядывал в ChangeLog MySQL, там было много исправлений достаточно серьёзных проблем в репликации. Причём эта ситуация сохранялась на протяжении нескольких лет — как ни гляну в ChangeLog, так натыкаюсь на фиксы репликации.
Лично мне это говорит о том, что в репликации были, есть и будут баги, причём достаточно много и достаточно критичных. Я такие потенциальные «минные поля» в своём проекте без сильной нужды стараюсь не заводить.
Я прекрасно понимаю, что как-то репликация работает. На простых типовых запросах она даже, наверное, работает хорошо. Но баги там есть… И если репликацию использовать не в конкретном своём проекте (где Вы контролируете все SQL-запросы, и можете их подобрать так, чтобы на них реплика не глючила), а для бакапа всех баз на сервере, всех проектов — которые абсолютно без понятия что их будут реплицировать и которые могут использовать как раз те SQL-запросы, на которых реплика будет глючить — вероятность нарвать на баг в репликации сильно возрастает.
А, как чётко сказано в статье, я категорически против багов в процессе бакапа! Гарантировать отсутствие багов не может никто, но я любыми средствами стараюсь минимизировать вероятность столкнутся с багом.
Ну и последнее. Ситуации бывают разные, и подходы к бакапу должны это учитывать. Представьте себе базу данных, таблицы в которой не большие, но очень часто обновляющиеся. Например, накапливающие статистику по трафику: сетевых интерфейсов пара сотен, а UPDATE для них выполняется каждую секунду. В этом случае запаковать tar-ом эти таблицы можно за доли секунды, а поддержание репликации потребует нехилых ресурсов и заметно скажется на нагрузке сервера. Глубо выполнять сотню лишних UPDATE-ов в секунду вместо того, чтобы раз в сутки запаковать файл размером несколько мегабайт.
Конкретно-взятые случаи в рассмотрение не брались. Материал подаётся как универсальный подход. Ежу понятно, что делать репликацию ради таблицы в несколько килобайт вряд ли кто-то будет.
Баги есть везде, если их боятся, то можно совсем из дома не выходить. В MySQL очень много багов, не в репликации, а в целом.
Репликация в грубом приближении это когда два более-менее идентичных сервера один за другим выполняют запросы, в строгой последовательности изменяющие изначально идентичную базу. При любой ошибке на клиенте, репликация останавливается.
Ирония ситуации ещё и в том, что мы с вами читаем эту страницу с разных MySQL-серверов, связанных репликацией.
Баги есть везде, если их боятся, то можно совсем из дома не выходить. В MySQL очень много багов, не в репликации, а в целом.
Репликация в грубом приближении это когда два более-менее идентичных сервера один за другим выполняют запросы, в строгой последовательности изменяющие изначально идентичную базу. При любой ошибке на клиенте, репликация останавливается.
Ирония ситуации ещё и в том, что мы с вами читаем эту страницу с разных MySQL-серверов, связанных репликацией.
Материал подаётся как универсальный подход.Честно говоря, я никак не пойму, что именно Вам не понравилось:
— Статья с самого начала чётко декларирует, что подходы к бэкапу должны быть строго индивидуальны. Анализируйте мои сценарии и думайте, насколько мой подход актуален в Вашем случае.
— Предложенный механизм бакапа MySQL через FLUSH TABLES WITH READ LOCK + инкрементальный tar действительно можно назвать достаточно универсальным, и ничего плохого я в нём не вижу. В каких-то случаях это не будет оптимальным решением, но работать будет всегда.
— Про репликации я говорил только то, что там много багов — значительно больше, чем в tar! И с этим пока вроде никто не пытался спорить… На мой взгляд этот факт делает tar предпочтительным решением для бэкапа. Но, безусловно, есть ситуации, когда репликация будет предпочтительнее (например, если она у Вас уже используется). Хотя это относится, скорее, к сценарию бэкапа конкретного проекта, а не всего сервера (на котором установлено много разных, не использующих репликацию, проектов).
Объясните, пожалуйста, что здесь некорректно описано, в чём Вы усмотрели «псевдо-научные изыскания» [которым не место на хабре]?
сократить время блокирования проекта для бакапа до нескольких секунд
Например, задача бакапа базы перехватывает первый этап, чтобы заблокировать MySQL на время архивации файлов в /var/lib/mysql/
Процесс резервного копирования серьёзного проекта не должен блокировать его работоспособность ни на мгновение.
Резервное копирование данных интернет-проекта во многих случаях делится на три основные части:
— Исходный код. Изначально резервируется системой контроля версий
— Media-файлы. Хорошо резервируются с использованием rsync
— База, в нашем случае MySQL. Лучший способ прозрачного резервного копирования — снятие копий с клиента репликации.
Резервные копии файлов настройки можно сделать один раз самому или в случае аварии взять с аналогичных серверов.
Обратите внимание: если выполняется резеврное копирование с блокировкой базы, по вашему методу, скажем, раз в час, то в худшем случае теряется час жизни проекта, в добавок присутствуют никому ненужные замирания и ошибки, происходящие в момент блокировки.
Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.
> Репликация в большинстве случаев даст вам «живую» копию, актуальность которой датирована той же секундой, когда вышел из строя основной сервер.
А как быть если последние живые запросы — это были запросы хакера изменяющего базу?
Каким образом делать резервную копию с сервера репликации, чтобы иметь возможность восстановить основной сервер на заданную дату?
А как быть если последние живые запросы — это были запросы хакера изменяющего базу?
Каким образом делать резервную копию с сервера репликации, чтобы иметь возможность восстановить основной сервер на заданную дату?
где Вы контролируете все SQL-запросы, и можете их подобрать так, чтобы на них реплика не глючила)
Контролировать нужно не запросы, а пути их следования. То есть нужно просто-напросто один раз понять, что к чему и построить такую систему, которая снаружи будет как один сервер и не будет накладывать никаких ограничений на типы запросов и их содерание.
Например, нужно понимать, что write-запросы уходят на конкретные сервера, так что соотвествующие статусные значения с таблиц надо получать от них же, а не с клиентов репликации (например mysql_insert_id()).
Реплика не глючит, просто она имеет свои ограничение. Как-то работа с автоинкремент полями, NOW(), UUID() и переменными в запросах. Полностью все описано, как ни странно, в документации на mysql.com. В 5.1 достен другой вид репликации, при котором реплицируются не запросы, а изменение данных в таблице.
>> А при попытке восстановить базу из log-bin могут всплыть самые разные грабли.
Из log-bin ничего восстанавливать не надо. Такое ощущение, что вы все таки не до конца понимаете, как работает репликация.
Сначала берутся два сервера, мастер и слейв, на них создается идентичная база данных (с мастер-сервера копируется на слейв)
Мастер сохраняет все запросы, которые изменяют его базу в бинлог. Слейв забирает эти логи, и выполняет все эти запросы у себя. Таким образом база поддерживается в синхронном состоянии на двух серверах. После синхронизации бинлог никому не нужен, и обычно удаляется через какой то таймаут, 3 дня например. 3 дня нужно для того, чтобы если реплика или соединение будет «лежать» день, после устранения проблем можно было догнать мастер-сервер.
А бэкап в такой схеме делается просто. Слейв стопится, при этом проект продолжает работать. Реплика бэкапится любыми удобными средствами(можно и вашим софтом), стартует заново, после чего через некоторое время догоняет мастера. Эта схема проста и отработана годами и используется очень много где.
Из log-bin ничего восстанавливать не надо. Такое ощущение, что вы все таки не до конца понимаете, как работает репликация.
Сначала берутся два сервера, мастер и слейв, на них создается идентичная база данных (с мастер-сервера копируется на слейв)
Мастер сохраняет все запросы, которые изменяют его базу в бинлог. Слейв забирает эти логи, и выполняет все эти запросы у себя. Таким образом база поддерживается в синхронном состоянии на двух серверах. После синхронизации бинлог никому не нужен, и обычно удаляется через какой то таймаут, 3 дня например. 3 дня нужно для того, чтобы если реплика или соединение будет «лежать» день, после устранения проблем можно было догнать мастер-сервер.
А бэкап в такой схеме делается просто. Слейв стопится, при этом проект продолжает работать. Реплика бэкапится любыми удобными средствами(можно и вашим софтом), стартует заново, после чего через некоторое время догоняет мастера. Эта схема проста и отработана годами и используется очень много где.
Из log-bin ничего восстанавливать не надо. Такое ощущение, что вы все таки не до конца понимаете, как работает репликация.Я просто говорил о другой ситуации — когда MySQL сервер один, никаких slave-ов нет. И log-bin на этом сервере включается исключительно с целью бэкапить эти логи вместо самой базы — ведь во многих случаях они будут занимать меньше места, для их бэкапа не потребуется лочить MySQL, и их очень просто бэкапить инкрементально. А при необходимости восстановить базу из бэкапа — воспользоваться для этого этими логами. (Насколько я понимаю, в принципе можно даже отконвертировать log-bin в обычный .sql-файл.)
Ну тогда простите, но я совсем потерялся в ваших мыслях :)
Вы пишете, что реплика глючит, что пробовали и что то не получалось, при этом оказывается что вы вообще о другом совсем говорите, к репликации никакого отношения не имеющем (ибо сохранение бинлогов с целью по ним поднять потом базу — это никакая не репликация вовсе, более того, я первый раз слышу про такую затею, хотя и допускаю что такая схема возможна)
С таким взаимопониманием, мне даже как то не хочется спрашивать у вас почему у вас «из системы контроля версий можно вытащить только базовую версию проекта» (а для чего тогда вам вообще SVN(или то что у вас)).
Вы пишете, что реплика глючит, что пробовали и что то не получалось, при этом оказывается что вы вообще о другом совсем говорите, к репликации никакого отношения не имеющем (ибо сохранение бинлогов с целью по ним поднять потом базу — это никакая не репликация вовсе, более того, я первый раз слышу про такую затею, хотя и допускаю что такая схема возможна)
С таким взаимопониманием, мне даже как то не хочется спрашивать у вас почему у вас «из системы контроля версий можно вытащить только базовую версию проекта» (а для чего тогда вам вообще SVN(или то что у вас)).
Использую opennet.ru/fsbackup для инкрементного удаленного бэкапа. Сливаю бэкапы с веб-серверов на офисный бэкап-сервер, у меня 5 серверов (включая внутренние) так работает, пока доволен.
powerman, отлично, думаю стоит рассмотреть эффективность этой системы.
Кстати, почему сайт только на английском? Отпугнёт многих потенциальных пользователей.
Кстати, почему сайт только на английском? Отпугнёт многих потенциальных пользователей.
Ну, часть сайта на русском…
Сайт на английском (точнее, на том, что я называю английским :)) потому, что:
— я всё-таки фрилансер, и мне нужно что-то показывать англоязычным клиентам
— я чаще общаюсь на IT-темы в англоязычных maillist-ах, и мне нужна возможность давать там ссылки на сайт
— русские программеры/админы технический английский как правило знают
Сайт на английском (точнее, на том, что я называю английским :)) потому, что:
— я всё-таки фрилансер, и мне нужно что-то показывать англоязычным клиентам
— я чаще общаюсь на IT-темы в англоязычных maillist-ах, и мне нужна возможность давать там ссылки на сайт
— русские программеры/админы технический английский как правило знают
Всё-таки там не так много информации чтобы сделать и русскую версию :) и возможно, у вас появятся и русские клиенты Ж-)
Похоже они действуют по принципу «Хочешь жить, умей вертеться» но не в самый удачный способ
У меня самописный скрипт.
#!/bin/sh
# Описываем базовые директории
BACKUP="/srv/backup/"
TEMP="/srv/backup/temp" #Папка удаляется после выполнения скрипта !
PREFIX=`hostname -s`_`date +%d.%m.%y-%H:%M`
# Описываем папки backupов
# Файлы системы
ETC="$TEMP/etc/"
# Файлы сервера
WWW="$TEMP/www/"
VMAIL="$TEMP/vmail/"
MYSQL="$TEMP/mysql/"
# Создаем необходимые папки
mkdir $TEMP
#mkdir $ETC
mkdir $WWW
mkdir $VMAIL
mkdir $MYSQL
# Копируем файлы в созданые папки
#cp -r /etc/ $ETC
cp -r /srv/www/www.*.ru/ $WWW
cp -r /srv/www/mail.*.ru/ $WWW
cp -r /srv/www/workflow.*.ru/ $WWW
cp -r /srv/vmail/* $VMAIL
# Бэкапим mysql базы
mysqldump -ubackup -P3306 -hlocalhost -p[pass] mail > $MYSQL/mail.sql
mysqldump -ubackup -P3306 -hlocalhost -p[pass] webmail > $MYSQL/webmail.sql
# Переходим в каталог с копиями
cd $TEMP
# Создаем архив
tar -czvf /srv/backup/data/$PREFIX.tar.gz *
# Очищаем папку temp
rm -rf $TEMPПросвятите идиота, почему у вас бэкапы лежат в srv (я их храню в var и, возможно, делаю неправильно)
Просто я привык все сервисы, предоставляемые сервером, размещать в /srv/.
+ это обычно отдельная партиция.
+ централизованное размещение проще при передаче управления сервером другому лицу.
+ Создаем пользователя, который периодически по ssh или smb коннектится с другой тачки и забирает все содержимое домашней папки себе на ЖД.
Тоесть это лично мои предпочтения.
+ это обычно отдельная партиция.
+ централизованное размещение проще при передаче управления сервером другому лицу.
+ Создаем пользователя, который периодически по ssh или smb коннектится с другой тачки и забирает все содержимое домашней папки себе на ЖД.
Тоесть это лично мои предпочтения.
думаю вы делаете правильно. главное чтобы они были на другом физическом диске. :)
Не занудства ради, а исключительно для изложения моих мыслей на эту тему лично я бы еще как минимум:
1) d-m-y заменил бы на y-m-d для удобства сортировки в файловой системе;
2) вместо
3) на пайп от
4) соответственно, в
5) проверял коды ошибок, возвращаемые в процессе работы скрипта;
6) сохранял бы в каком-нибудь виде протокол его работы.
… О, еще чуть не забыл добавить:
7) подумал бы, а зачем предварительно перед тем, как запускать tar, делать дубликат www-серверов? То есть
1) d-m-y заменил бы на y-m-d для удобства сортировки в файловой системе;
2) вместо
cp -r писал cp -rp;3) на пайп от
mysqldump я бы еще натравил bzip2;4) соответственно, в
tar вместо -z я бы писал -y (-j);5) проверял коды ошибок, возвращаемые в процессе работы скрипта;
6) сохранял бы в каком-нибудь виде протокол его работы.
… О, еще чуть не забыл добавить:
7) подумал бы, а зачем предварительно перед тем, как запускать tar, делать дубликат www-серверов? То есть
tar напускал бы сразу на оригинал.
Все базы можно забэкапить так
# чистим старые
/usr/bin/find $dstdir -atime +10 -delete
# список дб
databases=`echo «show databases»|/usr/local/bin/mysql ${mysqlparam}|grep -v "^D"`
fname=`date "+%Y-%m-%d`
# архивируем
for FLS in ${databases}
do
${mysqldump} ${mysqlparam} ${FLS}| ${bzip2} -c -9 > ${dstdir}/${FLS}-${fname}.sql.bz2
done
# чистим старые
/usr/bin/find $dstdir -atime +10 -delete
# список дб
databases=`echo «show databases»|/usr/local/bin/mysql ${mysqlparam}|grep -v "^D"`
fname=`date "+%Y-%m-%d`
# архивируем
for FLS in ${databases}
do
${mysqldump} ${mysqlparam} ${FLS}| ${bzip2} -c -9 > ${dstdir}/${FLS}-${fname}.sql.bz2
done
Я бы не рекомендовал использовать такие скрипты. Во-первых, база не лочится. Во-вторых есть race condition между получением списка баз и их архивацией. В-третьих bzip2 тормозит, bzip2 -9 ужасно тормозит, а поскольку он соединён пайпом с mysqldump, то bzip2 будет тормозить mysqldump. В-четвёртых сам mysqldump тоже тормозит, особенно по сравнению с инкрементальным tar-ом.
Впрочем, как я упоминал в начале статьи, разные ситуации требуют разных подходов к бэкапу. Если у вас база маленькая и стоит на домашней однопользовательской workstation — этот скрипт будет работать как часы и ничего более навороченного не нужно.
Впрочем, как я упоминал в начале статьи, разные ситуации требуют разных подходов к бэкапу. Если у вас база маленькая и стоит на домашней однопользовательской workstation — этот скрипт будет работать как часы и ничего более навороченного не нужно.
Кстати, в скрипте таки фигурирует слово «бэкапим», а не «бакапим». ;)
Я некоторое время колебался, как его писать. Дело в том, что в русской википедии есть и Бекап и Бэкап, а все окружающие меня IT-шники всю жизнь произносили это как Бакап. Ещё рассматривался вариант оставить английский вариант, но он плохо склоняется и рвёт текст. :) В конце концов решил писать, как привык. Иначе в тексте были бы и бекап, и бакап и бэкап одновременно.
А вообще это фигня по сравнению с шоком, который я испытал, узнав что весь цивилизованный мир слово parser пишет как парсер, а не парзер, как я привык. Теперь вот переучиваюсь и правлю документацию… :)
А вообще это фигня по сравнению с шоком, который я испытал, узнав что весь цивилизованный мир слово parser пишет как парсер, а не парзер, как я привык. Теперь вот переучиваюсь и правлю документацию… :)
Real men don't do backups, they just put their work on an FTP site and let the world mirror it.
© Linus Torvalds
:)
© Linus Torvalds
:)
rdiff-backup
MySQL не умеет создавать копии «живой» базы? Почему не FireBird?
было бы интересно прочитать не только про бакап серверов, но и про стратегии бакапа рабочих станций.
Кстати, недвно нужна была софтинка (желательно портабельная) для автоматизации бэкапа. Ничего бесплатного не нашёл. Либо монстры требующие MySQL + Perl + Apache + настройка. Либо совсем примитивне решения. Раньше использовал rar + примитивный скрипт — умел далесть всё, что нужнос огромной скоростью. Но потом раскаялся и стал искать что-нибудь более бесплатное — нетуть.
Откройте для себя снапшоты (LVM, ZFS). Как делать бэкап MySQL я описывал тут
http://habrahabr.ru/blogs/habraworks/40255/#comment_975194
Тот же функционал и гораздо больший можно получить использованием rdiff-backup как тут уже писали.
http://habrahabr.ru/blogs/habraworks/40255/#comment_975194
Тот же функционал и гораздо больший можно получить использованием rdiff-backup как тут уже писали.
Мне кажется, есть несколько вариантов подхода:
1) лочим mysql, делаем LVM снапшот, разлочиваем. Снапшот бэкапим как-то.
2) лочим mysql, nginx и postfix останавливаем, делаем бэкап файловой системы, всё запускаем обратно.
3) делаем копию баз mysql с помощью mysqlhotcopy или какой-то другой дамп, делаем бэкап системы и баз.
Второй случай приводит систему в более-менее стабильное состояние. Первый — в менее стабильное но самый малопростойный, третий — состояние системы вообще нестабильное, но самый простой.
Бэкап можно делать разными способами, но мне кажется, лучшие варианты:
1) dar
2) rdiff-backup
dar — продвинутая версия tar, делает инкрементальные бэкапы, причём первую копию можно удалить, оставив от неё только метаинформацию. Сохраняет файлы с атрибутами в файлах заданного размера — например, чтобы на CD можно было записать. Пример использования — делаем первый бэкап, вытаскиваем метоинформацию, бэкап отправляем на FTP — много-много гигабайт, при следующих бэкапах используем метаинформацию как источник знаний о изменившихся файлах и отправляем на FTP инкрементальные копии. Достоинство — на локальной машине нет полной первой копии.
rdiff-backup — фактически система контроля версий. Недостаток — много файлов (сколько было плюс инкрементальные копии). Достоинство — иногда интересное — права на файлы хранит не только в виде идентификаторов пользователей, но и имён пользователей, при восстановлении в системе с другими идентификаторами права установятся на, например, www-data правильно. Ну и умеет работать с удалёнными архивами по ssh, что, правда, не очень полезно из-за возможных ошибок связи. Вариант использования — сделать первый бэкап на локальной машине, rsync'ом отправить на удалённую машину, стереть локальную копию и дальше работать только с удалённой. Ошибки связи могут быть, но инкрементальные копии делаются быстро. И директорию, которую строит rdiff-backup, трудно записать на носители.
1) лочим mysql, делаем LVM снапшот, разлочиваем. Снапшот бэкапим как-то.
2) лочим mysql, nginx и postfix останавливаем, делаем бэкап файловой системы, всё запускаем обратно.
3) делаем копию баз mysql с помощью mysqlhotcopy или какой-то другой дамп, делаем бэкап системы и баз.
Второй случай приводит систему в более-менее стабильное состояние. Первый — в менее стабильное но самый малопростойный, третий — состояние системы вообще нестабильное, но самый простой.
Бэкап можно делать разными способами, но мне кажется, лучшие варианты:
1) dar
2) rdiff-backup
dar — продвинутая версия tar, делает инкрементальные бэкапы, причём первую копию можно удалить, оставив от неё только метаинформацию. Сохраняет файлы с атрибутами в файлах заданного размера — например, чтобы на CD можно было записать. Пример использования — делаем первый бэкап, вытаскиваем метоинформацию, бэкап отправляем на FTP — много-много гигабайт, при следующих бэкапах используем метаинформацию как источник знаний о изменившихся файлах и отправляем на FTP инкрементальные копии. Достоинство — на локальной машине нет полной первой копии.
rdiff-backup — фактически система контроля версий. Недостаток — много файлов (сколько было плюс инкрементальные копии). Достоинство — иногда интересное — права на файлы хранит не только в виде идентификаторов пользователей, но и имён пользователей, при восстановлении в системе с другими идентификаторами права установятся на, например, www-data правильно. Ну и умеет работать с удалёнными архивами по ssh, что, правда, не очень полезно из-за возможных ошибок связи. Вариант использования — сделать первый бэкап на локальной машине, rsync'ом отправить на удалённую машину, стереть локальную копию и дальше работать только с удалённой. Ошибки связи могут быть, но инкрементальные копии делаются быстро. И директорию, которую строит rdiff-backup, трудно записать на носители.
2) лочим mysql, nginx и postfix останавливаемЭтот способ хорош если у Вас сервисы избыточные — т. е. после остановки nginx на первом сервере ваш сайт продолжит поддерживать в рабочем состоянии второй сервер. И наоборот при бэкапе второго сервера.
dar — продвинутая версия tar, делает инкрементальные бэкапы, причём первую копию можно удалить, оставив от неё только метаинформацию.tar это тоже умеет. Собственно, именно таким образом я его и использую.
Есть хорошая статья, описывающая проблемы разных программ создания резервных копий — www.halfgaar.net/backing-up-unix. Проблемы примерно такие: анализ ctime/mtime/atime, работа с дырявыми файлами, с хардлинками, сохранение прав доступа в символьном и числовом виде, обнаружение изменений в файловой системе, работа с файлами и архивами >4G. Никаких открытий в статье нет, но всё собрано в одном месте и проанализировны эти проблемы для tar, dar, rdiff-backup, rsync, cp.
Спасибо, статья (у Вас ссылка битая) действительно отличная!
good, reliable backups require forethought, effort and planningИ я о том же. Если бэкапить не особо вникая что и как — можно оказаться у разбитого (или, как минимум, серьёзно треснувшего) корыта после восстановления их таких бэкапов.
A backup is more than dataIMHO необходимость поддержки разнообразных расширенных атрибутов и дырявых (sparse) файлов зависит от конкретных условий. Например, я использую расширенные атрибуты только для пометки самих бэкапов неизменяемыми (immutable), ACL вообще нет, а дырявые файлы делают только p2p-качалки — в таких условиях поддержка этих метаданных не нужна.
I recommend you stay away from tar.Я думаю, с этой рекомендацией он погорячился. Фактически его претензии к tar сводятся к необходимости указывать параметр -p при восстановлении бэкапа. Совет использовать --numeric-owner на самом деле корректен только при условии восстановления бэкапа полной системы, а для восстановления отдельных частей (база MySQL, например) да ещё и на другой системе это абсолютно некорректно.
Ну к tar ещё одна серьёзная претензия — он не делит файлы на куски, а при нынешних размерах это совершенно нелишняя функциональность. Кроме того, при инкрементальном бэкапе tar что-то уж очень подозрительно мало данных хранит о файлах. Ещё одно отличие от dar — dar хранит в архиве упакованные версии файлов, в отличии от tar.gz, то есть добраться до отдельного файла в случае с dar гораздо проще.
Не хотел углубляться в философию, но Вы мне не оставляете выбора. :) Автор статьи ещё не избавился от некоторых детских проблем. С одной стороны, он уже понял чем качественный подход отличается от среднего-общепринятого подхода и перестал слепо доверять софту. С другой, он ещё не понял, что качественно работать может только простой софт… и чем он проще, тем он меньше глючит. Поэтому ему очень хочется и чтобы качественно, и чтобы можно было одну программу запустить (желательно — без особых параметров), и чтобы она «сделала ему красиво». К сожалению, так не бывает. И даже если изредка встречается сложный комбайн, который не глючит — это исключение, подтверждающее правило.
Я не люблю комбайны. Меня вполне устраивает не только то, что tar не разбивает файлы, но и то, что он их не сжимает (точнее, не сжимал раньше, но и сейчас эта фича, к счастью, опциональна). Поэтому если нужно разбить по томам — я лучше вывод tar направлю в утилиту, которая умеет делать только это. Зашифровать — аналогично.
Кроме того, я в таких критических задачах как бэкап предпочитаю консервативные, проверенные десятилетиями решения, а не активно развивающийся софт. Это же не браузер!
P.S. Что касается возможности «проще» достать из архива отдельный файл — у меня необходимость в этом возникает раз в 3-4 года, поэтому необходимости упрощать эту операцию просто нет. А если кто-то это делает регулярно — возможно ему стоит начать использовать какую-нить систему контроля версий файлов.
Я не люблю комбайны. Меня вполне устраивает не только то, что tar не разбивает файлы, но и то, что он их не сжимает (точнее, не сжимал раньше, но и сейчас эта фича, к счастью, опциональна). Поэтому если нужно разбить по томам — я лучше вывод tar направлю в утилиту, которая умеет делать только это. Зашифровать — аналогично.
Кроме того, я в таких критических задачах как бэкап предпочитаю консервативные, проверенные десятилетиями решения, а не активно развивающийся софт. Это же не браузер!
P.S. Что касается возможности «проще» достать из архива отдельный файл — у меня необходимость в этом возникает раз в 3-4 года, поэтому необходимости упрощать эту операцию просто нет. А если кто-то это делает регулярно — возможно ему стоит начать использовать какую-нить систему контроля версий файлов.
Я просто написал скрипт, который архивирует все данные, не поддающиеся восстановлению (~250M), в .tar.lzma, запускаю его раз в месяц и результат сохраняю на двух-трёх носителях. Всё.
В своё время у нас было много копий поломано по этому поводу. Единственно, что DBMS была не MySQL, a ORACLE. Естественно не в фаликах, а «по-взрослому» :))), на raw-devices. Ну и бэкапили на плёнку. Чего и вам всем советую. На всякий случай оргньюанс: кассетки должно быть 3 штука: бабушка, мама и текущая. После бэкапа кассетки — в сейф, размещённый за пределами серверной, лучше за пределами здания. :)
После плясок с бубнами различного диаметра, цвета и звука, пришли к следующему:
— еженощно останавливать Оракл и сливать дидёй (dd) raw-девайсы в бэкап, на плёнку (кстати, восстанавливается на ура — быстно и весело)
— экспорт Ораклу делать раз в 2-3 дня (зависит от объёма предполагаемых работ ночером на сервере), это правильно с точки зрения контроля целостности того, чего сливается дидёй.
Кроме того (но это уже не совсем бэкап :)) ), все ФС и те же raw-девайсы rsync-ались на два зеркальных сервера, «боевой» Оракл выкладывал аркайвлоги по мере накопления транзакций, эти логи тоже rsync-ались каждые 5 минут.
По поводу утаптывания бэкапа gzip и иже. А надо? Подумайте о том, сколько лишнего драгоценного времени нужно будет потратить на раскрутку бэкапа в тот момент, когда времени просто не будет хватать. ИМХО дешевле купить пару быстрых стриммеров (скорости и объёмы растут, на вскидку: четветь тера в час на почти теровую кассету), десяток кассет, + построить зеркальный серверок, желательно в территориально удалённой серверной, нежели потерять данные.
После плясок с бубнами различного диаметра, цвета и звука, пришли к следующему:
— еженощно останавливать Оракл и сливать дидёй (dd) raw-девайсы в бэкап, на плёнку (кстати, восстанавливается на ура — быстно и весело)
— экспорт Ораклу делать раз в 2-3 дня (зависит от объёма предполагаемых работ ночером на сервере), это правильно с точки зрения контроля целостности того, чего сливается дидёй.
Кроме того (но это уже не совсем бэкап :)) ), все ФС и те же raw-девайсы rsync-ались на два зеркальных сервера, «боевой» Оракл выкладывал аркайвлоги по мере накопления транзакций, эти логи тоже rsync-ались каждые 5 минут.
По поводу утаптывания бэкапа gzip и иже. А надо? Подумайте о том, сколько лишнего драгоценного времени нужно будет потратить на раскрутку бэкапа в тот момент, когда времени просто не будет хватать. ИМХО дешевле купить пару быстрых стриммеров (скорости и объёмы растут, на вскидку: четветь тера в час на почти теровую кассету), десяток кассет, + построить зеркальный серверок, желательно в территориально удалённой серверной, нежели потерять данные.
Спасибо за скрипт, возможно когданит пригодится. Сам я пользуюсь Bacula
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Backup — дело тонкое