Comments 20
Не поделится ли кто-нибудь баш-скриптом, выполняющим инкрементальное копирование посредством rsync? Хочется посмотреть рабочие примеры, чтобы понять правильно ли сделал себе.
Ох, не знаю подойдет ли Вам, но мы лет несколько бэкапили OpenVZ ноды вот таким манером: gist.github.com/pavel-odintsov/8b01b8d83ee996603e00
Весь цимус там во флагах rsync:
То есть, при включенном флаге --backup все файлы, которые отличаются от текущей рабочей папки (где содержится идентичная копия боевой машины), клудутся в папку с именем incremental_backup_for_some_date.
Единственное, при такой схеме сложно извлечь бэкап за определенную дату — нужно писать еще спец скрипт.
Весь цимус там во флагах rsync:
--backup --backup-dir incremental_backup_for_some_dateТо есть, при включенном флаге --backup все файлы, которые отличаются от текущей рабочей папки (где содержится идентичная копия боевой машины), клудутся в папку с именем incremental_backup_for_some_date.
Единственное, при такой схеме сложно извлечь бэкап за определенную дату — нужно писать еще спец скрипт.
UFO just landed and posted this here
rsnapshot
Для себя я такой скрипт в свое время написал: zerolab.net/?p=1473
Это лишь мое видение оптимального резервного копирования, возможно кому-нибудь пригодится.
Это лишь мое видение оптимального резервного копирования, возможно кому-нибудь пригодится.
Например вот так gist.github.com/nshopik/10134265
Есть такая штука как rdiff-backup
> Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
Хочу добавить что дополнительно должны быть механизмы для проверки резервных копий. Особенно это актуально для баз данных.
В целом хорошая подборка, но по поводу копирования устройств есть неточности и ошибки:
1. Неправильно противопоставлять md raid1 и drbd как ненадежный способ, а lvm snapshot, как надежный. На самом деле, условия копирование дисков через mdraid, drbd или lvm snapshot одинаковы. Полную консистентность без кооперации с операционной системой и приложениями не гарантирует ни один из них. А при сбрасывании данных приложений и буферов ОС, все эти способы обеспечат одинаковую консистентность файловой системы.
Вы порекомендовали flush table только для lvm, хотя это точно так же полезно и для md/drbd.
Отключение slave-диска из RAID mirror идентично созданию в этот момент lvm снэпшота — содержание и mirror slave, и снэпшота будет одинаково.
2. В приведенном вами коде
sync должна быть последней командой перед lvcreate. А в данном сценарии будут сначала сброшены на диск буферы ядра, потом mysqld сбросит из своих буферов данные в буферы ядра, но они еще не будут записаны на диск в тот момент, когда вызван lvcreate.
1. Неправильно противопоставлять md raid1 и drbd как ненадежный способ, а lvm snapshot, как надежный. На самом деле, условия копирование дисков через mdraid, drbd или lvm snapshot одинаковы. Полную консистентность без кооперации с операционной системой и приложениями не гарантирует ни один из них. А при сбрасывании данных приложений и буферов ОС, все эти способы обеспечат одинаковую консистентность файловой системы.
Вы порекомендовали flush table только для lvm, хотя это точно так же полезно и для md/drbd.
Отключение slave-диска из RAID mirror идентично созданию в этот момент lvm снэпшота — содержание и mirror slave, и снэпшота будет одинаково.
2. В приведенном вами коде
$ sudo sync
$ sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
$ sudo mysql -e 'FLUSH LOGS;'
$ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s
$ sudo mysql -e 'UNLOCK TABLES;'
sync должна быть последней командой перед lvcreate. А в данном сценарии будут сначала сброшены на диск буферы ядра, потом mysqld сбросит из своих буферов данные в буферы ядра, но они еще не будут записаны на диск в тот момент, когда вызван lvcreate.
1) Согласен, только речь шла как раз о результате, т.е. о кооперации с ОС этих утилит. Сложность нормального сброса кешей с mdraid и lvm разная. mdraid/drbd тоже можно довести до ума, только надо корректно скидывать кеши.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.
1. Нет разной сложности сброса кэшей, кэши находятся выше блочного устройства хоть md, хоть dm для LVM, и сбрасываются одинаково. Далее тоже сложности нет — выполнить по одной команде — mdadm -f или lvcreate -s.
Вы пока так и не написали, чем конкретно md или что в нем нужно доводить.
2. В буферы ОС он пишет всегда (если не указана прямая запись на диск), как раз их потом fsync и должен сбросить. Но дальше водятся драконы. Скажем, может вызываться не fsync, а fdatasync, который не обновляет мета-данные. Скорее всего есть и другие причины или баги из-за которых в буферах что-то остается. Вы можете для эксперимента в своем скрипте после flush tables и перед lvcreate посмотреть, что будет в Dirty и Writeback в /proc/meminfo. Я всегда вижу какие-то данные.
Еще давайте представим, что у вас либо в памяти держится несколько сотен Мб несброшенных данных, либо какой-нибудь тяжелый селект выполняется и flush tables будет ждать несколько минут его завершение. А в это время в системе пришутся какие-то другие файлы — и до диска что-то доходит, а что-то не доходит.
Не захотелось еще перенести sync на правильное место?
Вы пока так и не написали, чем конкретно md или что в нем нужно доводить.
2. В буферы ОС он пишет всегда (если не указана прямая запись на диск), как раз их потом fsync и должен сбросить. Но дальше водятся драконы. Скажем, может вызываться не fsync, а fdatasync, который не обновляет мета-данные. Скорее всего есть и другие причины или баги из-за которых в буферах что-то остается. Вы можете для эксперимента в своем скрипте после flush tables и перед lvcreate посмотреть, что будет в Dirty и Writeback в /proc/meminfo. Я всегда вижу какие-то данные.
Еще давайте представим, что у вас либо в памяти держится несколько сотен Мб несброшенных данных, либо какой-нибудь тяжелый селект выполняется и flush tables будет ждать несколько минут его завершение. А в это время в системе пришутся какие-то другие файлы — и до диска что-то доходит, а что-то не доходит.
Не захотелось еще перенести sync на правильное место?
1. Очень похоже на тонкий троллинг. :)
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
1. На мой взгяд, вы должны понимать, что так как и dm (LVM), и md являются блочными устройствами, буферы ядра работают выше уровнем и сбрасываются абсолютно одинаково. Напримет, тем же самым sync.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
UFO just landed and posted this here
Странно, что тут еще не упомянули о mrb manpages.ubuntu.com/manpages/gutsy/man8/mrb.8.html — отличная утилита-надстройка над rsync, делает хорошие дифференциальные бекапы с хардлинками на старые файлы в предыдущем бекапе, если они не изменялись и копированием новых измененных. Таким образом все срезы полноценны, готовы к заливке и не занимают много места.
Sign up to leave a comment.
Сравнение способов резервного копирования