MySQL backup

Что? Т.е. просто не использовали LVM. Так и запишем, нечего стесняться.

Покуда есть место (порядка размера изменений на $LV, покуда снапшот нужен) на

группе томов ($VG) - делаем снапшот любого тома подходящего размера ($LV) - мгновенно:

lvcreate -L XXXG -s -n ${LV}_backup /dev/${VG}/${LV}

LVM неудачно организован, скорее всего, если вся группа томов занята

одним логическим томом. У Вас 3Gb данные mysql (каталог) всего (или к чему последнее предложение)? Так вынести каталог данных mysql на отдельный

логический том, делать его снапшот.

Про теневое копирование от R1Soft почему все молчат?

Andreyka, а что про него говорить, если бесплатные инструменты не хуже?

Еще стоит вспомнить xtrabackup. тоже бесплатный, но он для innodb разработан.

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

коммерческого продукта.

Во-первах, на этом томе болтается очень жирная ВПСка. Во-вторых, действительно нужные данные в СЖАТОМ виде весят 3 Гбайт. Вместе с мускулом и т.п. Остальное пространство используется очень _активно_. Свободно на томе примерно 30 Гбайт, остальное - активно использующиеся SVN-репозитории, кучка всяких ротаций различных логов, кучка всякой дребедени, которая активно пишет всякие кеши и т.п., кучка всяких обновлений качается, ядра пересобираются... Я об этом. А зачем снапшотить статический раздел, я не понимаю. Собственно, бекап переносился для того, чтобы на отдельный сервер без этой тряхомундии стабильного зверя унести, все. Вот вы представьте, сидят на ВДСке 3 пользователя, что-то постоянно программят, что-то компилят, что-то запускают в chroot... Мне кажется, слишком частое обновление снапшота ни к чему хорошему привести не может. Это раз...

А два - снапшоты я попросту никогда не делал. Нет, вру, делал один раз. 20-гигабайтный раздел снапшотился минут 10... Потому как диск активно использовался. И еще...

service stop mysql && service stop kloxo && service killall mysql && service killall kloxo вырубают напроч весь мускул со всеми мониторами. Подскажу, клоксо - это панелька такая. Для хостинга. Может я и не представляю, как именно происходит снапшот в ЛВМ, но одно я вижу точно: мне оно в данный момент не надо. Так как некуда. Не проще ли держать все в рейде на случай отказа дисков и бекапить непосредственно перед серьезными изменениями? :-D.

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

Raistlin добавил 08.02.2010 в 14:12

P.P.S. А ели уж вы такие умные, поставьте ее на 64 бит-систему, чтобы не глючило. И, пожалуйста, заставьте заработать почту. А то курьеру памяти не хватает :-D. Держу пари, что эту проблему так же быстро и изящно решить из вас никто не сможет :-D. Ну разве что кто-то, кто умеет готовить qmail... Достаточно давно :-D. Понты в стороны. Как-та таг. :-D.

Скорее всего, таки не врете. Т.к. время на создание

снапшота ~= 0, там же COW используется. Работа LV, которого

снапшот делается - тормозится в дальнейшем, конечно. Но

ведь это уже другое дело.

Ниче не знаю, было один раз и примерно год назад. Сервак тупил 10 минут и считал проценты. 20 гектар... Это вообще я тогда экспериментировал с переносом ВПСок на другую ноду... Честно говоря, ничего полезного не вынес оттуда. Врать смысла нет, хотя и умею. Только боюсь, в данном разделе это плохо получится.

Мы делаем :)

Понятно, продолжайте дальше, я люблю следить за тэоретиками 🍿

Andreyka,remsys - кто мешает Вам рассказать про решения от R1Soft,

если Вы их используете? 🍿

А следить - кто-ж запретит - может и для себя что-то вдруг откроете.