Comments 28
Если неправильно делать резервные копии, можно стать взадником без головы.
«Акатуальная» статья.
Странно что нет упоминания про дедупликацию данных (http://en.wikipedia.org/wiki/Data_deduplication), всё таки это хоть и дороже, но гораздо удобнее использования инкрементальных резервных копий.
Дедупликацию удобно организовать непосредственно на хранилище сервера, но тогда теряется смысл в использовании его как резервной копии.
Если дедупликация выполняется средствами хранилища архива, а программа резервного копирования о дедупликации не заботится, то это означает, что в архив необходимо каждый раз передавать полную копию — не оправданный расход ресурсов.
Если дедупликацией занимается программа резервного копирования, в том числе чтобы не передавать лишние данные по сети, то самая простая реализация дедупликации — инкрементное копирование.
Если дедупликация выполняется средствами хранилища архива, а программа резервного копирования о дедупликации не заботится, то это означает, что в архив необходимо каждый раз передавать полную копию — не оправданный расход ресурсов.
Если дедупликацией занимается программа резервного копирования, в том числе чтобы не передавать лишние данные по сети, то самая простая реализация дедупликации — инкрементное копирование.
Объясните пожалуйста, почему же смысл теряется?
И почему же передавать нужно именно полную копию, имелась ввиду именно дедупликация посредством программы, и лично я не вижу в этом существенных проблем, т.к. инкрементальная резервная копия в описанном вашем примере в посте по размерам значительно уступает полной резервной копии. И даже если индексация этой копии будет занимать несколько часов, то для пользователя это уже никак не будет афектить.
Создание инкрементальной резервной копии никак не является реализацией дедупликации, не путайте пожалуйста, это разные понятия.
Если говорить проще: то инкрементальная копия отслеживает изменения по сравнению с последней созданной резервной копией. В случае использования дедупликации: происходит именно поиск уникальных данных создаваемых в различных резервных копиях.
Например (ПРК — полная резервная копия; ИРК — инкрементальная резервная копия):
В случае создания инкрементальных копий: ПРК+ИРК+ИРК+ИРК и так до бесконечности (при этом каждая ИРК будет содержать все изменения), если конечно вы не будете настраивать политики консолидации и очистки старых копий. Т.е. получится 100Гб + 8 Гб + 8 Гб + 8 Гб и т.д.
В случае с дедупликацией: ПРК+ИРК+ИРК+ИРК… Но при этом размер будет значительно меньше, например 100Гб + 8 Гб + 1 Гб + 1 Гб и т.д.
И почему же передавать нужно именно полную копию, имелась ввиду именно дедупликация посредством программы, и лично я не вижу в этом существенных проблем, т.к. инкрементальная резервная копия в описанном вашем примере в посте по размерам значительно уступает полной резервной копии. И даже если индексация этой копии будет занимать несколько часов, то для пользователя это уже никак не будет афектить.
Создание инкрементальной резервной копии никак не является реализацией дедупликации, не путайте пожалуйста, это разные понятия.
Если говорить проще: то инкрементальная копия отслеживает изменения по сравнению с последней созданной резервной копией. В случае использования дедупликации: происходит именно поиск уникальных данных создаваемых в различных резервных копиях.
Например (ПРК — полная резервная копия; ИРК — инкрементальная резервная копия):
В случае создания инкрементальных копий: ПРК+ИРК+ИРК+ИРК и так до бесконечности (при этом каждая ИРК будет содержать все изменения), если конечно вы не будете настраивать политики консолидации и очистки старых копий. Т.е. получится 100Гб + 8 Гб + 8 Гб + 8 Гб и т.д.
В случае с дедупликацией: ПРК+ИРК+ИРК+ИРК… Но при этом размер будет значительно меньше, например 100Гб + 8 Гб + 1 Гб + 1 Гб и т.д.
Хранить хоть снэпшоты, хоть дедуплицированные копии на том же хранилище, что и оригинал, бессмысленно по причине — если пострадает оригинал, то с высокой вероятностью пострадает и копия. Копии должны находиться максимально далеко и быть независимыми от оригинала.
В принципе, сравнение разных методов хранения копий в тему статьи не входил, т.к. я писал о том как достигнуть консистентности копии, а не как ее лучше хранить. Но в комментариях с удовольствием поговорю о хранение, хотя не могу похвастаться опытом работы с большим числом средств.
Мы почти везде используем rsync и для передачи копий, и для организации нескольких версий. Лет 10 назад кроме него ничего лучшего не было, и сейчас это для большинства наших задач отлично подходит, поэтому нет причин менять. Задачу по сокращению объема передаваемых и сохраняемых данных он решает хорошо. Таких же гибких, простых в эксплуатации и проверенных долгой практикой аналогов, которые были бы для нас лучше, скажем, в аспекте дедупликации, пока не нашел. Наверняка они есть, но предполагаемая дополнительная выгода от их использользования слишком мала, чтобы оправдать переход.
Из современных способов дедупликации мне больше всего нравится дедупликация на блочном уровне, так как у нас становится все больше задач, в которых мы оперируем образами дисков и доступа в файловую систему не имеем и не должны иметь. Но пока «закидываем шапками» — когда необходимо, держим отдельные копии на дешевых дисках.
По поводу конфликтности терминов дедупликация и инкрементность не соглашусь. Путаница — да, есть. Скажем, rsync, сделав хардлинки на одинаковые файлы добился того, что их данные не дублируются. Но rsync называется это incremental backup, а bacula — deduplication.
В принципе, сравнение разных методов хранения копий в тему статьи не входил, т.к. я писал о том как достигнуть консистентности копии, а не как ее лучше хранить. Но в комментариях с удовольствием поговорю о хранение, хотя не могу похвастаться опытом работы с большим числом средств.
Мы почти везде используем rsync и для передачи копий, и для организации нескольких версий. Лет 10 назад кроме него ничего лучшего не было, и сейчас это для большинства наших задач отлично подходит, поэтому нет причин менять. Задачу по сокращению объема передаваемых и сохраняемых данных он решает хорошо. Таких же гибких, простых в эксплуатации и проверенных долгой практикой аналогов, которые были бы для нас лучше, скажем, в аспекте дедупликации, пока не нашел. Наверняка они есть, но предполагаемая дополнительная выгода от их использользования слишком мала, чтобы оправдать переход.
Из современных способов дедупликации мне больше всего нравится дедупликация на блочном уровне, так как у нас становится все больше задач, в которых мы оперируем образами дисков и доступа в файловую систему не имеем и не должны иметь. Но пока «закидываем шапками» — когда необходимо, держим отдельные копии на дешевых дисках.
По поводу конфликтности терминов дедупликация и инкрементность не соглашусь. Путаница — да, есть. Скажем, rsync, сделав хардлинки на одинаковые файлы добился того, что их данные не дублируются. Но rsync называется это incremental backup, а bacula — deduplication.
Какая-то сильно «водная» статья. Вроде бы любому понятные очевидные вещи превратились в «многобукв».
Статья большая, интересная, с картинками и большим количеством данных. Но есть еще один важный момент, наверняка присутствующий в сложных системах, о котором нет ни слова в статье, и который, увы, не позволяет — по-крайней мере, на мой текущий взгляд; надеюсь, вы меня переубедите — использовать метод резервирования виртуальнх снапшотов.
К примеру, этот метод не подходит для резервирования контроллеров домена в случае, если их больше одного. При попытке восстановить контроллер со снимка мы получим проблему отката USN (USN Rollback). Лично с ней сталкивался с год назад, уповая как раз на механизмы, описанные в статье. Слава богу, была «обычная» резервная копия, но так как проблема обнаружилась только через несколько дней после восстановления, изрядно помучился, внедряя в старую копию изменения за прошедшее время. Наверняка точно такая же ситуация будет и в других системах, использующих репликацию «мастер-мастер», а уж в случае с «master-slave» — почти 100% при восстановлении master-ноды.
К примеру, этот метод не подходит для резервирования контроллеров домена в случае, если их больше одного. При попытке восстановить контроллер со снимка мы получим проблему отката USN (USN Rollback). Лично с ней сталкивался с год назад, уповая как раз на механизмы, описанные в статье. Слава богу, была «обычная» резервная копия, но так как проблема обнаружилась только через несколько дней после восстановления, изрядно помучился, внедряя в старую копию изменения за прошедшее время. Наверняка точно такая же ситуация будет и в других системах, использующих репликацию «мастер-мастер», а уж в случае с «master-slave» — почти 100% при восстановлении master-ноды.
На уровне резервного копирования файловой системы решить вопрос конфликта версий узлов с взаимной репликацией невозможно. Думаю, описываемую ситуацию можно свести к такой:
1) Есть серверы, синхронизирующие между собой данные, и имеющие в один и тот же момент одинаковую версию данных.
2) Периодически выполняется резервное копирование снэпшотов файловой системы серверов. Версии данных при этом зависят от времени создания снэпшота и в общем случае у резервных копий, сделанных в одно и то же время, версия данных может не совпадать.
3) Произошел отказ одного сервера. Его восстанавливают из бэкапа за прошлый день, с устаревшей версией данных. Остальные узлы, работавшие без аварии работают с актуальной версией данных.
Проблему конфликта версий в этом случае должно решать только приложение, в данном случае, конроллер домена, т.к. только оно организует репликацию данных. При сохранении снэпшота без шатдауна машины, его данные могут оказаться на диске в неконсистентном состоянии, от него ничего не зависит. Если же у клона был сделан корректный шатдаун, для контроллера домена работающего в клоне, это выглядит как потеря связи с другими контроллерами и потом шатдаун. Если приложение в этом случае не может сохранить свое состояние таким образом, что при последующем запуске у него возникает конфлик версий, то это является недостатоком в работе приложения. Так как любой отказ одного из узлов, например, перезагрузка сервера, должна приводить к такому же конфликту.
Мне трудно допустить, что у контроллера домена такая реакция на перерыв работе может быть нормой. В статье по ссылке описывалось условие, в котором возникла проблема — это был просто снэпшот, и восстановление из этого снэпшота привело к нарушению в работе. Судя по ней, контроллер доменов не поддерживает Quiesce, поэтому не сбрасывает корректно данные на диск перед снэпшотом. Могу предположить, что ни в вашем случае, ни в случае из KB MS, шатдаун клона на снэпшоте не выполнялся.
В принципе, выполнив синхронно снэпшоты всех узлов, занимающихся репликацией, затем запустив их клоны в отдельной виртуальной сети, не пересекающейся с рабочей, и отправив их всех в шатдаун, мы получим консистентное состояние всей системы этих узлов. Но не вижу особой ценности в таком результате, ведь репликация master-master или master-slave нужна для того, чтобы не терять изменения, и при потере какого-то из узлов данные должны востанавливаться не по бэкапу, а из оставшихся узлов. И если мы вместо ресинхронизации узлов просто восстановим из бэкапа все узлы на прошлы день, мы потеряем произошедшие изменения.
1) Есть серверы, синхронизирующие между собой данные, и имеющие в один и тот же момент одинаковую версию данных.
2) Периодически выполняется резервное копирование снэпшотов файловой системы серверов. Версии данных при этом зависят от времени создания снэпшота и в общем случае у резервных копий, сделанных в одно и то же время, версия данных может не совпадать.
3) Произошел отказ одного сервера. Его восстанавливают из бэкапа за прошлый день, с устаревшей версией данных. Остальные узлы, работавшие без аварии работают с актуальной версией данных.
Проблему конфликта версий в этом случае должно решать только приложение, в данном случае, конроллер домена, т.к. только оно организует репликацию данных. При сохранении снэпшота без шатдауна машины, его данные могут оказаться на диске в неконсистентном состоянии, от него ничего не зависит. Если же у клона был сделан корректный шатдаун, для контроллера домена работающего в клоне, это выглядит как потеря связи с другими контроллерами и потом шатдаун. Если приложение в этом случае не может сохранить свое состояние таким образом, что при последующем запуске у него возникает конфлик версий, то это является недостатоком в работе приложения. Так как любой отказ одного из узлов, например, перезагрузка сервера, должна приводить к такому же конфликту.
Мне трудно допустить, что у контроллера домена такая реакция на перерыв работе может быть нормой. В статье по ссылке описывалось условие, в котором возникла проблема — это был просто снэпшот, и восстановление из этого снэпшота привело к нарушению в работе. Судя по ней, контроллер доменов не поддерживает Quiesce, поэтому не сбрасывает корректно данные на диск перед снэпшотом. Могу предположить, что ни в вашем случае, ни в случае из KB MS, шатдаун клона на снэпшоте не выполнялся.
В принципе, выполнив синхронно снэпшоты всех узлов, занимающихся репликацией, затем запустив их клоны в отдельной виртуальной сети, не пересекающейся с рабочей, и отправив их всех в шатдаун, мы получим консистентное состояние всей системы этих узлов. Но не вижу особой ценности в таком результате, ведь репликация master-master или master-slave нужна для того, чтобы не терять изменения, и при потере какого-то из узлов данные должны востанавливаться не по бэкапу, а из оставшихся узлов. И если мы вместо ресинхронизации узлов просто восстановим из бэкапа все узлы на прошлы день, мы потеряем произошедшие изменения.
Боюсь, что я не очень корректно описал проблему, или она непонятно изложена в MS KB. Дело в том, что сохранив данные даже выключенной системы на уровне файлов (например, вытащив диск из сервера, вставив его в другой компьютер и скопировав данные), потом запустив сервер снова и через какое-то время (максимум — через 15 минут, потому что это минимальное промежуток между репликациями) восстановив файлы на старое место, полностью затерев предыдущие, вы получите ту же самую проблему.
Ситуация в следующем: при репликации AD используется USN (update sequence number) совместно с идентификатором вызова (invocation ID) для отслеживания изменений, переданных с источника обновления. Эти номера фиксируются. Если вы сняли снимок виртуальной машины, а затем продолжили работу, все участники репликации продолжают обмениваться данными. Если же затем вы восстановите систему из снимка, то номера не совпадут. А так как AD не транзакционная система и логов там не ведется, то восстановленный сервер просто не сможет договориться с остальными участниками репликации — он будет пытаться отдать данные с устаревшим USN и ID, а остальные откажутся их принимать (и, соответственно, отправлять свои), потому что для них этот номер уже в прошлом.
Поэтому MS прямо говорит (все в той же статье по ссылке выше), что нельзя для резервного копирования контроллеров домена использовать средства типа Norton Ghost или снимков виртуальных машин, потому что не заведется потом, если данные реплицируются. При использовании штатных (или разработанных специально сторонних) средств в вышеуказанном случае происходит корректное обнуление (reset) USN и ID, и конфликта не возникает.
Кроме того, мне неясна, честно говоря, мысль «для получения инкрементных бэкапов нам нужно иметь снимок выключенной машины» либо она не до конца у вас в статье развернута. Безусловно, чтобы иметь возможность делать консистентный инкрементный бэкап, нужно иметь снимок файловой системы, но как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины? (может, я просто невнимательно прочитал статью и не увидел решения?) Если же отправлять всё целиком, то неясен смысл выключения клона, отправить прямо с памятью и в случае чего получить рабочую копию в уже работающем состоянии.
Отсюда же неясна ссылка на приведенный мной случай — сохранялся снимок всей машины и восстанавливался так же весь. Т.е. о неконсистентности данных в рамках виртуальной машины говорить просто не приходится.
В общем, я к чему разговор завел — предложенный метод именно в данном виде подходит для отдельных серверов либо небольших проектов, не завязанных друг на друга системами репликации. Во всех остальных случаях бессмысленно полагаться только на снимки системы на уровне виртуальной машины, потому что необходимо работать с резервированием\восстановлением данных на уровне приложения, а в таких условиях при использовании соответствующих файловых систем (т.е. позволяющих иметь снимки) нет нужды в чем-то сверху. Если мы заставили приложение сбросить на диск всю информацию из буферов в памяти, а затем создали снимок файловой системы, то мы можем всё, что нам нужно, сделать из самой виртуальной машины.
Конечно, если у нас куча виртуальных машин, то удобнее организовать это снаружи, но без вмешательства в работу виртуальной машины (т.е. без агента, работающего в ней, причем такого, который поддерживал бы все приложения, выполняющиеся там) полноценно сделать это нельзя.
Ситуация в следующем: при репликации AD используется USN (update sequence number) совместно с идентификатором вызова (invocation ID) для отслеживания изменений, переданных с источника обновления. Эти номера фиксируются. Если вы сняли снимок виртуальной машины, а затем продолжили работу, все участники репликации продолжают обмениваться данными. Если же затем вы восстановите систему из снимка, то номера не совпадут. А так как AD не транзакционная система и логов там не ведется, то восстановленный сервер просто не сможет договориться с остальными участниками репликации — он будет пытаться отдать данные с устаревшим USN и ID, а остальные откажутся их принимать (и, соответственно, отправлять свои), потому что для них этот номер уже в прошлом.
Поэтому MS прямо говорит (все в той же статье по ссылке выше), что нельзя для резервного копирования контроллеров домена использовать средства типа Norton Ghost или снимков виртуальных машин, потому что не заведется потом, если данные реплицируются. При использовании штатных (или разработанных специально сторонних) средств в вышеуказанном случае происходит корректное обнуление (reset) USN и ID, и конфликта не возникает.
Кроме того, мне неясна, честно говоря, мысль «для получения инкрементных бэкапов нам нужно иметь снимок выключенной машины» либо она не до конца у вас в статье развернута. Безусловно, чтобы иметь возможность делать консистентный инкрементный бэкап, нужно иметь снимок файловой системы, но как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины? (может, я просто невнимательно прочитал статью и не увидел решения?) Если же отправлять всё целиком, то неясен смысл выключения клона, отправить прямо с памятью и в случае чего получить рабочую копию в уже работающем состоянии.
Отсюда же неясна ссылка на приведенный мной случай — сохранялся снимок всей машины и восстанавливался так же весь. Т.е. о неконсистентности данных в рамках виртуальной машины говорить просто не приходится.
В общем, я к чему разговор завел — предложенный метод именно в данном виде подходит для отдельных серверов либо небольших проектов, не завязанных друг на друга системами репликации. Во всех остальных случаях бессмысленно полагаться только на снимки системы на уровне виртуальной машины, потому что необходимо работать с резервированием\восстановлением данных на уровне приложения, а в таких условиях при использовании соответствующих файловых систем (т.е. позволяющих иметь снимки) нет нужды в чем-то сверху. Если мы заставили приложение сбросить на диск всю информацию из буферов в памяти, а затем создали снимок файловой системы, то мы можем всё, что нам нужно, сделать из самой виртуальной машины.
Конечно, если у нас куча виртуальных машин, то удобнее организовать это снаружи, но без вмешательства в работу виртуальной машины (т.е. без агента, работающего в ней, причем такого, который поддерживал бы все приложения, выполняющиеся там) полноценно сделать это нельзя.
А что мешает использовать СРК, которые поддерживают корректное восстановление ВМ с ролью Контроллера Домена, например Symantec Backup Exec или Veeam Backup & Replication или что-то серьезнее?
Если эти средства позволяют восстанавливать VM из снимка (snapshot) виртуальной машины — то ничего не мешает. Только они ведь не позволяют. Они делают собственный backup, возможно, будучи установленными на host-систему (я, к сожалению, не работал с ни с одной из этих систем, поэтому не знаю), но скорее всего требуют либо отдельную физическую машину, либо стоят в отдельной виртуальной машине, а на остальные VM ставят свои backup-агенты.
Теперь понятно, USN для каждого сервера собственный, я сначала предположил, что он общий для всех. С учетом изложенного вами поведения узлов при встрече с устаревшими USN, получается, что протоколом их взаимного резервирования состояние консистентности распространяется на всю группу.
Т.е. в системе из нескольких приложений, разделяющих между собой данные, возможность восстановления нормального состояния после разрывов связи или сбоев должна быть предусмотрена либо самими приложениемя, либо отдельной программой восстановления. Без их участия резервирование может быть выполнено только при синхронной остановке клонов всех узлов в изолированной сети.
В принипе, можно представить в качестве аналогии приложение, использующее базу данных. Если они находятся на одном сервере и останавливаются одновременно и у них есть стандартная последовательность остановки: приложение сможет закрыть свои внутренние данные, сбросить их в базу, а база сбросить на диск. При шатдауне клона все будет выполнено правильно. Если находятся на разных серверах, то для сохранения консистентности их нужно клонировать и останавливать синхронно, чтобы они выполнили полностью штатные процедуры остановки не теряя связи друг с другом.
Т.е. в системе из нескольких приложений, разделяющих между собой данные, возможность восстановления нормального состояния после разрывов связи или сбоев должна быть предусмотрена либо самими приложениемя, либо отдельной программой восстановления. Без их участия резервирование может быть выполнено только при синхронной остановке клонов всех узлов в изолированной сети.
В принипе, можно представить в качестве аналогии приложение, использующее базу данных. Если они находятся на одном сервере и останавливаются одновременно и у них есть стандартная последовательность остановки: приложение сможет закрыть свои внутренние данные, сбросить их в базу, а база сбросить на диск. При шатдауне клона все будет выполнено правильно. Если находятся на разных серверах, то для сохранения консистентности их нужно клонировать и останавливать синхронно, чтобы они выполнили полностью штатные процедуры остановки не теряя связи друг с другом.
как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины?
Некоторые утилиты делают бэкап прямо с блочного устройства (dump) без монтирования. А в общем случае, для пофайлового копирования файловую систему можно монтировать в хост-системе, в отдельной виртуальной машине для копирования, экспортировать по iscsi на внешний сервер копирования бэкапов. У нас сейчас используется rsync в хост-системе, но есть планы изолировать копирование в отдельную виртмашину.
Некоторые утилиты делают бэкап прямо с блочного устройства (dump) без монтирования. А в общем случае, для пофайлового копирования файловую систему можно монтировать в хост-системе, в отдельной виртуальной машине для копирования, экспортировать по iscsi на внешний сервер копирования бэкапов. У нас сейчас используется rsync в хост-системе, но есть планы изолировать копирование в отдельную виртмашину.
Извиняюсь за офтоп. Для ESXi, вроде как, есть платные приблуды для репликации виртуалок в реальном времени. Кто-нибудь, интересно, пользовался?
м, так а встроенная клонирование это не одно и то же?
Так клонирование — это вроде просто снапшот. А нужна репликация мастер-слэйв.
Есть в XenServer (так и называется HA) и в патчах XEN Remus (уже включены в основную ветку). Реализуется через постоянную Live миграцию виртуалки с мастер хоста на бэкап хост. К данному топику имеет слабое отношение.
Про репликацию в Veeam уже упоминали ниже, хотя там действительно не совсем синхронная реплика.
В составе платных редакций начиная с Enterprise есть механизм создания на другом ESXi теневой копии защищаемой вм — Fault Tolerance.
В составе платных редакций начиная с Enterprise есть механизм создания на другом ESXi теневой копии защищаемой вм — Fault Tolerance.
а насчёт тулов да, вроде как Acronis и Veeam есть. Там есть подобный функционал.
Можно настроить синхронную репликацию на уровне СХД, умеют многие СХД middle и high-end уровня, обычно при покупке соответствующих опций.
Все известные мне программные решения реплицируют на уровне ВМ и обеспечивают только асинхронную репликацию. Хотя Veeam Backup & Replication умеет то, что называется near online replication (т.е. запускает задание репликации сразу после завершения предыдущего, т.е. каждые 3-7 минут, зависит от дисковой активности реплицируемой ВМ). Site Recovery Manager 5 может реплицировать не чаще, чем раз в 15 минут, у других примерно также.
Все известные мне программные решения реплицируют на уровне ВМ и обеспечивают только асинхронную репликацию. Хотя Veeam Backup & Replication умеет то, что называется near online replication (т.е. запускает задание репликации сразу после завершения предыдущего, т.е. каждые 3-7 минут, зависит от дисковой активности реплицируемой ВМ). Site Recovery Manager 5 может реплицировать не чаще, чем раз в 15 минут, у других примерно также.
Тоже за синхронную репликацию СХД. Но нужно всегда учитывать, что и репликация СХД, и репликации ВМ могут оказаться неконсистентными при старте резерва и часть данных окажется неживой. С этой точки зрения репликация ВМ, если выполняется с quiesce и приложения их поддерживают, может оказаться более надежным решением.
Я сколько работал с ксеном, /etc/init.d/xendomains stop не всегда корректно отрабатывал, а вы это на поток ставите.
И как праверить, что бэкап целостный
А если у тебя побитый бэкап, это еще хуже чем его нет вовсе
А активная работа с LVM снапшотами может привести к самым неожиданным последствиям, это очень узкое звено.
И как праверить, что бэкап целостный
А если у тебя побитый бэкап, это еще хуже чем его нет вовсе
А активная работа с LVM снапшотами может привести к самым неожиданным последствиям, это очень узкое звено.
Скорее всего, это ваш личный негативный опыт. Мы работаем с ксеном 4 года и все решаемо. Баги, конечно, встречаются. Но их можно либо самостоятельно устранять, либо репортить и ждать, когда устранят разработчики.
Про побитый бэкап не понятно кому адресован вопрос. Верифицируйте бэкап тем способом, к которому привыкли.
В чем претензия к снэпшотам LVM? Они приводят к закономерной деградации производительности, в этом нет ничего неожиданного и в статье про это написано. Собственно, как статья и показывает, как минимизировать деградацию.
Про побитый бэкап не понятно кому адресован вопрос. Верифицируйте бэкап тем способом, к которому привыкли.
В чем претензия к снэпшотам LVM? Они приводят к закономерной деградации производительности, в этом нет ничего неожиданного и в статье про это написано. Собственно, как статья и показывает, как минимизировать деградацию.
Мы тоже работаем с ксеном 4 года. Не в таких промышленных масштабах как Вы, но около 30-40 хост-систем с ~25 виртуальных машин на каждой имеется.
Баги встречаются и «самостоятельно устранять» — это самое интересное. Вы преподнесли статью как готовую HowTo, преподнеся как готовое стабильное решение, а самое интересное не написали. Какие баги возникли при остановке доменов XEN и как пофиксили?
Верификация бэкапа — это важнейший момент. Вы его упускаете.
При активной работе с LVM снапшотами наблюдается не деградация проивзодительности, а полный отказ системы. (Был эксперимент по запуску корневого раздела машин на снапшотах)
Баги встречаются и «самостоятельно устранять» — это самое интересное. Вы преподнесли статью как готовую HowTo, преподнеся как готовое стабильное решение, а самое интересное не написали. Какие баги возникли при остановке доменов XEN и как пофиксили?
Верификация бэкапа — это важнейший момент. Вы его упускаете.
При активной работе с LVM снапшотами наблюдается не деградация проивзодительности, а полный отказ системы. (Был эксперимент по запуску корневого раздела машин на снапшотах)
В основном, проблемы случаются не с самим ксеном, а с конкретными версиями паравиртуальных ядер. Самые простые решения — менять ядра, или использовать HVM. Другие проблемы при частном или корпоративном использовании вряд-ли будут пересекаться с нашими, т.к. связаны с тем, что стандартное окружение ксен подготовлено для отдельных серверов, а у нас условия сильно от этого отличаются.
Я написал ровно о том, о чем заявлено — про метод создания консистентных бэкапов. Верификация бэкапа — один из аспектов, ничем не важнее остальных, таких как- среда и место хранения, метод ротации и удаления. У вас были бы основания сказать, что я все это упустил, если бы я заявил, что это учебник о бэкапах от и до.
С LVM скорее всего вам не повезло с конкретным багом и конкретными условиями. Не могу больше ничего сказать про ваш случай. На моих личных десктопах при загрузке автоматически создается снэпшот корня и система потом стартует на этом снэпшоте. Ни разу связанных с этим проблем за пару лет не было.
Я написал ровно о том, о чем заявлено — про метод создания консистентных бэкапов. Верификация бэкапа — один из аспектов, ничем не важнее остальных, таких как- среда и место хранения, метод ротации и удаления. У вас были бы основания сказать, что я все это упустил, если бы я заявил, что это учебник о бэкапах от и до.
С LVM скорее всего вам не повезло с конкретным багом и конкретными условиями. Не могу больше ничего сказать про ваш случай. На моих личных десктопах при загрузке автоматически создается снэпшот корня и система потом стартует на этом снэпшоте. Ни разу связанных с этим проблем за пару лет не было.
Sign up to leave a comment.
Резервное копирование — виртуальные клоны против неконсистентных кентавров