Добавлю, что работает только в 32bit яве — да еще и проблемы с монтированием в линухе.
Иногда конкретно затупляет и приходится доставать винду из загашника.
Ну что за привязка к «раз в час»? Раз в час это я для своих задач же сказал, у меня сервера прекрасно влезают на винты в 80 гиг, где запущено 4-5 виртуалок + место под бакапы другого сервера.
Как правило 1 виртуалка это 10 гиг.
10 гиг за час вообще не являются проблемой.
Если бакапить надо терабайт — то там и время между запусками бакапов должно быть пропорционально увеличено.
Скажем так — не запускать новый раньше завершения предыдущего + некая дельта.
Что касается стоимости — если считаются ёпсы, то ёпсы бакапа считать как обычные, имхо. Это как раз будет стимулировать не делать бакапы чаще необходимого.
Нам не надо цепочки. бакап должен лежать в другом углу комнаты для защиты от метеорита.
Процесс бакапа:
1. Включили снапшот.
2. Копируем снапшот в бакап-спейс (можно rsync)
3. Убили снапшот.
Для ускорения пункта 2 можно ввести к блочному устройству дополнительный журнал возрастов, где для каждого 1-16-128M пространства вести счетчик числа записей. Не биты COW, а именно счетчик записей. тогда надо будет перекопировать только те блоки, чей счетчик больше чем в прошлом бакапе.
Так же и инкрементальные делаются.
А просто инкрементальные снапшоты это совсем не торт — они для хранения «на том же месте» заточены — если бакап стоит отдельные деньги, лучше его хранить в другом месте, и тогда у нас всё те же O(1).
Да, задержки на счетчик есть — но они уже невелики по сравнению с ведением полноценного бакапа, да и писать на диск их не обязательно часто — достаточно флага «грязности». Если счетчики помечены грязными на диске — считать всё грязным и не полагаться на них.
2Тб раз в час не выйдет, хотя если снапшот то вполне.
А в чем проблема с цепочками? Вот у нас есть блок, помеченный снапшотом. Вот в него записали — блоков стало два. Вот и аккаунтим 2 при этом.
Амазон же как-то аккаунтит снапшоты без больших проблем. Только по размеру диска.
А усложнение дисковых операций — тут я не вижу проблем. что одна машина создаёт обращения в разные места, что 100 машин — всё равно упирается в кеш же.
Могу посоветовать LCard — достаточно дешевые вешающиеся на USB калиброванные и поверенные АЦП. Я на них подцеплял электронный микроскоп — вместо монитора оператора. Няшно :)
Приматам его не дают :( Но зато читают теорию ведения эксперимента. По-моему в рамках численных методов нам его читали.
Но на хабре тут была неделя идиотских испытаний — измерение не пойми чего, не пойми чем, с непонятно какой трактовкой никаких результатов. Грустно это.
Мне нравится техника а-ля амазон/клодо — стоимость фактического места на диске на бакап.
Вот только у клодо не хватает важного — кнопочки «периодичность».
То есть я бы хотел держать два бакапа, один обновляется каждый четный час, второй каждый нечетный час.
Таким образом даже в случае астрального краха невовремя один да окажется целостным.
Не стоит. Очень интересно. Сам люблю полазить в глубинах.
Вот только дешевле взять более другую БД или более другое железо, чем тратить кучу времени на вот такие разбирательства.
Как приятно читать статью, где производят измерение с описанием как измерять, что измерять, и какие сторонние влияния.
Когда смотришь как прицепляют 20тилетнюю термопару к готовой «всё-в-одном-на-заводе-калибровано» микросхеме и утверждают что поверенный прибор из термосопротивления врёт — хочется тихонечко вздохнуть.
Если у вас оптимизация БД дошла до точки «лезть в исходники», то вы используете не свой инструмент не для своей задачи.
Оставьте мускулу простые задачки ведения блокнотика.
Для базы используйте СУБД с реальным ACID, реальным масштабированием и нормальным анализом планов запросов.
Иногда конкретно затупляет и приходится доставать винду из загашника.
Рейд еще сильнее вызывает разброс.
Как правило 1 виртуалка это 10 гиг.
10 гиг за час вообще не являются проблемой.
Если бакапить надо терабайт — то там и время между запусками бакапов должно быть пропорционально увеличено.
Скажем так — не запускать новый раньше завершения предыдущего + некая дельта.
Что касается стоимости — если считаются ёпсы, то ёпсы бакапа считать как обычные, имхо. Это как раз будет стимулировать не делать бакапы чаще необходимого.
Процесс бакапа:
1. Включили снапшот.
2. Копируем снапшот в бакап-спейс (можно rsync)
3. Убили снапшот.
Для ускорения пункта 2 можно ввести к блочному устройству дополнительный журнал возрастов, где для каждого 1-16-128M пространства вести счетчик числа записей. Не биты COW, а именно счетчик записей. тогда надо будет перекопировать только те блоки, чей счетчик больше чем в прошлом бакапе.
Так же и инкрементальные делаются.
А просто инкрементальные снапшоты это совсем не торт — они для хранения «на том же месте» заточены — если бакап стоит отдельные деньги, лучше его хранить в другом месте, и тогда у нас всё те же O(1).
Да, задержки на счетчик есть — но они уже невелики по сравнению с ведением полноценного бакапа, да и писать на диск их не обязательно часто — достаточно флага «грязности». Если счетчики помечены грязными на диске — считать всё грязным и не полагаться на них.
А в чем проблема с цепочками? Вот у нас есть блок, помеченный снапшотом. Вот в него записали — блоков стало два. Вот и аккаунтим 2 при этом.
Амазон же как-то аккаунтит снапшоты без больших проблем. Только по размеру диска.
А усложнение дисковых операций — тут я не вижу проблем. что одна машина создаёт обращения в разные места, что 100 машин — всё равно упирается в кеш же.
Но на хабре тут была неделя идиотских испытаний — измерение не пойми чего, не пойми чем, с непонятно какой трактовкой никаких результатов. Грустно это.
Ценою потери целостности и вообще данных в случае слёта питания — например, БП навернулся.
Вот только у клодо не хватает важного — кнопочки «периодичность».
То есть я бы хотел держать два бакапа, один обновляется каждый четный час, второй каждый нечетный час.
Таким образом даже в случае астрального краха невовремя один да окажется целостным.
Вот только дешевле взять более другую БД или более другое железо, чем тратить кучу времени на вот такие разбирательства.
Когда смотришь как прицепляют 20тилетнюю термопару к готовой «всё-в-одном-на-заводе-калибровано» микросхеме и утверждают что поверенный прибор из термосопротивления врёт — хочется тихонечко вздохнуть.
Бакапы есть?
А если НЕ найду?
:)
А если найду?
Оставьте мускулу простые задачки ведения блокнотика.
Для базы используйте СУБД с реальным ACID, реальным масштабированием и нормальным анализом планов запросов.