Вопрос про backup ЮТМ

[spiderman]

Привет всем.
У меня такая проблема.
В файле utm5_backup.sh написано:
backup_path=/netup/utm5/backup
что нужно писать, чтобы backup был сделан не на том компьютере в катором установлен UTM а на компьютере скажем с IP адресом 1.1.1.1.
Спосибо

[Andriuxa]

Я бы поднял на конечной машине самбу и открыл дирректорию для записи (скажем только для определенного ипа) и в строке бекапа поварьировал с smbclient.

[mikkey finn]

поставить на нужном компе mysql-client. Создать в базе юзера, которому разрешить бекапить данные, запускать скрипт с правильным юзером/паролем/адресом сервера на нужном компе.
По-моему так.

[SOLDIER]

Да можно и rsync присобачить, NFS - решений много. Скрипт, разумеется, надо переделать при этом.

[Magnum72]

Да можно и rsync присобачить, NFS - решений много. Скрипт, разумеется, надо переделать при этом.

Давайте начнем из далека:
Бекап биллинга вообще нельзя делать с рабочего сервера баз данных, 99% поблем в биллинге происходят именно из-за этого по причинам:
1) нарушения логической целостности из-за залочивани таблицы во время бекапа
2) нарушения логической целостности из-за того что бекапируются поочередно, следовательно пока бекапим одну таблицу, потом вторую, данные в этих таблицах перестают быть синхронныи, живой пример транзакшин* таблицы.

Я на месте разработчиков вообще бы в скрипте бекапа написал бы большими буквами это.

Теперь как правильно бекапить:
1) Поднимаем Slave Mysql сервер, и миррорим на него нужные базы (почему базы во множественном числе, потому что настоятельно рекомендую внедрить механизам архивирования таблиц и архивировать их с соседнбб юазу на этом сервере, это позволит уменьшить и время бекапа и позволит избавиться от многократного дублирования данных при каждом бекапе).
2) В момент бекапа (рекомендую 4 утра так как в этот момент активность юзеров практически отсутствует) останавливаем репликацию и бекапим таблицы горячим копированием т.е. тупо копируем файлы,
а) Естественно держим таблицы на бекапном сервере в формате myisam, для того чтобы собственно была возможность горячего копирования, во вторых чтобы можно было из бекапа достать нужную таблицу при надобности, а не восстанавливать все.
б) по поводу горячего копирования, это лучший способ быстро забекапить и быстро восстановить... 10 минут на все максимум.

ЗЫ рекомендую на слейве вести логирование, это позволит восстановить базу данных из бекапа и актуализировать данные на момент начала работ по восстановлению, даже в том случае если вы случайно на мастере сделаете дропдатабайз утм5

[Siny]

остановить коллекторы и закрыть внешние платежи, вообще доступы в урфу, если есть, в начале файла utm5_backup.sh, в конце соотв все запустить/открыть снова и можно с рабочей базы безболезненно ... вроде бы как
информация о трафике только канет в лета на время бэкапа ... в теже 4 часа ночи на несколько минут, в зависимости от запущенности базы
потом скриптом по sftp, к примеру, складировать на другой сервер архивы ... хоть себе по почте слать

а если по вопросу то нужно ключ -h какойнитьхост добавить в этот скрипт к mysqldump и можно будет его запускать на другом сервере (где естественно должен быть клиент мускула) ну и юзера в мускуле завести для этого дела

[JAO]

Хм. Я один раз сделал дамп с работающего биллинга, так его весьма перекосило, хотя выжил. После этого поднял репликацию. Но там я не копированием снимаю, а дампом, естественно при остановленной репликации. В целом по шагам так - остановка репликации, снятие дампа, запуск репликации, архивация дампа.

[Magnum72]

остановить коллекторы и закрыть внешние платежи, вообще доступы в урфу, если есть, в начале файла utm5_backup.sh, в конце соотв все запустить/открыть снова и можно с рабочей базы безболезненно ... вроде бы как
информация о трафике только канет в лета на время бэкапа ... в теже 4 часа ночи на несколько минут, в зависимости от запущенности базы
потом скриптом по sftp, к примеру, складировать на другой сервер архивы ... хоть себе по почте слать

а если по вопросу то нужно ключ -h какойнитьхост добавить в этот скрипт к mysqldump и можно будет его запускать на другом сервере (где естественно должен быть клиент мускула) ну и юзера в мускуле завести для этого дела

Ну например начал бекап с основной базы
забекапил табличку accounts
в это время биллинг кого то заблокировал
скрипт бекапа дошел до таблички block_info и забекапал ее.

В итоге: при поднятии из бекапа по информации из аккаунтов юзер будет не заблокирован, а в таблице block_info будет светится блокировка

[Siny]

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

[bazalt]

а) Естественно держим таблицы на бекапном сервере в формате myisam, для того чтобы собственно была возможность горячего копирования, во вторых чтобы можно было из бекапа достать нужную таблицу при надобности, а не восстанавливать все.
б) по поводу горячего копирования, это лучший способ быстро забекапить и быстро восстановить... 10 минут на все максимум.

Вопрос по пункту а), подпункту во-первых): при InnoDB нельзя разве скопировать целиком папку data + ibdata + ib_logfile? Сейчас размеры дисков позволяют держать бэкапы за пару-тройку мес. даже не сжатыми.

Собираюсь настраивать репликацию, и вот этот пункт заинтересовал. При простом переносе базы (+ibdata) на другой сервер всё же работает. Или всё-таки лучше в MyISAM?

[Magnum72]

а) Естественно держим таблицы на бекапном сервере в формате myisam, для того чтобы собственно была возможность горячего копирования, во вторых чтобы можно было из бекапа достать нужную таблицу при надобности, а не восстанавливать все.
б) по поводу горячего копирования, это лучший способ быстро забекапить и быстро восстановить... 10 минут на все максимум.

Вопрос по пункту а), подпункту во-первых): при InnoDB нельзя разве скопировать целиком папку data + ibdata + ib_logfile? Сейчас размеры дисков позволяют держать бэкапы за пару-тройку мес. даже не сжатыми.

Собираюсь настраивать репликацию, и вот этот пункт заинтересовал. При простом переносе базы (+ibdata) на другой сервер всё же работает. Или всё-таки лучше в MyISAM?

Сколько времени то уже прошло Уже появились перконы и марии с возможностью горячего бекапа иннодб таблиц. поэтому поставь хотя бы на слейв перкону и бекапь спокойно.

[bazalt]

Magnum72, как всегда, огромное спасибо. Пойду изучать.

[Magnum72]

Я думаю тут достаточно интересно описано:
http://habrahabr.ru/post/137380/

А вообще я хочу вот это попробовать с биллингом:
http://habrahabr.ru/post/152969/

[serg2k]

Уважаемый Magnum72,

у меня возникла та же мысль, что и у Siny, что вы думаете о бакапировании на основном сервере с остановкой всех сервисов биллинга?
Ведь действительно, 5 минут в 5 утра погоды не сделают для большинства некрупных провайдеров.

[JAO]

Я работаю у некрупного провайдера. Считаю, что остановки биллинга не должны быть регулярными, а тем более ежесуточными. Бэкап базы - не повод для остановки, даже на пять минут. Просто некрупные провайдеры иногда становятся крупными, и тогда придется всё это веселье переделывать. А зачем, если можно сразу сделать как надо?