провёл краш тест с выключением по кнопке. Всё выжило, гипервизоры, gluster том, кроме марии дб. Бугога. Причем не только кластер сломался, она вообще не захотела стартовать.

не, ну на куй его. Я восстановить не смогу. Либо надо научится делать. но я с этим не работаю, так что учиться не у кого.

Так дел не пойдёт, это ебаная БД - ключевой компонент. А из дампа клон скуля восстанавливать несколько часов.

Что любопытно, текущая БД тоже несколько раз перегружалась, ну может не так жёстко, но аварийно, и поднималась сама.

Будем читать. Да и Деда Марию не тестировал.

Ну ос тут точно не причём, да и субд тоже. Субд -форк mysql когда-то, отзываются хорошо, так что тут я виноват, а не кто-то.

Самая большая БД из набора - скуль. Где-то 100+ Гигов ну и старый дедофорум + новый. Не помню сколько может под 25 гигов все вместе.

Я выделил диски по 500 гигов для БД.

Сами виртуалки да, буду бэкапить, конечно, но часто я это делать не смогу.

В конечном итоге 100+ гигов.

Но это из текстового дампа долго восстанавливать. Так-то можно другими методами пойти на новом хостинге.

Да. На текущем хостинге, на этом. А он, сравнительно быстрый. Может пров что-то подрезает. Поглядим на новом с физическими серверами. Так-то обхем маленький, но не для стандартного хостинга.

Давно уже я делал через снэпшоты LVM. Механизм в слайдах Оракла нашёл
Суть:
- flush tables with read lock; create snapshot; exit. Не обращайте внимание на блокировку, снэпшот создаётся быстрее, чем что-то успевает записаться, при выходе тут же снимается.
- архивируем директорию с данными, изменения пишутся в снэпшот.
- удаляем снэпшот, изменения сбрасываются в данные

Но так я делал с заббиксом, там терабайт с чем-то был, обычный дамп - очень долго. Всё корректно восстанавливалось + я переносил такой архив на слейв, чтобы репликацию настроить.

Но критиковали этот способ многие.

Я тут ещё вычитал про mariabackup. Это не аналог xtrabckup?

Сейчас, наверное, нет. На этом хостинге. Для этого нет ресурсов, вернее они стоят денег.. Даже ALTER TABLE таблицы с постами потребует в 2 раза больше места, места сейчас мало.

На физических серверах будет всё получше, там места ощутимо больше.

Блять, один Деда помнит, как я ебался с восстановлением на ноутбуке, на котором ещё меньше места )))

Касательно бэкапов самой БД мне знаком вышеозвученный способ с LVM снэпшотами. Он быстрый. Не знаю, насколько он будет корректен по отношению к форумной БД и тем более в кластере. Надо проверять.

Просто Трёп [игнорируется] 

ещё выше мегабайт озвучил xtrabackup. Слышал, но никогда не делал.

Ну вот тут подробно описано про озвученный мной метод, я про него читал ещё в слайдах оракла, поэтому решил довериться. Я бэкапил сравнительно большую БД заббикс, там терабайт примерно, которую в те времена дампить и сосать - это анрил полный. Да и бредово.

https://www.percona.com/blog/using-lvm-for-mysql-backup-and-replication-setup/

Если эта схема продемонстрирует себя приемлимо, то можно забить на этот кластер, настроить master-slave репликацию и бэкапить со слейва.

Правда тут есть некий нюанс, дамп - текстовый файл, бзип, например, его сжимает в больше чем 10 раз. А тут будут бинарные файлы и большой архив, который надо выгружать и хранить

Нашёл скрипт бэкапа, древнющийСмысл вше озвучен
- логинится в БД
- делает блокировку (блокировка не снимается до выхода)
- тут же создаёт снэпшот, прямо из mysql
- вылогинивается (блокировка тут же снимается)
- данные пишутся в снэпшот, пока делается бэкап, тупо архивируется директория
- после окончания снэпшот удаляется, данные сбрасываются в нормальный путь средствами LVM

InnoDB.