Comments 63
если не ошибаюсь что-то подобное уже где то было
но все равно спасибо за старания =)
но все равно спасибо за старания =)
Я в свой скрипт резервного копирования (запускается кроном) добавил хранение бекапов только за определенное количество дней (сейчас — 7).
Потому что размер одного бекапа примерно 2G.
Потому что размер одного бекапа примерно 2G.
Когда почти террабайт на сервере стоит, не задумываешься о таком пока что :) но идея хороша :) доработаю потом.
и всё-таки,
unix-way — это выполнение задачи специально приспособленными для неё утилитами, а не «минимумом средств»
unix-way — это выполнение задачи специально приспособленными для неё утилитами, а не «минимумом средств»
Ага а если утилиты нету — пишем ее сами. :)))
Чем именно в данном случае?
Чем именно в данном случае?
для копирования файлов вообще есть утилита rsync, которая кроме прочего, умеет бэкапить на удалённые хосты, и при этом копирует только изменившиеся фрагменты файлов.
для MyISAM таблиц достаточно сделать им LOCK_TABLES/FLUSH_TABLES и скопировать rsyncом бинарные файлы, в которых он хранятся.
для бэкапа InnoDB таблиц эффективнее использовать бинарный лог, позволяющий делать инкрементальный бэкап.
всё подробно описано в мануале
а с mysqldumpом при восстановлении нужно ещё следить за ссылочной целостностью и автоинкрементными полями.
для MyISAM таблиц достаточно сделать им LOCK_TABLES/FLUSH_TABLES и скопировать rsyncом бинарные файлы, в которых он хранятся.
для бэкапа InnoDB таблиц эффективнее использовать бинарный лог, позволяющий делать инкрементальный бэкап.
всё подробно описано в мануале
а с mysqldumpом при восстановлении нужно ещё следить за ссылочной целостностью и автоинкрементными полями.
А что будет быстрее — бекапить rsync'ом или tar + gzip?
rsync просто копирует + проверяет изменения. он не сжимает.
(сжимает только для передачи по сети)
(сжимает только для передачи по сети)
Ок, убираем сжатие.
Что быстрее — просто копирование или просто копирование с проверкой изменений (tar vs rsync)?
Что быстрее — просто копирование или просто копирование с проверкой изменений (tar vs rsync)?
tar — это не программа копирования.
полная копия rsyncом будет медленне, чем cp или scp
а если файл изменился только частично — то естественно, rsync быстрее.
полная копия rsyncом будет медленне, чем cp или scp
а если файл изменился только частично — то естественно, rsync быстрее.
Тогда предлагаю (cp+md5sum vs rsync)
в rsync алгоритм гораздо хитрее, чем md5sum.
он вычисляет изменившиеся _фрагменты_ файла, чтобы сократить трафик.
на cp+md5sum придётся городить некислый скриптовый огород.
он вычисляет изменившиеся _фрагменты_ файла, чтобы сократить трафик.
на cp+md5sum придётся городить некислый скриптовый огород.
Но если чкрестить cp+md5sum и во время первого бэкапа создавать лист контрольных сумм, то потом это будет работать быстрее, мне так кажется. Ведь найти контрольную сумму из списка быстрее чем изменившийся фрагмент
пробовали.
предыдущий админ в нашей конторе так и сделал (на перле, для бэкапа файл-сервера гигов на 30)
rsync оказался быстрее настолько, что замерять насколько именно даже в голову не пришло.
предыдущий админ в нашей конторе так и сделал (на перле, для бэкапа файл-сервера гигов на 30)
rsync оказался быстрее настолько, что замерять насколько именно даже в голову не пришло.
Будет время, я знакомого попрошу написать на баше такое, он хорошо шарит. Лично посмотрим :)
одно время юзал
скрипт с невыговариваемым названием bontmia
он делает (rsyncом) снапшоты каталога.
на каждый снапшот — бэкапит изменившиеся файлы, а неизменившиеся делает хардлинком на предыдущий снапшот.
возможно, стоит на него посмотреть.
скрипт с невыговариваемым названием bontmia
он делает (rsyncом) снапшоты каталога.
на каждый снапшот — бэкапит изменившиеся файлы, а неизменившиеся делает хардлинком на предыдущий снапшот.
возможно, стоит на него посмотреть.
А для проверки md5sum файла (чтобы узнать, изменен он или нет) разве его прочитать не нужно? Не проще ли обратить внимание на дату файла — если она изменилась, то и файл теоретически должен измениться.
Имхо сделано как раз в духе Unix-way: каждая отдельная программа выполняет конкретно ту задачу, которую умеет выполнять лучше всего.
«Специальной утилитой»? Это тот миллион быдлософтинок для «бекапа, очистки и всего всего всего», что активно плодятся как мухоморы после дождя под виндой и просят всего $49.95 за красивый интерфейс?
Даешь разделение кода! Конфиги отдельно, каждую операцию — в отдельную функцию.
Полезная вещь.
Вы бы date +%F--%H-%M в отдельную функцию вынесли, раз уж используете ее в каждой строчке почти что
надо еще ротацию дописать
tee /home/bond/backup/backup.log
Имхо лучше
tee -a, чтобы лог не перезаписывался, а делался append.
Откройте для себя bacula.
Ещё одно замечание. Большие дампы лучше сжимать на лету: mysqldump… | gzip > sql.dmp.gz
ну и вообще говоря, mysqldump генерит sql-текст, что существенно больше, чем бинарники.
если же бэкапить сами файлы таблиц, сжатие менее актуально.
а rsync сможет забэкапить только те куски таблиц, котрые изменились.
если же бэкапить сами файлы таблиц, сжатие менее актуально.
а rsync сможет забэкапить только те куски таблиц, котрые изменились.
автор принципиально не использует процедуры? :)
function print()
{
d=`date +%F--%H-%M`
prefix=$1
msg=$2
echo "$prefix $d $msg"
}
Вам же самому проще будет менять формат вывода в одном месте, чем искать их по всему скрипту
function print()
{
d=`date +%F--%H-%M`
prefix=$1
msg=$2
echo "$prefix $d $msg"
}
Вам же самому проще будет менять формат вывода в одном месте, чем искать их по всему скрипту
С mysqldump нужно поаккуратнее, иначе есть шансы получить такой дамп, который хрен восстановишь. Помнится, ресторили мы один INSERT, в котором было много миллионов записей…
еще можно потом отправить весь архив на S3 :)
есть библиотека code.google.com/p/s3-bash/, которая в этом поможет
или просто на резервный бэкап сервер (scp), чтоб мы не потеряли все бэкапы, если накроеся винт
есть библиотека code.google.com/p/s3-bash/, которая в этом поможет
или просто на резервный бэкап сервер (scp), чтоб мы не потеряли все бэкапы, если накроеся винт
Как я понял, бэкапы сольются на сервер Amazon?
да, это такой их севис — aws.amazon.com/s3/
Эх, хорошо с этим у линукоидов. А мне бы нормальную бэкапилку под Винду :(
В тему. Может кому пригодится статья Автоматизация резервного копирования в Linux от IBM developerWorks.
К слову о функциях и переменных:
И всё, что можно, оформляется в таком духе:
$mysqldump_console и $backup_to берётся из настроек конкретного проекта с помощью команды source.
При таком подходе проблемы начинаются тогда, когда нужна более продвинутая обработка ошибок вроде конструкции try-catch-finally и пролетающих сквозь стэк исключений. Тогда я не жалею времени, чтобы переписывать bash-скрипт бэкапа на программу на питоне:
function assert2 {
msg=$1
shift
test "$@"
ec=$?
if [ $ec -gt 0 ]
then
echo "ERROR (assertion $* failed): $msg"
exit 2
fi
}
function run {
"$@"
ec=$?
if [ $ec -gt 0 ]
then
echo "failed with error code $ec:" "$@"
exit 3
fi
}И всё, что можно, оформляется в таком духе:
d=`date +%F--%H-%M`
assert2 "mysqldump_console is empty" ! -z "$mysqldump_console"
run $mysqldump_console --result-file=$backup_to"${d}-database.sql"$mysqldump_console и $backup_to берётся из настроек конкретного проекта с помощью команды source.
При таком подходе проблемы начинаются тогда, когда нужна более продвинутая обработка ошибок вроде конструкции try-catch-finally и пролетающих сквозь стэк исключений. Тогда я не жалею времени, чтобы переписывать bash-скрипт бэкапа на программу на питоне:
...
if not machine_is_on(machine_info['host']):
turn_on_machine(machine_info['host'], machine_info['mac'])
assert not os.listdir(settings.target_mountpoint), 'mountpoint is not empty'
mount_command = ("smbmount //%(host)s/%(shared_path)s " + settings.target_mountpoint + " -o %(mount_options)s") % machine_info
if not os.system(mount_command) == 0:
raise Exception('mount error')
try:
# do backup
finally:
if not os.system("smbumount %s" % settings.target_mountpoint) == 0:
raise Exception('umount error')
...
Я использую backupninja в сочетании с rdiff-backup. Рекомменд.
Sign up to leave a comment.
Элементарный Bash скрипт для резервного копирования данных