Компания Veeam, выпускающая ПО для резервного копирования и восстановления после аварий, предложила для включения в состав ядра Linux модуль blksnap с реализацией механизма создания снапшотов блочных устройств и отслеживания изменений в блочных устройствах. Для работы со снапшотами подготовлена утилита командной строки blksnap и библиотека blksnap.so, позволяющие из пространства пользователя взаимодействовать с модулем ядра через ioctl-вызовы...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58062
По описанию -- годная вещь. Костыль, конечно. Но не только лишь каждый может позволить себе пользоваться продвинутыми файловыми системами, для которых не требуется таких костылей.
Ну это создано чтобы делать бэкапы виртуальных машин, независимо от файловых систем.
причем тут виртуальные машины? qemu умеет снапшоты, например.
оно как раз может быть удобно для физических.
> причем тут виртуальные машины?так у авторов. Возможно, они что-то знают, чего ты не?
> qemu умеет снапшоты, например.
снапшот-снапшоту рознь...
> оно как раз может быть удобно для физических.
У физических есть одна проблема, догадываешься, какая?
В случае lvm и прочих не-совсем-физических ее, правда, нет, но им эта технология и не требуется, они и так умеют. Правда, есть нюансы...
1. Нихера они не знают;
2. я с Вами не пью.
> Ну это создано чтобы делать бэкапы виртуальных машин, независимо от файловых систем.Нет. Это сделано чтобы снепшотить любые блочные устройства. Я так / серверов бэкаплю - очень удобно. Еще удобнее, что теперь это можно и без Veeam использовать. LVM для этих целей тоже можно, но не так удобно.
Простите, сколько серверов вы бэкапите? я числа / не знаю.
> Простите, сколько серверов вы бэкапите? я числа / не знаю.Следует читать как "я так корневую ФС серверов бэкаплю"
а супервизор это делать не умеет?
> Ну это создано чтобы делать бэкапы виртуальных машин,У них свой cow давно был, зачем им это счастье?
Каждому достаточно делать регулярные бэкапы критически важных ДАННЫХ, и надобность в подобных хренях отпадает.
Эээ… Данных… Тут приходится процессы дампать, чтобы в случае чего не потерять все часы-дни рендера, а ты о таких мелочах печёшься. Хотя если база данных навернётся, это будут тоже невосполнимые потери. Пытаешься найти баланс между постоянными остановками прода и количеством потерь в случае БП.
А может не надо часы-дни рендерить. Както накладно выходит, лучше постаринке.
А как оно, по-старинке? Разрешения картинки до 360p, из кодеков только mpeg2? VHS предел мечтаний? Даже если тот же x265 параллелится куда лучше x264 и с меньшими артефактами (тот вообще только в 1 поток норм), всё равно потолок быстро найдётся. Быстрее просто не получится, а аппаратные кодировщики мерзость ещё та. Если ресурсы остаются, можно запустить параллельно несколько. С отрисовкой CGI получше, хотя бы аппаратно ускоряются, но тоже дело не быстрое с современным качеством картинки и разрешениями.
Я думал сейчас на аутсорс отдают на рендер-фермы.
> Я думал сейчас на аутсорс отдают на рендер-фермы.Да даже майнинг фермы отдают. Заплати-лети.
Ты че, а какже 16к?
> не потерять все часы-дни рендераОчевидно, для этого рендер должен сохранять нарендеренное хотя бы раз в час.
Это обещает быть хорошим приключением, я не уверен, что какой-либо тулинг любого уровня это позволяет. Сомневаюсь, что это вообще осуществимо без потерь. Лучшее, что я вижу, это либо периодические снапшоты вм, либо дампы процессов на диск. Так можно обойтись относительно малой кровью и без различных дефектов в интересных местах.
> Каждому достаточно делать регулярные бэкапы критически важных ДАННЫХ, и надобность в подобных
> хренях отпадает.окей, чувак, у нас тут навернулась база и твой банковский счет восстановлен с регулярного бэкапа. Причем наисвежайшего - полусуточной давности (извини, скорость дисковых полок все же ограничена и чаще мы не можем - не успеет дописаться предыдущий - "надобности" то нет).
Ой, твоя зарплата пришла час назад? Ну извини. А вот твои кредиты никуда не делись, не забудь оплатить вовремя.
P.S. к сожалению, админы локалхостов, у которых на самом деле вообще нет никаких важных данных, принципиально необучаемы.
Ах, да, не смотря на то что в бэкапе на твоем (кредитном) счете еще оставались последние 300 ржублей - заплатить за хлебушек ты не сможешь - твоей карты нет. И счета нет. И тебя нет. И вообще ничего нет.Бэкап, понимаешь, восстанавливается - тоже не мгновенно. На самом деле - очень-очень медленно он это делает. Пока не восстановится - базы как бы и нет, мы ж не можем обрабатывать транзакции в недовосстановленной.
Пока не восстановится - хрен тебе, а не хлебушка. Кушай пирожные, с уважением, твой банк.
Приболел? Банк, который базы без репликации юзает, это не банк, а шарашкина контора того самого админа локалхоста, о котором ты тут слюной брызжешь. Сразу видно профессионал высшего порядка
> Приболел? Банк, который базы без репликации юзаетВнезапно, и у банков слуцяется. И в базы с репликацией улетает что-то чего улететь было не должно.
И успешно реплицируется, ага.
А вот дальше - шарашкина контора типа твоей - мэдленно и пэчально поднимает свои базы с бэкапа. Я бы мог назвать поименно, но нельзя, подписал.
А у кого были снапшоты - пишет в журнал "апгрейд впопердня прошел неудачно", откатывается за пару секунд на снапшотик и снимает табличку "проводятся работы". Дальше пусть другие думают.
Я вот тоже в банке склянке работал, тоже подписывал, но срок прошел, тоже видел как диск рассыпается на сервере филиала, правда не с базами а с файлопомойкой всех филиалов города. От регианалов пришла отписка что файлопомойку надо восстановить из бэкапа, так кто ж её бекапио, на то она и файлопомойка. А вообще да, где только не работал, ни на одном месте не было чтобы нормально налажен процесс и все из-за человеческого фактора, из-за неэффективных менеджеров. Объясняешь, что нужно бэкапа нормально настроить, работает не трожь, просишь денег на обновление сервак, не дают.
омг, а причем тут репликация???
1. разговор про ситуацию, когда элекричество в проводах закончилось. обычно, заканчивается приблиз, одновременно во всем дц.
2. снапшот - он не спасет от лютого дизастера - если у тебя занулился диск от пожара, то чаще и снапшот тоже.
3. и еще. снапшот, он протухает во времени. как и обычный бэкап.
4. в таких ситуациях - может быть оч много приколов с репликацией. ну например, не все данные, которые вкомитились, зареплицировались. репликация, она может быть например отложенной. да и просто задержка для кросс-дц репликации может иметь место.
5. более того, база в таких конторах, чаще лежит на хранилке, с доступом по оптике. и снапшот, такого типа, можно делать средствами хранилки.
6. более того, снапшот, это тоже не бэкап. из снапшота, можно сделать бэкап. ну типа слить снапшот, на другую хранилку, проверить, что из него сюрприз, что-то можно восстановить в принципе и вот это всё бла-бла-бла.
7. более того, лог транзакций - он обычно не только на уровне базы данных. он обычно, еще и на уровне приложения существует. и его тоже можно перенакатывать. а там транзакции могут хранится в каком-нибудь лютом, шардированом nosql - который бэкапать вообще отдельная забава.
8. а еще, взрослые базы данных, умеют инкрементальные бэкапы, ну типа один раз забэкапил со слезами 100 терабайт, а потом доливаешь в бэкап изменения, по 10 гигабайт в день.короч, снепшоты, это вообще, для очень своеобразных случаев. и любой DBA об этом скажет.
и что репликация, это не бэкап (ну тип вкатили DELETE без условия, и прощай реплики) - тоже азы.
> омг, а причем тут репликация???
> 1. разговор про ситуацию, когда элекричество в проводах закончилось. обычно, заканчивается
> приблиз, одновременно во всем дц.Ну, у хорошего банка есть и второй (правда там тоже фокусы есть, но местным экспертам до них как до луны), и даже третий.
> 3. и еще. снапшот, он протухает во времени. как и обычный бэкап.
Э, не совсем, хотя в конце-концов да, протухает если специально не помогать, умеют это исключительно редкие и кривые системы.
Но вот время восстановления - оно разное.> 5. более того, база в таких конторах, чаще лежит на хранилке, с
> доступом по оптике. и снапшот, такого типа, можно делать средствами хранилки.эх... в общем, не работал ты с ними, да?
Можно. К счастью, не особо кому нужно.
> 6. более того, снапшот, это тоже не бэкап. из снапшота, можно сделать
да. crash-consistent (то есть неконсистентный ни разу - то ли взлетим, то ли недалеко и все больше вниз)
> 8. а еще, взрослые базы данных, умеют инкрементальные бэкапы, ну типа один
они инкрементальные ресторы не очень быстро умеют. Вот поэтому и храним отдельно снап, отдельно логи.
> и что репликация, это не бэкап (ну тип вкатили DELETE без условия,
alter table там обычно, в реальной жизни.
Но легче потом не стает.
> Ну, у хорошего банка ...Это, например, какие?
> элекричество в проводах закончилось. обычно, заканчивается приблиз, одновременно во всем дц.Но серверы этого не замечают, потому что в подвале есть большая комната с батареями и вторая, с дизелем, который при проседании на любом из трёх вводов заводится и выходит на обороты кратно быстрее, чем заканчивается заряд батарей. А чтобы было чем топить дизель, в землю между стоянкой и кафетерием закопаны два огромных танка на полтонны горючки каждый. И трак притаскивает цистерну со свеженьким топливом когда первый танк пустеет наполовину, даже если на дворе 4 утра 1 января. Единственное, чем отличается пропадание питания от штатной работы ДЦ — ощущение лёгкой вибрации и низкочастотный гул дизеля. Если в вашем ДЦ не так — это не ДЦ, а просто большой шкаф для ненужных серваков где-то в офисе ООО «Рога и Копыта».
Забавно, что абсолютно всё о квалификации человека можно сказать по тому, путает ли он репликацию с бэкапом :)
И чем же разовая репликация например FS отличается от бэкапа, при условии хранения архивных журналов базы данных, которые потом можно накатить хоть на базу восстановленную из бэкапа или из ZFS реплики (снэпшота или даже вот такого снэпшота как в онтопике)?Непонятен также и батхерт от delete from table_C, отправленного в реплику при условии сохранения всех архивных логов. А если реплику еще и снэпшотят, то она не хуже бэкапа в общем-то.
Но вообще-то реплика в первую очеред конечно нужна для других целей типа обеспечения HA и/или HL :)
...а если там ещё и массив ребилдится...
Это же основные эксперты опеннета. Они и в программировании сильны, и админы отличные, сетевики топ уровня, а заодно и безопасники.Им всё ненужно. У них всё есть. В крайнем случае сбацают аналог на любимой Сишечке за пару часов. Без единой ошибки!
И что не так ?
угу. сбацаем. умеем, понимаешь. но не переживай, скоро вымрем, и останетесь вы окончательно с жабоскриптерами и прочими молодыми талантливыми. я в это не верю, но так хочется, чтобы загробная жизнь таки была, и я мог посмотреть и поржать.
> верю, но так хочется, чтобы загробная жизнь таки была, и я
> мог посмотреть и поржать.Там, того, с раскаленным колом в заднице особо не поржешь...
Или в процессе строительства в ледяной пустыне лодки из ногтей, тьфу... Я в целом последнее время склоняюсь к тому, что ад скорее близок к скандинавским идеям, а не этих послехрамовых сектантов.
А разве Нагльфар ещё не построен? Я так думал оно просто стоит ждёт ...
Ну хрен знает... по идее, он сразу после достройки должнен вроде был и отплывать.
С другой стороны, учитывая сколько лет уже не принято следовать прекрасной традиции обстригать ногти покойникам - давно уже могли и достроить, и сейчас как раз грузят армию на борт.
а при чём тут ад? нет никакого «посмертного справедливого воздаяния», ада, рая, всей вот этой чепухи. если вдруг какой-то механизм сохранения самосознания после смерти физического тела и существует, то он не имеет отношения к морально-этическим концепциям — как и вся остальная природа.
> а при чём тут ад? нет никакого «посмертного справедливого воздаяния»ну те вот сектанты считают что есть (справедливость там, правда, 2000 лет назад отменили, а то дорога в рай заросла нафиг, но стало от чего-то только хуже)
А у скандинавов справедливостью и не пахло даже - сподобился умереть с оружием в руке и сохранить, что немаловажно, большие пальцы - к Одину на пир, и совершенно неважно что ты там в жизни натворил, воруй, убивай, е-и гусей - но меч из руки не выпускай даже во сне. Сдох как неудачник - в Хель, будь ты хоть сам Бальдр.
> как и вся остальная природа.
в живой природе все в общем нормально с моралью и этикой. Иначе бы меня давно сожрали.
Если механизм сохранения самосознания существует а возможности взаимодействия с другими сознаниями нет - то вот тебе и ад (причем, надо заметить, что вот ТАКОГО ада избегают абсолютно все духовные направления - кроме как раз той секты. Впрочем, и там лишь часть сектантов следуют этой идее, она сравнительно новодел, и там она невечна, хотя как по мне долго-то и не надо). А если есть взаимодействие, то опять здравствуй этика и мораль.
>Это же основные эксперты опеннета. Они и в программировании сильны, и админы отличные, сетевики топ уровня, а заодно и безопасники.Главное иметь понимание, что это должны быть четыре разных человека. Мне тут не так давно, одному айтишнику начальнику пришлось объяснять что админ виндовых серверов, сетевик и первая линия техподдержки это три разных человека. Он был уверен что этим должен заниматься один человек за копейки.
> Главное иметь понимание, что это должны быть четыре разных человека. Мне тутначальник, самый главный начальник, экзекьютор и собственно тот раб. Примерно так обычно и устроено.
> не так давно, одному айтишнику начальнику пришлось объяснять что админ виндовых
> серверов, сетевик и первая линия техподдержки это три разных человека. Он
> был уверен что этим должен заниматься один человек за копейки.Если его регулярно пороть - куда ж он денется.
Вон у юзера ниработаит. Кто должен разбираться, кабель он креслом переехал или винда краденая крива? Экзекьютор, что-ли?
К тебе обратились, ты и чини. БЕГОМ!
К тому же ты не хочешь чтоб тебя стало трое. Потому что копеек у начальников ограничено, и тебе достанется совсем мало. (Нет, я понимаю что ты-то надеешься побыть админом серверов, которому больше всего почета и уважения и денег тоже, но мой тебе совет - переучивайся на экзекьютора, раз в начальники не взяли.)
Ну что поделать, современное ойти :-( Где первая линия никогда не станет второй, потому что некогда, картридж иди тряси быстрее.
Поэтому я и хотел переквалифицироваться в выгул собак. Пока не оказалось что страну мы проcpaли и выбор теперь совсем между другими сортами.
>начальник, самый главный начальник, экзекьютор и собственно тот раб. Примерно так обычно и устроено.Да там рога и копыта.
>Вон у юзера ниработаит. Кто должен разбираться, кабель он креслом переехал или винда краденая крива? Экзекьютор, что-ли?
Разбираться должен эникейщк.
>К тому же ты не хочешь чтоб тебя стало трое. Потому что копеек у начальников ограничено, и тебе достанется совсем мало. (Нет, я понимаю что ты-то надеешься побыть админом серверов, которому больше всего почета и уважения и денег тоже, но мой тебе совет - переучивайся на экзекьютора, раз в начальники не взяли.)
Я побыл виндовым админом и линуксовым побыл, мне этол уже не интересно. В результате он меня послушал и нанял виндового админа и сетевика, правда сетевика не потянул и уволил и сам стал за сетевика, а вот я уволился, нервы дороже, да и без работы не сижу. Переучиваться на экзекьютора не вижу смысла, т.к. уже бэкэндер а планиную фуллстак стать.
Любая обезъяна может выучить Питон и податься в погромисты.
> Любая обезъяна может выучить Питон и податься в погромисты.Дык, в этом и трагедия. Вон от гуаноуслуг пришло письмо щастья - не желаю ли я своего пе3дюка отправить на курсы впихона с хорошей скидкой.
Так все бананы сожрут и без тебя. Я по этой причине полагаю правильней тренировать те скиллы, которым в яндексбиолабораториях не учат.
> Дык, в этом и трагедия. Вон от гуаноуслуг пришло письмо щастья -
> не желаю ли я своего пе3дюка отправить на курсы впихона с
> хорошей скидкой.Могут и что поинтереснее прислать, повестки там всякие :)
>> Дык, в этом и трагедия. Вон от гуаноуслуг пришло письмо щастья -
>> не желаю ли я своего пе3дюка отправить на курсы впихона с
>> хорошей скидкой.
> Могут и что поинтереснее прислать, повестки там всякие :)Кто не успел сдать пе3дюка на курсы впихона - сдаст на мясо, в чем проблема вообще? Или ты, сволочь, не патриот?!
Максут кстати письмо прислал, электрическое. Что получателей отсрочки уже хватит, новые "IT-компании" больше регистрировать не будут, документы у новых обитателей старых тоже не принимаются, и вообще пора проредить число этих итшников, далеко не все они такие ценные как казались.
Подобная база данных на единственном девайсе, в 1ом экземпляре? Тебе не кажется, что это какая-то минимум странная архитектура системы? ;)
А теперь скажите как от этого спасут снапы через 5 минут и какой будет оверхед? Кластер надо строить нормально. Периметр защищать.
Вы не учитываете затраты на все это. Одно дело откатить, а другое дело - копировать огромный массив данных.
Пока список этих критически важных данных соберешь, можно уже и весь диск забекапить, особенно если под торренты отдельный диск, который не нужно бекапить.
Я не совсем понял эта демонюгпа работает с блоками устройства или на уровне файловой системы? Если первое, то какие там имена файлов и структура?
Ну да теперь расширился круг виноватых. То ли сама файловая система то ли демон то л ссора между ними.
Всю жизнь было доступно с помощью dd.
🤝
Браво!
Снапшот включенной вм с помощью dd? Удачи вам и вашим данным с таким подходом.
снапшот включенной вм обычно делается средствами гипервизора - которому гораздо проще зафиксировать состояние "дисков" и куда-нибудь на время складировать все перезаписываемые блоки.Но, видимо, к модным-современным-из-гуана-зато шва6оооодка kvm-based это не относится?!
Не то чтобы я удивлен, конечно... но я думал о вас лучше.
"kvm-based это не относится"man lvm?
ну или почитайте про снапшоты в qemu прежде чем нести чушь.
> "kvm-based это не относится"
> man lvm?причем бы тут? И нет, его снапшоты не консистентны в пределах системы и ни малейшей возможности их таковыми сделать.
> ну или почитайте про снапшоты в qemu прежде чем нести чушь.
мне неинтересно вашу чушь читать. Я спросил - у вас правда так все плохо как предполагает разработчик новой модной технологии, уже почти включенной в ядро?
Судя по неумению ответить прямо на заданный вопрос - вы не в курсе, следующий!
>И нет, его снапшоты не консистентны в пределах системы и ни малейшей возможности их таковыми сделать.кхммм, само понятие "снепшот" по определению должно включать консистентность (согласованность).
> само понятие "снепшот" по определению должно включать консистентность (согласованность).Три раза ха.
Они придумали хитрые термины, тут уже писали же про crash consistent snapshot.
Типа он consistent, но есть ньюанс....
> Три раза ха.гип-гип
> crash consistent snapshot.
ну, в студию определение данного термина
> кхммм, само понятие "снепшот" по определению должно включать консистентность (согласованность).чего с чем?
Вот у тебя volume, предположим, с массивом базы на жестких дисках.
Вот втрой - с кэшем или там логами - на ssd собран, чтоб побыстрее.Ой? Снапы-то per volume.
> чего с чем?данных на диске
> Вот у тебя volume, предположим, с массивом базы на жестких дисках.
> Вот втрой - с кэшем или там логами - на ssd собран,
> чтоб побыстрее.
> Ой? Снапы-то per volume.Ой, а мы микроскопом уже гвозди забиваем? С чего это механизм консистентного снепшота ФС должно волновать консистентность данных какого-то приложения (той же базы)? Зачем тогда для баз предъявлять всякие ACID?
> Ой, а мы микроскопом уже гвозди забиваем? С чего это механизм консистентногону если от него толку никакого вообще - можем им и печку топить.
> снепшота ФС должно волновать консистентность данных какого-то приложения (той же базы)?
а на гуя нам консистентные снапшоты фс? Мне лично fs вообще без надобности. Мне данные нужно сохранить. А они в описываемом сценарии - вот-съ, в кашу-съ.
> Зачем тогда для баз предъявлять всякие ACID?
совсем не для этого.
Дай угадаю, ты тоже фулшмяк девелопер, да?
А вот те пацаны которые костыль blksnap придумали - они, похоже, да, догадываются о чем-то...
>> Зачем тогда для баз предъявлять всякие ACID?
> совсем не для этого.
> Дай угадаю, ты тоже фулшмяк девелопер, да?я вот его прогнать хотел, а теперь считаю, что зря: иногда любопытно заглянуть в сознание плесени, которая думает, что она думает. я вот до недавнего не знал, например, что ACID — это, оказывается, чтобы вытаскивать данные из каша-бэкапов.
всё-таки хорошо, что я детей никогда не планирую: мне поэтому не страшно, а смешно.
>что ACID — это, оказывается, чтобы вытаскивать данные из каша-бэкаповв студию где такое написано
судя по неумению правильно задать вопрос- вы ничего не понимаете ;-)
Хуже ипанутых на всю голову снэпшотов ESXi, еще ничего не придумано.Мало того, что они жутко тормозят гостевуху пропорциАнально количеству снапшотов, так еще могут отказаться мержиться с ашипкой, а х.з. номер XXXXXX, не гуглится.
Зато апгрейд ESXi до следующей версии может внезапно (за полчаса +) смержить (удалить) снэпшот. Этаж какое счастие то было, когда снэпшот смерджился. С тех пор только ZFS, KVM, OpenNebula и другой опен сорц, ну их в *епу, все эти ESXi.
Может быть, кому-то и нужна непрерывная availability с миграцией виртуалок, где приложения (под DOS LOL) сами не умеют в HA, ну купите им vSphere за дохуллиард баксов, ога. В клауд натив не проще переделать?
Ну да, а чудо-костыль спасет ) Парни пиарятся, это лучше чем ничего. Пугают местные строители которые бросаются это встраивать это куда-то кроме локалхоста. Ну умные то на нормальную систему расчитывают, по крайней мере единое решение.
Так qemu и раньше далал такие же снапшоты что и в описании, но формат нужен qcow2
А в чем он не прав? Он сказал Вам где он применяет dd? Зачем Вы додумываете? На вскидку этот чудо-костыль выглядит как реклама основного продукта.
Выглядит надёжно, примите наши аплодисменты.
снапшот живого носителя БЕЗ снапшота работающих на нём процессов... знатно авторы курнули.
> Ну это создано чтобы делать бэкапы виртуальных машин, независимо от файловых систем.
> Снапшот включенной вм с помощью dd? Удачи вам и вашим данным с таким подходом.оно всего навсего делает crash consistent sanpshot, это как если питание выключить. но на всех дисках аднавременна, да, в отличие от ДД.
База с софтового рэйд может и восстановиться, если повезет, , но скорее всего не быстро и с откатом транзакций, после того как рэйд починиться.
Не совсем - процесс отключения питания, к сожалению, не мгновенен. Современные диски очень, очень такого не любят.Нормальная база с double buffer writes (ни на что не намекаю) кстати, да, восстановится. И заново из лога накатит транзакции, о которых сообщила что они - завершены. (А если она не уверена что они в лог попали - то и не сообщает).
Но то - нормальная. А у тебя - поцргрец про, импортозаместительный. Поэтому он не поднимается вообще. Но мы уже послали запрос в контору-импортозамещятель и с нетерпением ждем ее ответа. Как придет - уведомим тебя письменно.
так постгрес, собссно работает по той же схеме.
лог транзакций, откат-накат в случае крэша, и прочие радости.
не сильно понимаю в чем превосходство господина. чэсн.
> так постгрес, собссно работает по той же схеме.дык, эта, тово - ниработает. sig11
> не сильно понимаю в чем превосходство господина. чэсн.
э... вот...
https://postgresqlco.nf/doc/en/param/full_page_writes/
> https://postgresqlco.nf/doc/en/param/full_page_writes/ну включи, включи на проде.
Ну не знаю как модный, современный postgre ... Но 9 вообще не поднимался после отключения питания ... да да, логи были, но прочитать он их не может и вылетает по signal (хз может и 11 - давно это было). Oracle такое вытворял как раз только на raw-устройствах (за которые тут сильно ратуют).А вообще - вопрос ... А когда кто-то вообще БД с бакапа подымал ? Чёт я тут попробовал на днях проверить, а что мы каждый божий день делаем ? Да как-то тестовое восстановление не очень большой БД (где-то 10Тб) заняло почти сутки ... Нахрена, спрашивается нужен такой бакап ?
Так что, похоже, только репликация спасёт ...
точно? у нас несколько сотен касс, разумеется, отключения питания бывают сплошь и рядом.
не так давно там был именно 9-ый постгрес, сейчас 11.всё работает.
> Ну не знаю как модный, современный postgre ... Но 9 вообще неподсказываю: структуры хранения данных ни разу не изменились. Их как в 95м году придумали, так и остаются ;-)
> А вообще - вопрос ... А когда кто-то вообще БД с бакапа
> подымал ? Чёт я тут попробовал на днях проверить, а чтону я инвалид :-(
> мы каждый божий день делаем ? Да как-то тестовое восстановление не
> очень большой БД (где-то 10Тб) заняло почти сутки ... Нахрена, спрашиваетсяхорошие у тебя диски... А я неделю валандался.
> нужен такой бакап ?
Ну, типа, иногда некоторые лавки с потерями, но переживают. Типа не весь мир еще к счастью виртуальный, можно деньги принимать налом, а приходник на БСО выписывать. А потом работать 24/7 чтоб все это вернуть в онлайн.
> Так что, похоже, только репликация спасёт ...
Ну кому как. Этим может и ок - во-первых, разумеется, за это 24x7 заплатили вовсе не по ТК.
А типа либо мы поработаем, либо сразу можем все искать новую работу. Оне чавота не захотели.Во-вторых репликация не факт бы что и спасла. (теперь у тебя две дохлые реплики)
В-третьих если сравнить потери от "сцайт не открывается" аж неделю раз в пять лет и цену хостинга такого - и не забываем чтоб подальше от оригинала, плюс канал позволяющий такое, плюс кто-то кто может потом починить если репликация развалится, а оно, вот - вполне возможно, оно и в десять раз отличается.
А Вы бы поднялись? Есть бесперебойное питание (хотя бы какое-то время) или распределенный кластер.
> у тебя - поцргрец про, импортозаместительный. Поэтому он не поднимается вообщеа что с посгресом не так? это же база данных и должна восстанавливаться после отключения питания.
>> у тебя - поцргрец про, импортозаместительный. Поэтому он не поднимается вообще
> а что с посгресом не так? это же база данных и должна
> восстанавливаться после отключения питания.ну...э...короче просто не имей дело с теми, кто на это рассчитывает.
А то оно потом спрашивает - "должна? Расписку покажи!"
тот самый момент, когда постгрес умнее какого-то пох.-а, и последний об этом узнал...
Уважаемый, если у Вас не восстанавливается, то это не значит вообще. И почему Вы тут переходите на политику? Есть нормально построенные комплексные решения, которые сидят на постгрес. Люди просто пограмотнее Вас и не Экают. Простите - не сдержался.
Я знал что придешь в топик :)> ... Современные диски ...
Разрешите перефразировать, запамятовал, вместо "это как если питание выключить. но на всех дисках аднавременна, да"
следует читать "это как если kernel panic наступил, цвет консоли по вкусу"> Нормальная база с double buffer writes (ни на что не намекаю)
И несмотря на отсутствие намёков в моей голове звучит - ИннаДБ!!!
Они там в MariaDB даж его пытались выпилить :)))
https://mariadb.org/significant-performance-boost-with-new-m.../
Да, я понимаю в общем как надо, и что сначала еще надо постараться найти какие именно гарантии
предоставляет, если предоставляет вообще, именно это ЗУ.> А у тебя - поцргрец про
Сначала рэйд собрать....
Вобщем, подъитоживая флэйм - ниже аноним все в ответе тебе хорошо объяснил,
без application aware VSS writer тяжело.Хотя большинство делает просто ДД и это как-то работает в большинстве редких случаев,
когда таки приходиться восстанавливать из снапшота.
Соответственно денег за сделать правильно не платят.
> следует читать "это как если kernel panic наступил, цвет консоли по вкусу"Ну тоже не совсем - паник может наступить поздновато, уже поназаписывав каши из поврежденных буферов (то есть собственно, откуда по твоему адские крэши zfs и btrfs)
А тут чпок и отрубилось все. Ближе всего - схдшный свитч вырубить на ходу - пол-пакета она не примет и не запишет.> без application aware VSS writer тяжело.
vss не умеет поцгреза в wsl, к сожалению. А то б я несомненно рассмотрел такое редкостно ушлепское решение, не пропадать же добру.
> Хотя большинство делает просто ДД и это как-то работает в большинстве редких
> случаев,Ну я вот напоролся на, кстати, иннодб, не желавшую подниматься даже с магической шестеркой
после такого "dd". Причем я бы там согласился на потерю всех данных новее пары месяцев, лишь бы вообще запустилось и от меня отстало, но хрен там. Как раз из-за неконсистентности - логи уехали вперед от состояния базы, и совсем без логов оно оказывается тоже не может.
Энтерпрайзные Toshiba умеют при отключении питания сбрасывать на диск кеш записи.
> Энтерпрайзные Toshiba умеют при отключении питания сбрасывать на диск кеш записи.дык кэшей-то не один. Еще в памяти есть. И тоже может быть не один.
А это - просто костылик, позволяющий им чуть раньше отрапортовать что запись закончена (именно потому что нам-то не важно на самом деле, чем она там закончена, важно чтобы потом прочиталось именно это) и выиграть в каких-то соревнованиях энтерпрайзных плевков в длинну.
Вы сейчас про энергонезависимую оперативку в рейд контролере? Это не особенность фирмы, это стандартное решение. Здесь речь про кэш работающих процессов в оперативной памяти. Почему то все додумывают, что это чудо-костыль помогает от самого страшного краша. ) Только дисковая система, господа и быстрый снап , чтобы не бэкапить все блоки.
Чет мне кажется ты не разбираешься в поцгресе, у него как раз есть и wal и по дефолту ждет подтверждение от системы про запись на диск.
Ну тут много экспертов которые круты во всем, лишь бы похаливарить )) По мне разработчикам БД надо крупными буквами писать - о бесперебойности питания должен позаботиться потребитель продукта. )
Нет. Перед созданием снапшота вызывается freeze_bdev() https://www.kernel.org/doc/htmldocs/filesystems/API-freeze-b... .
Это позволяет обеспечить консистентность файловой системы и завершение всех запросов на блочное устройсто.Подробности о том как это примерно работает можно послушать тут https://www.youtube.com/watch?v=eoQyNSezY4U.
это примерно работает нифига не лучше dd. возможно, для кого-то это станет сюрпризом — но практически никакой софт не оперирует блочным уровнем, почти все, внезапно, оперируют файлами со сложной внутренней структурой. которая влёт оказывается неконсистентной что с flush, что без. но, конечно, верить в волшебные бэкапы это никак не помешает.
Не ври бесстыдник, почитай лучше про zvol.
> Не ври бесстыдник, почитай лучше про zvol.что, оно магически обеспечивает консистентность файлов данных для произвольного набора программ? не употребляй больше то, что ты употребляешь.
Нет конечно, речь не о консистентности данных приложений, а хотя бы об одновременности разных участков данных такого среза (снэпшота).
В ZFS одновременность есть, а dd из обычного блочного устройства ее ессно нет.
В dd из снэпшота zvol ессно одновременность есть, как-то так.Одновременность - не консистентность, но хоть что-то.
Намного хуже оказаться вообще с голой жепой.
А реально неконсистентное битое содержимое окажется в менее, чем одном проценте приложений.
Даже и придумать не могу в каких кроме СУБД, которые (по крайне мере нормальные РСУБД) как раз с потерей последних транзакций таки приведут базу в порядок. А накатив архивные логи с другого устройства мы получим полностью консистентные данные, даже те, которые были на момент факапа.
>а dd из обычного блочного устройства ее ессно нетА если это устройство на котором /boot хранится. )
А если я сконфигурирую хранение файла БД в отдельной ветке и смонтирую ее на отдельное устройство, могу я надеятся что он будет консистентный между флэшами БД? Могу я заскриптить в этот момент, когда система отчитается БД что данные сброшены на диск по флэш-требованию, dd? )
откуда лять идея о том, что механизм снепшота ФС должно беспокоить консистентность данных какой-то там БД приложения, которые растут как грибы каждый день? зачем ACID придумали для БД?
да ниоткуда, всё нормально, возвращайся на свой локалхост, тут взрослые дяди беседуют.
> тут взрослые дяди беседуют.кек, простите :)
> откуда лять идея о том, что механизм снепшота ФС должно беспокоить консистентность
> данных какой-то там БД приложения, которые растут как грибы каждый день?
> зачем ACID придумали для БД?Если хочется острых ощущений, сделать вот это вот с базой виндового контроллера домена ;)
> Если хочется острых ощущений, сделать вот это вот с базой виндового контроллера
> домена ;)сделать что? снепшот фс на которой крутиться база контроллера? ну вот делаю, и что? дальнейшие действия какие?
Если БД не консистента до бэкапа, то он не виноват, естественно. ) Но все сложно структурированные файлы хранятся в виде блоков ) консистентность БД не головная боль а поддержки серверной инфраструктуры, для этого есть админы БД.
алё, Серёжа, так ты пояснишь, как оно обеспечивает консистентность файлов данных? или это очень сложный вопрос, если на него честно ответить, то вашего слона никто не купит?
Консистентность файла данных обеспечивается приложением (если речь идёт о базе, то логами).И вы, мне кажется, немного путаетесь.
Что снапшот LVM, что blksnap - эти вещи они не вместо DD, они в дополнение к DD (или rsync, кому что).
Т.е. вы точно также можете взять снапшот диска с файлами данных и диска с логами (и оба диска будут в согласованном между собой состоянии внутри снапшота), и потом с него утянуть файл данных базы и логи в хранилище бэкапов при помощи rsync или cp, да хоть весь диск целиком при помощи DD.
Вот только с голым DD вам придётся сделать одно из трёх:
а) тормозить базу наглухо
б) лочить таблицы (для MyISAM)
в) Использовать --single-transaction перед тем как делать дамп (+ не должно быть коннекций которые используют ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, и тому подобное)Использование снапшота блочного устройства где лежит база и её логи позволяет сделать бэкап базы без даунтайма, и с минимальной докаткой по логам базы (при условии что логи попали в бэкап).
Копируя живые файлы логов и базы при помощи DD вы потом должны будете применить логи к базе, да ещё подождать пока они применятся (если хвостик логов длинный, то процесс будет небыстрым).
P.S. и слон бесплатный так-то, продавать тут нечего. Исходники все открыты, доки есть, бери да пользуйся, если скиллы позволяют (а инструмент создан как раз с расчётом на среднего админа без навыков мейнтейнера и кодописания).
> Копируя живые файлы логов и базы при помощи DD вы потом должны
> будете применить логи к базе, да ещё подождать пока они применятся
> (если хвостик логов длинный, то процесс будет небыстрым).ну да, ну да, а если сделать бэкап «блочного устройства» волшебной таблеткой — то этого делать совсем не придётся.
> P.S. и слон бесплатный так-то, продавать тут нечего.
свежо питание. *часть* инструмента пытаются засунуть в ядро, чтобы скинуть на кого-то работу по маинтенансу этой бесполезной ерундени.
> ну да, ну да, а если сделать бэкап «блочного устройства» волшебной таблеткой — то этого делать совсем не придётся.придётся, но в гораздо меньшем масштабе и происходить это будет быстрее (т.к. хвост логов будет гораздо короче) в случае с DD и без снапшота вы пока файл будете копировать логов нарастёт уже прилично. Понятие restore time objective не просто так придумали так-то.
И я не получил ответа на вопрос как вы аналогичное действие сделаете с помощью dd и без снапшота. Вы что-то очень много болтаете, и критикуете, однако взамен ничего не предлагаете : )
> свежо питание. *часть* инструмента пытаются засунуть в ядро, чтобы скинуть на кого-то работу по маинтенансу этой бесполезной ерундени.
Если бы вы хотя бы раз попытались сами отправить что-то уровня драйвера в ядро, то знали бы, что мейнтейнеры весьма щепетильно относятся к вопросу "кто будет это поддерживать", и просто скинуть на них свою работу не получится. Претендуя на отправку в ядро серьёзного фунцкионала, разработчик тем самым в 99% процентов случаев подписывается на поддержку своего кода.
> И я не получил ответа на вопрос как вы аналогичное действие сделаете
> с помощью dd и без снапшота.потому что я не собирался отвечать на дурацкие вопросы.
> Если бы вы хотя бы раз попытались сами отправить что-то уровня драйвера
> в ядроу меня для тебя плохие новости. очень плохие. можешь попробовать угадать.
А, ну я так и думал - критиковать и дуть щёки горазды, а будучи притянутыми к ответу сразу в кусты :DСидите на своём dd спокойно дальше, не смею мешать.
> А, ну я так и думалты даже смысл прочитаного текста понять не можешь, не льсти себе.
Извините, дорогие л@п4тые - я не в теме, а что - ваши гуановиртуализационные системы такое гуано что сами не умеют?
veeam умеет и на уровне гипервизоров (разных) и на уровне ОС... более того, стоящей на баре металл... а вот на уровне ESXi free не умеет, ибо разделение рынока :)
> veeam умеет и на уровне гипервизоров (разных) и на уровне ОС... более
> того, стоящей на баре металл... а вот на уровне ESXi free
> не умеет, ибо разделение рынока :)это не veeam умеет. (и не умеет)
Это вмварь (и некоторые другие) умеет такие интересные снапшоты (то есть она другие тоже умеет, и там никакой veeam не нужен - если ты признаешь мое превосходство, я тебе покажу заклинание - его, как ни странно, не знают даже многие мнящие себя админами инфраструктуры) которые не назад а вперед, и которыми пользуется не только виам а вообще все вмваре-совместимые бэкапалки.Голый Esxi их не умеет.
пох, даже для тебя это перебор )
чтобы сделать консистентный бэкап диска, в любой оси нужно погемороится. да и опять же, btrfs и zfs у лапчатых есть.
и ты всё это знаешь )
> пох, даже для тебя это перебор )
> чтобы сделать консистентный бэкап дискатам про системы виртуализации.
Я знаю две - нахаляву и даром - kvm и xen.
Какая из них не умеет снапшоты, и желательно не дисков а целиком состояния vm? Друг интересуется!
> В blksnap реализован фильтр, который перехватывает запросы на запись, читает старое значение и сохраняет его в отдельном списке изменений, определяющем состояние снапшота.Вот это фокус придумали. Без шуток, довольно интересное решение. Надеюсь, примут в апстрим.
Ну ничего такого, что не используется уже давно в Copy-on-write хранилищах, типа LVM-thin или Zvol от zfs или btrfs. Вопрос куда пишет данные, если с trim-командой не интегрирован чтобы знать свободное место, то видимо отдельное хранилище нужно будет для вытесняемых данных. Для гипервизоров конечно мало необходимости, но вот забэкапить рабочую станцию наживую без live-cd, zfs/btrfs - вполне интересно будет...
https://github.com/veeam/blksnap/blob/master/doc/blksnap_ru.md
можете подробно почитать как оно работает
Ага, интересно, спасибо! Как я понял это у них чуть получается ближе к снапшотам обычного, не thin, LVM'а.
Да, советую еще почитать про виндовую vss если тема интересна https://habr.com/ru/company/veeam/blog/560534/
Не хочу поднимать холивар, но что может быть интересно в винде и ее конторческих решениях, где за вас все решили? )
почитал
"В зависимости от потребностей и выбранной лицензии "ясно
> Ну ничего такого, что не используется уже давно в Copy-on-write хранилищах, типа
> LVM-thin или Zvol от zfs или btrfs.Ну вот представь что у тебя ДВА zpool'а - предположим, отражающих разную физическую сущность хранилищ. И как без этого костыля получить crash-consistent state? А никак.
> Вопрос куда пишет данные,
ага
надеюсь нет
коду от коммерческих компаний не место в ядре
Ващет пофиг. Коммерческие компании могут ведь делать открытые продукты. Но ьы можешь самолично собирать libre версию ядра.
Где вас таких делают то глупых.
Весь код линукса написан на деньги корпораций.
ну не весь.. 90%
Ну да, первые версии он написал ещё бесплатно.
> ну не весь.. 90%ну вряд ли там 10% осталось от первоначального кода, скорее <1%.
так что не 90, а 99%
>> ну не весь.. 90%
> ну вряд ли там 10% осталось от первоначального кода, скорее <1%.вопрос как мерять - строчками или все же проделанной работой.
Так-то вполне себе много кода написанного до нашествия пацанов с адресами @intel.com и подобными.
В основном эти ребята, как и Линус, судя по тем самым адресам, были либо студентами старших курсов, либо аспирантами хороших универов, где им позволено было на гранты страдать фигней под видом курсовиков и кандидатских.
К сожалению, они повзрослели и пошли работать в какую-нибудь трансмету. А нынешнее поколение совершенно не заинтересовано забесплатно вкалывать. Тем более при наличии гранта на гендерные штудии в разработке хруста.
Ну а гранты универам кто даёт - корпорации.
> Ну а гранты универам кто даёт - корпорации.когда-то их давали просто в режиме - сунуть денег под дверь, и потом на выходе получить просто много хорошо подготовленных студентов (а не "хорошо подготовленных" программировать в VS)
Для всего остального были - целевые гранты, на разработку.
Ну, те времена прошли, как и студенты, способные с пустого места написать какой линукс.
Снапшоты без взаимодействия с внутренним миром приложения - ну такое...
Ну или (во избежание рассогласований) всё останавливать на момент снапшота, но тогда и dd прокатит.
это просто работает. так надо.
Самое правильное (если на уровне носителя) - завершать процессы записи на носитель, чтобы приложения зафиксировали семантику данных, перевод носителя в ro, далее - хоть dd. Не завершишь запись - получишь кашу в снапшоте.
P.S. а вообще снапшотить надо не абстрактный носитель, а пользоваться инструментами конкретного приложения, чьи данные тебе так дороги.
Консистентность данных приложения обеспечивается самим приложением (в случае с базами при помощи логов).1. Хватается снапшот системы целиком при помощи blksnap.
2. Спокойно утаскивается в бэкап целиком система (или при желании только диски на которых живёт файл с данными базы + логи базы).
3. Отпускаем снапшот.База в течении всего процесса продолжает работать как будто ничего и не происходило.
При подъёме же из бэкапа база будет думать что хост на котором она стояла грохнулся по питанию, адекватные ACID compliant движки с таким спокойно справляются (если админ не накосорезил с настройками).Расскажите, как вы подобное сделаете при помощи dd?
Если же хочется более продвинутой интеграции, то перед снятием снапшота базе командуем встать в правильную позу (checkpoint на postgres, flush tables with read lock для MyISAM древнего, и так далее в зависимости от типа приложения). После того как снапшот взят, базе можно дать команду расслабиться и снять блокировки. Это всё можно сделать самописными скриптами.
> Ну или (во избежание рассогласований) всё останавливать на момент снапшотаИменно. Я так и поступаю. Перед созданием снапшота торможу докер и базу, делаю снимок, а потом всё запускаю. После этого спокойно бэкаплю снимок. Конечно, имеется простой, связанный с тем что контейнера поднимаются не слишком быстро - Конфлюенс и всё вот это вот..., но минуту-другую в середине ночи все потребители стойко переживают :D
Тем не менее это прерывание сервиса. Кому-то катит, кому-то нет. Попробуй так игровой сервер или чатик тормознуть, узнаешь о себе много нового.
> Тем не менее это прерывание сервиса.Само собой. В моем случае - подходит. Если бы докера не было, то можно было бы не останавливать - СУБД в режим логирования и вперед, на танки. В принципе, и с докером можно было бы контейнера переделать так, чтобы тома с данными биндить, а при восстановлении пересоздавать контейнер. Но последнее мне просто лень делать.
А где фанаты системд, которые должны орать что это Поттеринг уже реализовал?
Не знаю где они, но я могу покричать "переписать срочно на расте", это сойдёт в качестве замены Поттерингу?
> Не знаю где они, но я могу покричать "переписать срочно на расте",НАЧАТЬ переписывать, ну что вы каждый раз на те же грабли!
> это сойдёт в качестве замены Поттерингу?Даже превзойдет! Особенно если будешь писать правильно.
Тем более Линус хрустодрайверы в ведре - разрешил!
Похоже на снэпшоты в LVM.
"позволяющих перехватывать запросы ввода/вывода."
"реализован фильтр, который перехватывает запросы на запись, читает старое значение и сохраняет его в отдельном списке изменений, определяющем состояние снапшота"Больше снапшотов богу снапшотов. Вроде и звучит, с одной стороны занятно, а с другой... потенциальные дырени и дополнительное рeшeто вижу я
Напоминает упрощённую версию DRBD. Только в DRBD уже есть готовая синхронизация.
Если бы для файлов аналог маковской тайм машины сделали..
А бекап устройств целиком почти любая виртуалка и так умеет, а просто бэкапов, со срезами на разное время хватает тоже всяких.
Не оценил.
> Если бы для файлов аналог маковской тайм машины сделали..для zfs сделали. Но ты, наверное, не захочешь.
>> Если бы для файлов аналог маковской тайм машины сделали..
> для zfs сделали. Но ты, наверное, не захочешь.Любопытно. Как же я проспал.
К zfs отношусь нормально, но если доступ к снапшотам файлов только через консоль, без gui, то наверное таки незахочу.
Беру паузу почитать.
речь идет о системах где сотни и тысячи виртуальных машин. ваши бэкапы которые каждая кухарка умеет- не интересны...ибо нефункциональны
Тридцать тыщ одних курьеров?Ох уж эти админы локалхостов...
P.S. а майнинг-ферму никто и не бэкапает.
> Если бы для файлов аналог маковской тайм машины сделали..
> А бекап устройств целиком почти любая виртуалка и так умеет, а просто
> бэкапов, со срезами на разное время хватает тоже всяких.
> Не оценил.Не имел возможности оценить маковскую тайм машину, но разве линуксячий тайм шифт не из той же оперы?
> не из той же оперы?Из той. Но работает не так же.
На Маке изменения сохраняются при сохранении отдельных файлов, сами по себе. Можно хранилище тайм машины поместить на рам диск и сохранять только важные рабочие каталоги. Обычно с исходниками. Бывает, что то сделал и работает не так, а в репозиторий выгружал давно, и внезапно есть удобный просмотр, а что же понаписал, и быстренько найти проблему.
И место не кончается, а несколько часов изменений на всякий случай хранит.А тайм шифт это снапшоты системы, типа точек восстановления.
И интерфейс пользователя на маке ориентирован не не бекапы, а на документы, с их быстрым предпросмотром.
И оно есть очень давно. Странно, что не передрали до сих пор.
> Обычно с исходниками. Бывает, что то сделал и
> работает не так, а в репозиторий выгружал давно, и внезапно есть
> удобный просмотр, а что же понаписал, и быстренько найти проблему.это настолько прелестно, что даже не нуждается в комментариях.
Это когда свой проект годами мусолишь, всё "прелестно", и тайм машины не требуются,
а когда работаешь с железом, и собираешь на финальной стадии единое целое, а готовые модули оказались "невпихyeмые", то при правке в надцати местах, что то пропустить, или наоборот перестараться, да элементарно.
А если ещё и срочно, и все разбежались, и чего доброго в командировке..
В общем если соломка есть, почему б не подстелить заранее. ;)
btrfs-снапшоты и snapper?
в качестве гуя есть модуль yast
> копирования накопителей и виртуальных дисков без остановки работы...с мгновенной отсылкой скопированного кому надо без всякого уведомления пользователя :))))
это винда делает согласно лицензии на ее, без всяких бэкапов...
Судя по комментариям выше, местный народ в массе ни про Veeam, ни про бекапы баз данных практически ничего не знает, только фантазирует.Что касается Veeam, они предоставляют бесплатное бекапное решение для 10 машин (физических или виртуальных - неважно), т.е., отличное решение для домашней сети, так что для незнающих есть повод познакомиться. Кому как, а мне эта штука нравится. (Не во всём).
Ну, правда, сервер ставится на Windows Server, но и пробный Windows Server работает без ограничений по времени.
И, конечно, Veeam не годится для случаев, когда данные совсем терять нельзя (вроде финансовых) - для этого используют другие решения (HADR/Data Guard/etc).
С другой стороны, как и многие, они порвали связи с Россией.
>Что касается Veeam, они предоставляют бесплатное бекапное решение для 10 машин (физических или виртуальных - неважно), т.е., отличное решение для домашней сети, так что для незнающих есть повод познакомиться. Кому как, а мне эта штука нравится. (Не во всём).10 лицензий на проприетарщину, или аккаунт на 10 образов облачного бекапа?
10 виртуальных хостов для домашней сети? уровень гикнутости такого сетевладельца запредельный...
> Что касается Veeam, они предоставляют бесплатное бекапное решение для 10 машинА бесплатный объём сколько Терабайт на машину? 0.01 или типа того?
Локальное хранение несоизмеримо дешевле.> И, конечно, Veeam не годится для случаев, когда данные совсем терять нельзя
Но если кто то хочет за даром хранить даныые, то найдутся данные которые уместно так хранить.
И особенно для случаев удаленного доступа из разных мест. Это заведомо не офисное применение.
>>10 машин (физических или виртуальных - неважно)Неа. 10 виртуалок или 30 вин-компов. Для примера. У них это называется Instance и отсюда самоочевидно, что 1 инстанс виртуалки = 0,33 инстанса венды (про линуксы на физике и прочее - не в курсе).
Ну и ты копировал какой-нибудь железячный MS SQL этим Veeam-ом ? Если да, расскажи ... я послушаю.Вим - он даже виртуальный MS SQL через жо^W костыль сохраняет ... Бакапит снапшот виртуалки, и пердически лог файл... Такое себе решение ...
Снапшот блочного устройства? И куда ж оно его писать-то будет? Пахнет внезапными граблями, как впрочем и все недоподелия от этой говноконторки.
ну а винда куда пихает?
У винды это всё же на уровне файловой системы, так что драйвер фс знает где что лежит.
И у винды это не просто мгновенный снимок состояния диска, а целая церемония с запуском VSS райтеров, остановкой и сохранением на время снимка неподдерживаемых виртуалок и т.д. и т.п.
> Пахнет внезапными граблямиЕщё какими! Вот пишется большой файл, посередине делается снапшот, в итоге часть файла, которая уже записана, снапшотится, а остальное - не попало в транзакцию снапшота... Что получаем - херню в снапшоте.
в снапшоте ерунда. Но он слепится с другим и внезапно вы удите полный файл. Все снапы надо слеплять. Можно автономнои и паралельно. Вы принцип формирования снапов знаете? Как это работает?
> Но он слепится с другимсопрягается гусеница опричная!
" И куда ж оно его писать-то будет? "
так написано куда, посмотрите ещё раз :-)
Посмотрел, ещё больше охренел, диапазон секторов, ладно бы сказали, должен быть отдельный раздел с данными, и раздел под снапшоты.
Это значит надо ещё какую-то утилиту регулярно дёргать, чтоб она смотрела что файл на месте и список секторов передавала... привет загрузчику LILO
Так тут именно в этом и суть, что администратор системы не позаботился о возможности создания снапшотов- не создал lvm или не выбрал fs, которая их умеет.
А тут вфигачиваем модуль и оно само начинает магически уметь снапшоты...
> оно само начинает магически уметь снапшоты...до первого обнаружения, что в снапшоте - неюзабельные спагетти данных...
дык запросто :-)
Ы-ksnap?
Ну положим будет эта хрень в ядре.
Читать то из неё сможет только ихний софт за бабло, верно?
Вообще для начала хотелось бы понять, под какой лицензией вообще сабж планируется. А то будет как с каким-нибудь nvidia.ko.
https://github.com/veeam/blksnap/blob/master/LICENSE.mdGNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Нет. Читаёте доку.
https://github.com/veeam/blksnap/blob/master/doc/blksnap_ru....
"В соответствии с парадигмой "лучшая документация — это код", инструмент содержит подробную встроенную справку."и всё.
прочитать что-то там нельзя.
Если вы не умеете читать инструкции и man'ы к консольным утилитам, то вам рановато участвовать в подобных обсуждениях. Если есть прдеметная критика инструкций предоставленных разработчиком, то пишите списком. Всё остальное с вашей стороны это "блабла" и хайпожорство.
там нет доки, там кусок овна вместо документации.
там прямым текстом написано, читайте кодт.е. если ты не понимаешь, что закладывал разработчик или не знаешь его ЯП (а в 99% случаев конечному юзеру нужно сделать команду "утилита сделай бекап /dev/устройства"), то помогать тебе никто не будет.
Нормальная документация содержит подробное описание каждой команды, а заодно и несколько примеров наиболее частого ее использования. Херовая документация просто... существует.
Но давай проведем тест? Если ты такой умный, как сделать бекап этой тулзой?
"из пространства пользователя" можно будет читать то, что раньше было запрещено читать правилами доступа и всякими аппарморами? =)
> "из пространства пользователя" можно будет читать то, что раньше было запрещено читать
> правилами доступа и всякими аппарморами? =)"Что делает хороший бакап? Гарантированно нарушает систему безопасности."
с чего бы? доступ к бекапу только у того, кого надо.
> с чего бы? доступ к бекапу только у того, кого надо.И где это вы такое видели? :)
у себя
Давно мечтал украсть этот механизм из veeam agent, а тут они сами его предлагают.