чем можно сделать бэкап Mysql из ssh

Для начала поэксперементируй с опциями дампа - найди причину «затупов».

В чём выражаются затупы?

А так, я ещё использую помимо mysqldump'а bacula, но там бекап не только мускля.

Если бинарные логи транзакций хранятся с самого начала и в полном виде, то можно делать их бекапы.

http://www.percona.com/software/percona-xtrabackup

Вот в этом

mysqldump: Error: 'Got error 28 from storage engine' when trying to dump tablespaces
mysqldump: Couldn't execute 'show fields from `admin_login_logs`': Got error 28 from storage engine (1030)
mysqldump: Couldn't execute 'SHOW TRIGGERS LIKE 'admin\_login\_logs'': Got error 28 from storage engine (1030)
mysqldump: Couldn't execute 'show fields from `admin_logs`': Got error 28 from storage engine (1030)

`mysqldump -f --quick --opt -u backup --password=*******--databases forum >$forum 2>/etc/mannaz/mannaz.log`

Ругается что места не хватает, но его вагон этого места

бинарные логи

и что с ними потом делать?

Его вагон где? На разделе с базой, на разделе, куда кидается дамп или в /tmp?

Ругается что места не хватает

а в /tmp (tmpdir) хватает?

Проста мне кажеться мой дам не сможет занять 200 мег tmp! На винте как бы место хватает! Где база тоже хватает!

Да как бы я посмотрел! Внизу приложил комент! Вся трагичность ситуации следующая что дам делается раз через раз! Но самое интересное что если я запущу сам срипт то из 10 раз 10 будет 100% ризультат а вот если запускает cron то то 70% что будет всё нормально а так тока кусок базы! Я уже устал бороться с этим mysqldump

df -i

Очевидно, что, используя (полные) бинарные логи, можно «проиграть» запросы транзакций к базе, получив ту же базу. Является очень ценной технологией (особенно в финансовой сфере), т.к. (как оказалось) БД-ПО может глючить, а БД может при этом даже повредиться (что не сразу может быть замечено).

А по подробней? Я так понимаю что настраиваю бинарный лог и раз в сутки я его копирую? Копировать можно на горячею не останавливая mysql? Я так понимаю будут записываться тока транзакции, но если я настраиваю бинарный лог то попадет в него то что есть сейчас ? или тока транзакции которые после включения бинарного лога ?

Сп прикольная софта буду её побывать! А ты сам пользовался?

Неа, рассматривали как замена mysqldump, но что-то нас в ней не устроило, не помню что.

-u backup --password=*******

Не надо так делать. Лучше задай логин и пароль в ~/.my.cnf у пользователя, от имени которого делаются резервные копии.

тока транзакции которые после включения бинарного лога

Но никто не мешает сделать бекап дампом, потом его восстановить на чистую mysql, которая уже использует лог транзакций (такой же метод (насколько я знаю) используется для уменьшения размера бинарных логов, если есть паранойя по поводу базы (финансы). Хотя, в обычном случае, достаточно не давать другим клиентам подключиться (перевод в ro), слить дамп, удалить логи транзакций, перезапустить уже в rw. Тогда для восстановления будет нужен тот дамп+дапм последующих транзакций.).

Однако, данный метод (бекап и восстановление через лог транзакций) может быть весьма затратен на больших ресурсах, некритичных к потере пары транзакций (сайты). Во-первых, объем логов будет равен числу RW-операций, во-вторых скорость проигрывания таких логов меньше скорости проигрывания дампа из-за куда большего числа транзакций (все, а не текущего результирующего временного среза).

В случае говнопроектов (говносайт, говнобухгалтерия и т.д.) я рекомендую использовать снапшоты/прямое копирование с остановкой mysql-сервера (ночью) и тупа копирования (архивировния) тупо файлов БД. При использовании снапшотов (COW) остановка mysql нужна только для создания снапшота, далее можно сделать бекап из подмонтированного снапшота (или вообще не делать).

Что касаемо теории курицы (записи в конечный файл БД) или яйца (записи в бинарный лог транзакций), то тут вопрос очевиден: скачала яйцо, потом курица, чтобы сохранять консистентность (как в ФС журнал).

Я сейчас подумал, что в случае не-фин проекта, снапшоты можно делать даже в случае текущей записи в БД без остановки сервера (желательно всё-таки тогда применять и бинарные логи, на всякий пожарный). В такой ситуации полученный срез хотя и не будет полностью консистентен, для mysql это будет выглядеть как внезапная потеря питания или kill -9. Тогда как в случае обычного tar-бекапа без блокировки записи файл будет неконсистентным («начальные» регионы файла БД успеют замениться, пока будут читаться «конечные», в результате мы получим сбойный файл).

И ещё: mysqldump затыкается - это значит «приостанавливается и не продолжается» или «медленно идет с какого-то места»? Если первое, что смотрите лог (который с ошибками/отчетами, а не транзакций), т.к. может иметь место баг или повреждение БД.

bacula

А каким образом bacula делает бекап мускуля?

А какая разница? Как мне это поможет?

Так я уже ошибку написал! Гугол говорит места мало! Но бывает странные ситуации, что раз делается полностью а бывает косячный!

Я так понимаю что альтернатив нет mysqldump всё плохо!

Вероятно, снапшот-бекапы + бинарные логи дадут наилучший результат.

А какая разница? Как мне это поможет?

Разница в том, что при задании пароля в конфиг-файле, он (пароль) не засветится в /proc/$PID/cmdline. Но описанные тобой проблемы, естественно, это не решит.

В плане безопасности! Спасибо за совет

Он и так не светится, в принципе:

rain@elitebook:~$ ps axu | grep ' mysql '
rain 11099 0.0 0.0 40464 3012 pts/7 S+ 09:58 0:00 mysql -hlocalhost -uroot -px xxxxx
rain@elitebook:~$ sudo cat /proc/11099/cmdline
mysql-hlocalhost-uroot-pxxxxxx

Но спрятать не помешает, да

Он и так не светится, в принципе:

Он светится, просто недолго. Утилита mysql затирает его в памяти после запуска. Но тем не менее, между запуском процесса и выполнением кода затирки пароля всегда будет какой-то промежуток времени, когда пароль виден.

снапшот любой файловой системе можно сделать?

На любой файловой системе с поддержкой снапшотов :) Если нельзя переразметить диск, то можно сделать lo-файл и его через lo-setup как блочное устройство монтировать (либо сразу mount --loop)