И авторы отличные

а как у borg с конкурентностью?

в плане если Я в один реп буду делать сразу несколько бекапов?

ее нет. и не будет в этом смысле

оно и прнятно

А главное, это бессмысленно практически

посоны, а с чего может возникать такая ситуация, что дженкинс не отслеживает завершение запущенного в джобе процесса? там нету никаких форков

просто внезапно, когда все джобы завершились, я захожу на сервер и вижу, что код еще работает

Может Jenkins помирает и перехапускается в какой то момент?

у меня там используется publish-over-ssh plugin

есть шанс, что когда коннекшн должен завершиться по таймауту - дженкинс не убивает удаленно запущенный процесс

если так - то это нефиговый баг

А главное, это бессмысленно практически

Ну почему -- удаленный хост и заливка по ssh со многих тачек.

Ну почему -- удаленный хост и заливка по ssh со многих тачек.

заливай в разные репы

Что ты хочешь выиграть заливкой в одну?

Дедупликация?

С разных машин? :/ Ты выиграешь меньше, чем потеряешь на распределенной транзакционности

Делай последовательно. Кстати.

С разных машин? :/ Ты выиграешь меньше, чем потеряешь на распределенной транзакционности

нот тру. Например, у нас выигрыш очень большой.

Дедупликация?

в общем, в борге так не получится, потому что там кеш, который будет перестраиваться при бекапе с нового места, эксклюзивный лок и бекап с одного клиента в одну репу. Да, было бы лучше, если бы было можно, но даже без этого это пока самый лучший вариант, видимо, из всех.

нот тру. Например, у нас выигрыш очень большой.

Ты иногда сначала говоришь, потом думаешь. А у тебя есть конкурентная запись? Ты чудесным образом родил боргу рапсределенные транзакции кэша чанков? Вот вся стоимость родов, поддержки и родовые травмы - вот это будут минусы. Я именно это имел ввиду. И сразу посоветовал кстати сделать последовательно

1) можно пересчитывать кеш при начале бекапа со следующего сервера, а можно перенести кеш с первого сервера. На этом проблема закрыта. 2) да, конкретно у нас выигрыш по дедупликации очень очень большой. Я проверял. 3) то что последовательно, если в одиин репозиторий, то по-другому и не получится. 4) если надо чтобы сам бекап всего произошел быстрее, то тогда очевидно каждый сервер в свой репозиторий

упирается там все в скорость работы lz4 в один поток в текущей версии и в следующей 1.1, поэтому даже на гигабитном линке можно лить на бекапный сервер 2-3-4 потока с ссд и, наверное, дофига потоков с обычных дисков.

1) можно пересчитывать кеш при начале бекапа со следующего сервера, а можно перенести кеш с первого сервера. На этом проблема закрыта. 2) да, конкретно у нас выигрыш по дедупликации очень очень большой. Я проверял. 3) то что последовательно, если в одиин репозиторий, то по-другому и не получится. 4) если надо чтобы сам бекап всего произошел быстрее, то тогда очевидно каждый сервер в свой репозиторий

2. Я уже вижу да. 3. Мы очевидно теоретизировали 4. Кстати надо статейку на эту тему зарубить пока помнишь. Кэш не кэш, мой ляп, быстрее не быстрее

ну я вроде все в жж уже написал, кроме готовых скриптов под наш случай )

пропущенное есть в доке и в тикетах в гитхабе

упирается там все в скорость работы lz4 в один поток в текущей версии и в следующей 1.1, поэтому даже на гигабитном линке можно лить на бекапный сервер 2-3-4 потока с ссд и, наверное, дофига потоков с обычных дисков.

а может и хорошо что упирается. зато это позволяет не упираться в диск

а может и хорошо что упирается. зато это позволяет не упираться в диск

нипонял

в диск я не упираюсь ни с одной из сторон

причем, с одной стороны я не упираюсь в диск в 10 раз, а с другой раз в пять

но авторы довольно твердо уверены, что в 1.2 они научатся параллелить процессы и тогда все будет быстрее

потому что у тебя ssd. не везде есть ssd

ну погоди, ты упираешься либо в диск с одной из сторон, либо в скорость одного потока

ты все равно всегда во что-то упираешься

тип того

если у тебя медленный диск с одной из сторон, то ты таки уже упираешься в диск и ничего хорошего от того что все медленно - нет

Тип того

причем упираешься ты всегда со стороны источника

ну и вот что тогда ты за глупость выше сказал? )

а может и хорошо что упирается. зато это позволяет не упираться в диск

вот разве что у тебя в комплекте еще и такой медленный проц, что он оказывается медленнее дисков

но это просто ССЗБ со всех сторон

Хмм... кстати, если делать одну репу на всё, то borg как-то странно "туда" отправляет повторные архивы. Ручками-то в пустую репу всё быстро, а тут он как-то того-с

@knutov смотри, он у тебя в ~/.cache/borg/блаблабла/chunks.archive.d что-нибудь оставляет, или там всегда пусто?

пусто

Что-то я напрягся. Если всё лить в одну репу, он меньше чем 15 секунд вообще ничего не делает. Это в сумме у меня выливается в какашку. Я не совсем понимаю, выиграю ли я, если не буду по пользователям бить, а сразу всю колбасу заправлю?

ну в смысле у меня каждый пользователь - архив

причем на пустой репе всё ок - разница повторного бэкапа по времени видна сходу

при этом кэш у меня на ssd...

О, и тут @pavel_odintsov

везде

А в наговском чятике ты есть?

не думаю :)

ERROR: S client not available

инвайти :)

https://t.me/nag_public

Попробую сегодня borg в варианте - репа <=> юзер. Потеряю конечно в общей дедупликации, но возможно увеличу скорость

@knutov а ты настройками чанков не игрался? Может мне просто их пример сделать с тем что жрет больше памяти?

@knutov а ты настройками чанков не игрался? Может мне просто их пример сделать с тем что жрет больше памяти?

не игрался и как я понял - играться надо тогда, когда у тебя метадата перестает входить в дефолтные 8гб или специфика самих файлов такова, что оптимальнее иметь другой размер чанка

Просто у меня реальнго кэш всё вытормаживает...

напиши тикет в гитхабе, спроси что делать

Подскажите нормальный СМС шлюз для Европы

Подскажите, чем заменить xclip и pbcopy, чтобы работало поверх ссх и без проблем? xclip не работает стабильно и просто постояно отваливается со стороны xquartz, вариант с pbcopy через netcat требует телодвижений и технически не очень хороший

парни keepalived vs peacemaker ?

таскать ip nginx-а в броадкастной сетке

таскать ip nginx-а в броадкастной сетке

vzmigrate —live )

vzmigrate —live )

эм.... чо ?

хотя да, к нему все равно будет нужна примочка

чет я не подумал

вот вот

ойпи то надо утащить

утащить - это как раз оно норм. А вот узнать о том, что надо утащить, да еще чтобы было с чего утаскивать

keepalived пожалуй

аргументы ?

если нужно только переносить ип и быть уверенным, что он поднят - то keepalived проще и легче

результат работы keeplived 64 bytes from 192.168.1.210: icmp_seq=3 ttl=64 time=0.117 ms 64 bytes from 192.168.1.210: icmp_seq=7 ttl=64 time=0.590 ms

у коросинка такого небыло

это если его рестартануть на мастере

а что было у коросинка?