Comments 20
Не поделится ли кто-нибудь баш-скриптом, выполняющим инкрементальное копирование посредством rsync? Хочется посмотреть рабочие примеры, чтобы понять правильно ли сделал себе.
+1
Ох, не знаю подойдет ли Вам, но мы лет несколько бэкапили 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.
Единственное, при такой схеме сложно извлечь бэкап за определенную дату — нужно писать еще спец скрипт.
0
UFO just landed and posted this here
rsnapshot
+5
Для себя я такой скрипт в свое время написал: zerolab.net/?p=1473
Это лишь мое видение оптимального резервного копирования, возможно кому-нибудь пригодится.
Это лишь мое видение оптимального резервного копирования, возможно кому-нибудь пригодится.
0
Например вот так gist.github.com/nshopik/10134265
0
Есть такая штука как rdiff-backup
0
> Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
0
Хочу добавить что дополнительно должны быть механизмы для проверки резервных копий. Особенно это актуально для баз данных.
+3
В целом хорошая подборка, но по поводу копирования устройств есть неточности и ошибки:
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.
+2
1) Согласен, только речь шла как раз о результате, т.е. о кооперации с ОС этих утилит. Сложность нормального сброса кешей с mdraid и lvm разная. mdraid/drbd тоже можно довести до ума, только надо корректно скидывать кеши.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.
2) Разве MySQL всегда пишет данные в буффер ОС? И там и там вызывается fsync(), т.е. подтверждение записи ожидается от дисковой подсистемы.
0
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 на правильное место?
0
1. Очень похоже на тонкий троллинг. :)
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
Я уже писал, что речь идет не отдельно об утилитах. Вопрос рассматривается системно. Название статьи — схемы резервного копирования, а не утилиты. ;)
Расскажите как сбросить кеши в схеме с mdadm и если это не сложнее, чем с схеме с LVM, я соглашусь с вашим первым утверждением.
2. Ключевая фраза — «если не указана прямая запись на диск».
Я писал о том, что некорректно утверждать какой из методов должен быть первый, а какой второй.
В проекте, под который написан был тот скрипт бекапа — flush на диск идет при помощи fsync().
У меня там данных на диск пишется в разы меньше чем в БД (а это типичная ситуация) и выполнять sync после блокировки и сброса кешей MySQL подобно смерти — там накопится огромная очередь запросов, и не дай бог, oom-killer.
А когда MySQL пишет не на диск, а в кеш, безусловно пользоваться надо вашим методом.
0
1. На мой взгяд, вы должны понимать, что так как и dm (LVM), и md являются блочными устройствами, буферы ядра работают выше уровнем и сбрасываются абсолютно одинаково. Напримет, тем же самым sync.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
-1
UFO just landed and posted this here
Странно, что тут еще не упомянули о mrb manpages.ubuntu.com/manpages/gutsy/man8/mrb.8.html — отличная утилита-надстройка над rsync, делает хорошие дифференциальные бекапы с хардлинками на старые файлы в предыдущем бекапе, если они не изменялись и копированием новых измененных. Таким образом все срезы полноценны, готовы к заливке и не занимают много места.
+3
Sign up to leave a comment.
Сравнение способов резервного копирования