Про бекапы

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

Твоя же статья - вообще вредна, вдруг кто-то действительно попробует использовать приведённый скрипт, что будет с базой mysql после такого бэкапа?

Забыли то, что 99.9% пользователей не бэкапят 5TB данных с полусотни серверов в удаленный датацентр, базы на лету, не делают снапшоты состояния и не нуждаются в проверке целостности и статистке занятого места.

Им нужно просто сбэкапить свои данные в виде десятка сайтов и пятка баз на случай, если на сервере сгорит HDD.

Для таких задач монструозные "интегрированные решения" вроде Бакулы или Acronis TrueImage сильно избыточны и сложны. Не нужно забивать гвозди микроскопом и привинчивать сложную систему там, где обычного tar и mysqldump хватит с избытком.

Никто за бакулу и аманду и не ратовал.

fsbackup и есть обычный tar + mysqldump - но людям не понадобится изобретать велосипед. Берем конфиг по умолчанию, указываем какие директории бекапить, реквизиты доступа mysql и ftp/ssh доступ на площадку бекапа - ВСЕ.

mysqldump иногда бывает вреден. Если базы не в InnoDB и вы "сам себе админ", т.е. в случае чего сможете их положить файл "на место", то можно просто за'tar'ить папку /var/db/mysql/ или /var/lib/mysql в зависимости от системы.

Ага, и , если повезет, mysqlcheck/myisamchk - справятся потом, с тем, что

вы обратно положили "на место".

Для подобного есть mysqlhotcopy. Или использование LVM-снапшотов.

вот тут то и вылезает вся правда, что "всё что надо знать про бэкапы" - это не одна информационная страничка и не один скрипт, а куча проблем, которые надо решать. По хорошему бэкап должен начинаться с остановки apache (перед которым стоит nginx), остановки cron, остановки mysql. На практике это сложно, и достаточно остановить apache и сделать mysqlhotcopy, но это уже не так тривиально как просто запустить tar.

Если правда надо "на лету" сделать самосогласованную копию и файлов и баз данных (если _все_ интенсивно меняется) - лучше снапшоты использовать (LVM, ZFS). На эту тему тоже есть готовые решения в любом дистрибутиве - но это уже из той же категории, что и аманда.

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

Для базы данных (MySQL, к примеру) - это не проблема. Делаем flush tables, read lock на все - быстро снапшот - и unlock обратно. А с приложением, согласен. Тут, действительно проще стопнуть вебсервер на время создания снапшота.

Я не понимаю как это не проблема. В mysql транзакция размазана на время выполнения скрипта, то есть в принципе нельзя, без остановки скриптов, получить базу с сохранением целостности.

Но с локом это правильно - mysqlhotcopy так и делает. Всё это, в конечном итоге, сильно усложняет самопальные скрипты и, при правильном подходе, на выходе получается та же аманда :)