может у тебя что-то в кронтабе записано ? логи не смотрел ?

Вот листинг команды: crontab -e

59 7 * * * /etc/webmin/cron/tempdelete.pl #Delete Webmin temporary files
1,6,11,16,21,26,31,36,41,46,51,56 * * * * /etc/webmin/virtual-server/collectinfo.pl
0 23 * * * updatedb

Что именно мне посмотреть в логах, чтобы понять где запара?

А может и не у него, а где-то на промежуточном роутере в ДЦ что-то творится.

Кстати, возможно проблема возникает при ежедневном бекапе БД (MySQL). База дампится и сжимается. Т.к. база не маленькая, (около 5Гб) может в этом проблема?

Скрипт сжатия бд:

#!/bin/sh

db_name="MYSQL"
db_pass="PASSWORD_HERE"
db_date="$(date +%d.%m.%Y)"
db_MYSQL="$(date +%d.%m.%Y)_db_MYSQL.sql"

mysqldump -u$db_name -p$db_pass --opt $db_name > /home/dir/backup/db/$db_MYSQL
sleep 60
tar zcvf /home/dir/backup/db/$db_date.sql.tgz /home/dir/backup/db/$db_MYSQL
sleep 60
rm /home/dir/backup/db/$db_MYSQL
sleep 30
echo "Ok"
exit 0

Может проблема в скрипте? Он лежит в папке /etc/cron.daily и выполняется раз в сутки (где-то в 4 часа как раз...)

Если проблемы в скрипте, то как дампить большую БД без подобных проблем (без дауна сайтов)?

как я понял со скриптом всё ок. но вот вопрос в том насколько долго выполняется этот скрипт.
может когда начинает работать tar возникают проблемы ?

может когда начинает работать tar возникают проблемы ?

А как узнать возникают они или нет?

nice, не?

nice, не?

Т.е. понизить приоритет выполнения скрипта?

да какой nice…

таблицы на бекапе лочатся. соответственно, всякие insert-ы и update-ы ждут пока оно забекапится.

решается это только установкой отдельного mysql-я slave-ом, что бы бекап делался с него.

Ну да. Если есть подозрения, что система под бэкапом ложится.

но ещё не факт что именно под бэкапом ложится

а в messages что говорится ?

но ещё не факт что именно под бэкапом ложится

Хм... Сейчас проверил. Запустил скрипт бекапа, - сайты в дауне. Как только я его остановил, все сайты стали корректно отвечать... Похоже действительно нужно делать репликацию и с реплики уже делать бекап.

Спасибо большое за наводки!

Можно еще предположить, что провайдер рвет соединение разв сутки, а потом его восстанавливает. По крайней мере у меня так и есть, хотя никогда лично не замечал.

Сервер находится в ДЦ, и этот ДЦ весьма надежен.

Ну тогда грешить можно только на скрипт, но ты и так уже это понял =)

> 1,6,11,16,21,26,31,36,41,46,51,56 * * * * /etc/webmin/virtual-server/collectinfo.pl

Сделай уже */5

Спасибо, законное замечание!

--skip-lock-tables

--skip-lock-tables

Моя команда превращается в?

mysqldump -u$db_name -p$db_pass --opt $db_name --skip-lock-tables > /home/dir/backup/db/$db_MYSQL

Что это дает, только то что БД не блокируется на время бекапа? Будут ли последствия такого шага, при откате базы обратно?

зайти на сервер по ssh в 4 утра и смотреть логи и top. логично же =)

айти на сервер по ssh в 4 утра и смотреть логи и top. логично же =)

КО! :)

> Будут ли последствия такого шага, при откате базы обратно?

вполне можешь получить битую БД при восстановлении.

вполне можешь получить битую БД при восстановлении.

Выход репликация master-slave?

именно так. или repair БД после отката. обычно проходит нормально.

> Что это дает, только то что БД не блокируется на время бекапа?

Именно

Будут ли последствия такого шага, при откате базы обратно?

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

Всем большое спасибо за ответы!