Как лучше делать бэкапы больших объёмов?

Объёмы от 100Gb. Если тупо делать mysqldump всех таблиц и tar всех файлов, то это занимает несколько часов, за которые сервак фактически лежит. Плюс забитый канал на время пересылки архивов в S3.

Есть ли более умные способы?

Mysqldump + Incremental Backup c помощью Duplicity

Тут подробно: http://blog.damontimm.com/bash-script-incremental-encrypted-backups…amazon-s3/


ну или не заморачиваться и платить отдельному сервису за rsync backup на S3 http://www.s3rsync.com/

Во-первых, надо настроить отдельный слейв mysql сервер. И делать бекап с него.

Во-вторых, mysqldump на таких объемах не эффективен. Надо лочить таблицы на запись (FLUSH TABLES WITH READ LOCK), снимать LVM-снепшот тома с таблицами, отпускать таблицы (UNLOCK TABLES). Дальше база продолжает работать, а бекапишь ты уже снапшот раздела с таблицами с помощью обычного dump.

Ну и постепенно дамп на S3 загонять. Или куда поближе.

Pentarh писал:

отдельный слейв mysql сервер

А на репликации не будет серьёзных потерь в производительности?
И как быть с файлами контента? rsync, csync, или что-то принципиально другое?

Спасибо за советы!

Оч геморойно настроить репликацию. Особенно на таком объеме. Но проблем с производительностью на главном сервере репликация не вызовет. А на слейве пох. Пусть хоть ложится. Главное чтобы читал бинарные логи с мастера.

В принципе могу помочь не за спасибо если что.

Sanman писал:

Mysqldump + Incremental Backup c помощью Duplicity

Саныч, инкрементальный бекап на таких объемах mysqldump не имеет смысла. Один и тот же контент будет копироваться в полном объеме.

А вот если дампать LVM снепшот тома обычным dump'ом, то там инкрементальный бекап (самого dump'а) в принципе может снизить нагрузку на канал.

Последний раз редактировалось: Pentarh (18/11/12 в 20:15), всего редактировалось 1 раз

Pentarh: ТС же не говорил, что базы у него от 100 гиг, весь контент на сервере, как я понял Вот файлы до 5гиг( ограничение S3) отлично синкаться инкрементально смогут

Последний раз редактировалось: A.Brain (18/11/12 в 20:17), всего редактировалось 1 раз

А на "как быть с файлами контента" ничего не ответил

Ну окей, если своими руками не получится - обращусь к тебе на коммерческой основе

А, еп. Я чето подумал 100 терабайт. Ну ладно. 100 гиг в принципе можно снимать mysqldump. Но со слейва.

Вот тут у меня описание и скрипт бекапа со снапшота.

http://www.pentarh.com/wp/2010/08/12/mysql-remote-encrypted-backup-lvm-snapshot/

Основной гемор - настроить слейв теперь.

Залип в блоге на полчаса

Парни, ну скажите как лучше файлы бэкапить, я же теперь мучаться буду пока не узнаю рецепт. Rsync на больших объёмах нахрен нагрузит либо канал, либо проц. Как иначе?

ну дампом опять же

рсинк не грузит проц, он грузит винт

а это. я вроде читал что при определенных обстоятельствах можно сами файлы баз бекапить. при условии что инсерт\апдейт туда не ведется в этот момент.

FXIX писал:

сами файлы баз бекапить

Это же всё равно слейв городить, на продакшене ведь их не заморозишь.

FXIX писал:

а это. я вроде читал что при определенных обстоятельствах можно сами файлы баз бекапить. при условии что инсерт\апдейт туда не ведется в этот момент.

Гарантию отсутствия записи и сброса кеша дает запрос "flush tables with read lock".

Потом делаем снепшот раздела с базами. Конечно же базы должны располагаться на выделенном LVM разделе.

Снепшот снимает мгновенный снимок раздела и замораживает его. Снепшот LVM раздела делается за несколько секунд.

Потом отпускаем запросы инсерт, апдейт запросом "unlock tables". Запись в базу пошла опять.

Но снятый снепшот сохранил раздел с базами в состоянии на момент снятия лока баз.

И теперь этот снепшот можно:
1) замонтировать куда то, забекапить отдельные файлы
2) снять с него бекап без монтирования утилитой dump полным или инкрементальным бекапом.

Обращаю внимание. Если бекапаются таблицы InnoDB, нужно бекапать еще и my.cnf! Т.к. там есть настройки размера и положения лог файлов инны. При других настройках в процедуре восстановления файлов, инна раскапризничается.

Последний раз редактировалось: Pentarh (18/11/12 в 22:38), всего редактировалось 1 раз

DG писал:

Это же всё равно слейв городить, на продакшене ведь их не заморозишь.

да просто настрой слейв. это и будет тебе бекап. в первый раз слейв будет медленно заливаться. потом быстрее.

слейв же тупо операционные логи мастера читает. строки вида "INSERT что-то", "DELETE что-то", "UPDATE что-то" и у себя на исполнение запускает. короче бежит за мастером.

вот раз в неделю слейв запускай да и все. и не надо со 100гиговыми дампами прыгать.

по крайней мере в мане так суть репликации описана. вживую не трогал

Ну если не десятки гигабайт, можно и просто снепшотом бекапать.

Там лок таблиц включается на несколько секунд. Нагрузка на винт правда будет в процессе бекапа.

Если нагрузка на винт представляет угрозу стабильности, тогда надо городить слейв.

Лично я подошел с другой стороны - просто не храню миллион файлов на сервере, а заливаю их в облачное хранилище по типу S3 и никакого гемороя с резервным копированием.
А база реплицируется на другой сервер с задержкой в час и в случае если какая проблема или сам накосячил, то переключаюсь на второй сервер и все. Не спрашивайте как это, база не MySQL

iRoot писал:

заливаю их в облачное хранилище по типу S3

А вот с этого места поподробнее. Какое именно облачное хранилише? S3 вроде не любит адалт.

Мне интересно как их потом с S3 раздавать... Ну хотя бы на полтинике мегабит. Квартиру продашь нафиг )

DG: пока хостился там он не возразил ни разу, все было в порядке
Pentarh: а цена да, кусается. Пока трафика было мало все было супер, когда стало больше, то переехал в другое место. Но там целая история получилась - сперва нашел сервис с совместимым API, т.е. все что нужно было - это перекачать данные и поменять в настройках сервер и все. Но этот новый сервис оказался тормознутым, общение с поддержкой результата не дало, помыкался я еще немного и в итоге реализовали свое хранилище с совместимым S3 API, оказалось не сложно. Поставил это все дело на Hetzner сервера и остался очень доволен.
Предлагал даже поделиться кому надо - места полно, трафика тоже, будет мало поставлю еще сервер, система масштабируется горизонтально, но никто пока не ответил. Так что если кому надо - обращайтесь, договоримся.

Чтоб цена не кусалась, надо юзать правильные цдн

Pentarh: Советуй уж тогда правильные цдны

Вот я сейчас тестирую, насколько правильный CDN от Диамонда CDN решение для ваших сайтов. Free - тест!

diamond, advanced hosters