From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FUZZY_XPILL autolearn=no version=3.2.5 Date: Mon, 9 Jan 2012 14:11:59 +0200 From: Michael Shigorin To: =?koi8-r?B?69XM2NTV0s7ZyiDPxtTP0MnL?= Message-ID: <20120109121159.GE16304@osdn.org.ua> Mail-Followup-To: =?koi8-r?B?69XM2NTV0s7ZyiDPxtTP0MnL?= References: <20120103075555.GD16304@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [room] =?koi8-r?b?8sHa0sHCz9TLwSDNxcjBzsnazcEg0sXaxdLXydLP18HO?= =?koi8-r?b?ydEg18nS1NXBzNjO2cggzcHbyc4=?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shigorin@gmail.com, =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 12:12:05 -0000 Archived-At: List-Archive: On Tue, Jan 03, 2012 at 05:50:44PM +0400, Илья Кучмин wrote: > > Есть такое. > Под словом "перекрестный" предполагаю хранение резервных копий > непосредственно на HW. Я понял как "взаимное предоставление хостами с расположенными на них контейнерами друг другу стораджа для бэкапа". > >> Особенно если учесть, что винчестеры нынче дешевые, да и > >> raid обычно нулевой используется. > > Тот, кто с дешёвыми винчестерами использует raid0 для данных, > > испытывает судьбу даже и с бэкапами.  Да и с дорогими тоже... > В данном случае от raid1 большоей пользы не будет. VPS в > основном используются для целей тестирования и разработки, > смысл backup только в том, чтобы в короткие сроки развернуть > машину на стороннем HW. А-аа, ну так это существенное уточнение. Возможно, Вам лучше посмотреть в сторону существующих систем для организации provisioning -- насколько понимаю, сейчас в моде Puppet. (мы работали с systemimager.org) > В идеале, если требуется стабильность, имеет смысл собирать > raid начиная с 5, но в нашем случае это слишком большие > затраты, не сравнимые с однодневными потерями. Пятёрка плоха по записи и ресурсу дисков, если что. > >> [...] соответственно должны использоваться утилиты > >> предоставленные авторами механизма виртуализации [...] > > Вы про снапшоты? > Я имел ввиду, что системе должно быть возможно указать какую > утилиту использовать для выполнения резервирования. К примеру > для выполнения резервирования машин на платформе OpenVZ хорошо > бы было испольлзовать vzdump и т.д. Если по постановке задачи делается не столько бэкап, сколько шаблон -- может быть проще останавливать VE/VM и делать просто копию. VE при практически нулевой активности можно бэкапить и на ходу, хотя риск неконсистентности при этом всё же есть. Ещё может быть интересно эти шаблоны попросту выпекать под задачу -- на альтовской (прямщас) пакетной базе пилю mkimage-profiles: http://www.altlinux.org/Mkimage/Profiles/m-p -- но это требует возможности в существенной степени формализовать задачу VE. > > Не проще ли слать их более-менее гарантированным транспортом? > Когда я говорил о не гарантированных обновлениях я предполагал > вариант, когда клиент выпал из сети. В таком случае сервер > пишет в лог что уведомление не доставленно и в дальнейшем не > пытается его доставить повторно.(По аналогии с notify в DNS Возможно, стоит описать собсно задачу, а не фрагмент видимой реализации. > >> Прошу читателей покритиковать предложенную схему backup. > > Вы знакомы с bacula?  Там достаточно гибкая и шаблонируемая > > схема организации распределённого бэкапа, хотя возни при > > реализации (и времени на освоение базовых вещей) прилично. > Про bacula читал, но не использовал. Если не сложно поясните > как ее можно применить в моем случае. Как минимум там уже реализованы работающие бэкапные и стораджевые агенты, плюс управляющая логика. Возможно, под Вашу задачу не подойдёт, но посмотреть стоит -- хотя бы ради того, чтоб не решать уже решённое на концептуальном уровне. > Мне кажется основная проблема в том, что в bacula процесс > резервирования инициируется единым сервером, через клиентов на > HW. В тоже время я хочу обратной ситуации, чтобы более > скурпулезно управлять процессом резервирования в зависимости от > нагрузки HW и активности использования VPS. Да, bacula нацелена на снятие головной боли ручного управления. > Возможно я зря этого хочу, если вы считаете также то прошу > указать на это. Попробуйте сделать небольшой прототип и поиграться с ним, чтобы понять, насколько будет необходимо человеческое внимание. Осторожно только с тем, чтоб не влопатить туда нечаянно слишком много рабочего кода: можно попасть на "о, так у нас уже есть решение" и прототип пойдёт в дело, к которому не готов в принципе. У меня обычно ощущения складываются за две-четыре недели таких экспериментов... > >> Также если вы знаете об инструментах которые полностью или > >> частично реализуют необходимый функционал, прошу указать их. > > Возможно, http://wiki.openvz.org/Partners#Openwall; > Не до конца понял в какой форме они осуществляют процесс > резервирования. Если использовали прошу поделиться опытом. Нет, не использовал -- ссылку дал с тем, чтобы если покажется интересным -- связались сами. Люди в проекте OpenWall, с которыми довелось общаться -- крайне вменяемые, как минимум Solar Designer ещё и русскоязычный. > Про bacula почитаю подробнее, насколько я понял это самый > распространненный инструмент. Не знаю насчёт самого распространённого, но не исключено, что самый развитый; спроектирован и реализован тоже неплохо. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/