Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Выпуск утилиты для резервного копирования rclone 1.35, opennews (?), 03-Янв-17, (0) [смотреть все] А главное то, что написано оно на Go распространяется одним бинарём и под хоро, Фанатик (?), 10:12 , 03-Янв-17, (1) // И поэтому пермиссивно лочит любителей свободы на считанные единицы провайдеров о, Аноним (-), 15:53 , 03-Янв-17, (21) +6 И сколько он вешает в результате , Аноним (-), 10:50 , 03-Янв-17, (2) // 12568032, стрипнутый, амд64в чем вопрос то , Аноним (-), 11:10 , 03-Янв-17, (4) –1 // 12М - это немало Тот же rsync весит 500K , freehck (ok), 15:11 , 03-Янв-17, (17) +5 // А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то , фыв (??), 20:36 , 03-Янв-17, (39) –3 Так он же не целиком их включает, а только используемые функции В итоге весит 9, Mihail Zenkov (ok), 02:03 , 04-Янв-17, (44) +1 А его с LTO собрали А то LTO может вышибить то что не используется и в случае т, Аноним (-), 10:42 , 04-Янв-17, (47) –1 configuremake CFLAGS -static EXEEXT -static strip rsync-staticДа, с LTO как, Mihail Zenkov (ok), 14:26 , 04-Янв-17, (53) –1 Это что, вообще без оптимизаций oO А в чем пойнт Он и большой и не оптимальный, Аноним (-), 15:59 , 04-Янв-17, (56) –1 Вообще-то обычно все исходники содержат оптимизацию в системах сборки Обычно эт, Mihail Zenkov (ok), 16:43 , 04-Янв-17, (57) –2 Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный, Аноним (-), 20:51 , 04-Янв-17, (61) –2 На самом деле не так уж много если код адекватный - отдельные части функций, к, Mihail Zenkov (ok), 22:29 , 04-Янв-17, (66) Слушай, лучше не пиши ничего про LTO Ты ж в этом мягко говря - плаваешь ж, Led (ok), 20:58 , 05-Янв-17, (69) И в чем я не прав Напиши конкретно, по пунктам, с ссылками и примерами Будет п, Mihail Zenkov (ok), 21:51 , 05-Янв-17, (70) Я проверял на разном софте 1 Упомянутый мной tweetnacl-lite, с которым я развле, Аноним (-), 20:50 , 10-Янв-17, (80) +1 OK, я не верно сказал LTO может вынести и функции целиком Просто затраты как , Mihail Zenkov (ok), 01:09 , 11-Янв-17, (81) –1 Это его нормальное состояние, я бы сказал А это другой вопрос В свежих gcc, кст, Аноним (-), 08:16 , 13-Янв-17, (82) Ага, от BIOS с EFI ещё зависит , Аноним (-), 07:42 , 04-Янв-17, (45) О, а это Go-вно не зависит от libc Т е оно у меня под BSD запустится , anoni (?), 00:24 , 06-Янв-17, (73) Что за BSD без libc , Nas_tradamus (ok), 18:31 , 09-Янв-17, (76) –1 Лол, его самого такой в пору инкрементально синхронизировать Скоро на сидюк пом, Аноним (-), 15:55 , 03-Янв-17, (22) +5 // двоим-обоим сверхуничего что он статик собери гцц в динамике, а не родным и буд, Аноним (-), 16:31 , 03-Янв-17, (23) Ммм, как своевременно Нет, чтобы написать об этом сразу , freehck (ok), 16:48 , 03-Янв-17, (24) ути путиесли влез в обсуждение то хотя бы знай особенности языка о котором рассу, Аноним (-), 16:54 , 03-Янв-17, (25) А оно уже осилило динамическую линковку Или как обычно не работает - значит не, Аноним (-), 17:46 , 03-Янв-17, (29) –2 Ручками - да Обеща т как нить сделать Видимо из тех кто может сделать, а не ны, _ (??), 18:14 , 03-Янв-17, (33) fxd , Аноним (-), 22:41 , 03-Янв-17, (42) Бинарь на 12 метров даже статиком не каждый день увидишь Да мне и с rsync хорошо, Аноним (-), 10:40 , 04-Янв-17, (46) +2 Яндекс Диск же, Аноним (-), 11:07 , 03-Янв-17, (3) –2 Прикольная игрушка, но1 где ownCloud 2 все эти разношёрстные костыли не решают, Аноним (-), 12:55 , 03-Янв-17, (5) +2 // Самопальные скрипты на базе rsync решают обычно Кстати, что ужасного в скриптах, Crazy Alex (ok), 13:05 , 03-Янв-17, (7) // - Нужно время на разработку, тестирование и сопровождение, на каждый проект, на , Аноним (-), 14:20 , 03-Янв-17, (12) –1 // Я, конечно, с бакулой давненько дела не имел, но насколько я помню он по неудобс, Crazy Alex (ok), 15:02 , 03-Янв-17, (16) –1 Поэтому всякие симантеки с своими backup exec и будут получать копеечку Твоя на, Аноним (-), 17:02 , 03-Янв-17, (26) +1 Плюйся ядом меньше Можно сколько угодно пытаться бэкапить раздел или даже базу, Crazy Alex (ok), 20:00 , 03-Янв-17, (38) Да какой это яд Так, капитанинг и констатация того факта что благодаря такой си, Аноним (-), 11:46 , 04-Янв-17, (50) +1 упырьте мел, коллега в моих отрыжках на помеси гадюки с верблюдом, как вы поэти, Михрютка (ok), 22:47 , 03-Янв-17, (43) –1 Таки более-менее крупные компании усвоили некоторые простые вещи Кто по хорошем, Аноним (-), 14:18 , 04-Янв-17, (52) работают и хлеба не просят в самом страшном случае их нельзя легально обнови, Михрютка (ok), 00:34 , 05-Янв-17, (68) –1 Через vscsc зато умеет , commiethebeastie (ok), 14:08 , 04-Янв-17, (51) Bareos , Аноним (-), 15:21 , 03-Янв-17, (19) // То же самое, вид сбоку С незначительными улучшениями в виде пассиовного режима, Аноним (-), 17:48 , 03-Янв-17, (30) http burp grke org, Аноним (-), 17:50 , 03-Янв-17, (31) // О, забавная штука Кто-то решил таки запилить более-менее нормальную бэкапалку и, Аноним (-), 20:55 , 04-Янв-17, (62) Частично враньё Аманда это tar и все, что вокруг него вертится Руками вытащить, bac (?), 23:19 , 04-Янв-17, (67) Так себе штуковина Оно работает, да, но, как минимум, для Amazon Cloud там алго, Crazy Alex (ok), 13:08 , 03-Янв-17, (8) +2 // https minio io , Плохой Клоун (?), 13:43 , 03-Янв-17, (11) –1 // И при чём здесь эта хрень , Crazy Alex (ok), 15:35 , 03-Янв-17, (20) 1 Сливаем все что нужно с удалённых серверов с использованием rsync на централь, CHERTS (??), 13:15 , 03-Янв-17, (9) +4 // Так оно примерно с теми же трудозатратами и самим rsync делается же с --link-des, Crazy Alex (ok), 13:20 , 03-Янв-17, (10) // Если файл в бекапе кто-то намеренно поправит, поплывут все залинкованные бекапы , Аноним (-), 14:40 , 03-Янв-17, (15) +1 // Здесь чуть поправлю, т к сам эксплуатирую подобное на несколько ТБ Онлайн-дедуп, PnDx (ok), 11:43 , 09-Янв-17, (75) –1 В целом солюшн самый адекватный, но пока не получится на него соскочитьДля неадм, Аноним (-), 14:30 , 03-Янв-17, (14) // Зачем Кстати безопасность тоже будет против А для списка авторизованных - ну и , _ (??), 18:38 , 03-Янв-17, (34) +1 У вас там любят раздавать гранаты обезьянам, чтобы посмотреть что получится Нет, Аноним (-), 20:09 , 04-Янв-17, (58) Имеем радость жизни Когда под блоком который расшарен на все 100500 снапшотов к, Аноним (-), 17:15 , 03-Янв-17, (28)   // В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол так и так - файл, Аноним (-), 20:37 , 03-Янв-17, (40) –1   // Ага Файл помер Смотрим мы - а он такой дохлый разом во ВСЕХ снапшотах, наприме, Аноним (-), 14:50 , 04-Янв-17, (54) –2   От повреждения файла или чанка в диф бэкапах спасает только полное его копирова, Аноним (-), 21:29 , 04-Янв-17, (63) +1   Просто нормальный бэкапный софт все это умеет вообще без приявзки к файлухе и ка, Аноним (-), 16:30 , 13-Янв-17, (83)   Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 которая п, Твой факапчик (?), 21:49 , 04-Янв-17, (64) +1   Хм, я как-то пропустил этот момен Да ничего я не продаю Просто констатирую что , Аноним (-), 16:36 , 13-Янв-17, (84)   Чувак, ты не прав Если ZFS пулл собран админом на нескольких дисках, например, Аноним (-), 22:06 , 06-Янв-17, (74)   // то мы вспоминаем что бэкапы нужны раз в сто лет а хоанилка начинает удорожать, Аноним (-), 16:57 , 13-Янв-17, (85)   Что будете делать, если центральный сервер поломается , XoRe (ok), 10:45 , 04-Янв-17, (48) // А это как в анекдоте про поимку льва голыми руками - А если это будет львица - Н, Аноним (-), 15:07 , 04-Янв-17, (55) Freenas, NEXENTA, ananim (?), 15:18 , 03-Янв-17, (18) –1 // В каком месте они - решения для бэкапа и синхронизации , Аноним (-), 17:08 , 03-Янв-17, (27) // Вон в том выше по топику И не решение, конечно, а часть решения , _ (??), 18:45 , 03-Янв-17, (37) –1 doh и еще экспортированные, как блочный девайс, чтобы усугубить ситуацию вконец, Михрютка (ok), 21:18 , 03-Янв-17, (41) NAS - это обычно железка размером меньше чем рабочее место бородача Указанное в, Твой факапчик (?), 22:01 , 04-Янв-17, (65) 1,2,3,5,8,9,18

Сообщения

[Сортировка по времени | RSS]

	28. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 03-Янв-17, 17:15
	> 1. Сливаем все что нужно с удалённых серверов с использованием rsync на > центральный сервер бэкапов > 2. На центральном сервере бэкапов ZFS > 3. Делаем какой нужно алгоритм создания снапшотов на ZFS > 4. Profit > Что имеем: Имеем радость жизни. Когда под блоком который расшарен на все 100500 снапшотов каааааак вылезет BAD SECTOR! Ну или что там у кого. И внезапно окажется что вся стопка снпшотов при малейшем пофреждении - битая. Оппа-па. А снапшоты то внезапно не бэкапы! Совсем. Собственно похожая подстава с дифференциальнми бэкапами всех мастей, но там это подконтрольно админу в явном виде хотя-бы на предмет того что от чего зависит и где что шарится а где нет. А снапшоты несколько не для этого сами по себе.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	40. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (-), 03-Янв-17, 20:37
	В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол так и так - файл помер, поищи его в других бекапах. Как минимум ты хотябы узнаешь, какой файл повреждён. Для борьбы с этой фигнёй можно использовать резервирование по схеме 3-2-1 указанное выше, можно зеркало собрать, на худой конец можно сказать сколько уникальных копий каждого блока держать (ZFS такое вполне умеет). И разрулить это вполне подконтрольно админу, в отличие от ситуаций, когда админ даже не знает, что его файлы битые. Зато на диск в этом случае пишется гораздо меньше данных, что уменьшает его износ, и, как следствие, не так быстро происходит вылет всего диска, что куда критичнее одного сбойного файла.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (-), 04-Янв-17, 14:50
	> В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол > так и так - файл помер, поищи его в других бекапах. Ага. Файл помер. Смотрим мы - а он такой дохлый разом во ВСЕХ снапшотах, например. Круто, да? CoW по изначальной задумке пишет в сторону только изменения. А "core set" блоков может в принципе быть один на всю толпу. И если там что-то порушится - завалиться может и вся цепочка. Это касается и дифференциальных бэкапов, но там параметры цепочки зависимостей явно вывешены админу. И можно настроить - допустим на каждые 5 бэкапов лепится полный, который зависит только от сам себя. Это некий баланс: с одной стороны быстрые и мелкие бэкапы, с другой - масштаб урона если на сервере(ах) с бэкапами ситуация оказалась отлична от идеала. И еще есть соображения консистентности. Если вы просто взяли состояние БД "здесь и сейчас" - ну это круто. Но ничего не говорит о том какие там транзакции были in-flight. И когда вы это вернете двиглу БД, для него это будет как минимум жесткий крах с некорректным шатдауном с его точки зрения. Звучит прикольно и многообещающе, правда? И хрен с два вы с него корректный снапшот снимете без таких сюрпризов. Для этого надо двиглу через какой-то апи сказать чтобы на время угомонилось, снять снапшот, и вот тогда... тогда у вас будет нормальный снапшот. Но это подразумевает или остановку базы или умение дергать какие-то сильно отдельные административные апи. И наверное это уже не про скриптики на питоне и вбаханые наобум снапшоты. И в этом месте мы начинаем догадываться чем нормальный бэкапный софт отличается от наколенщины. Он все это умеет худо-бедно :). > Как минимум ты хотябы узнаешь, какой файл повреждён. Я знаю что у меня факап. Это круто. А дальше, собственно, что? Бэкапные сервера знают не для того чтобы узнать какой файл поврежден. > Для борьбы с этой фигнёй можно использовать резервирование по схеме 3-2-1 указанное > выше, можно зеркало собрать, на худой конец можно сказать сколько уникальных > копий каждого блока держать И тем не менее, это довольно стремная схема в том плане что если в механике файлухи что-то порушится, масштаб урона может получиться очень не прикольный. А то что сановские маркетолухи рассказывают про should never happen не дружит с законами Мерфи, а на лисяре был вполне нормальный пример как never happen может выглядеть. > вполне подконтрольно админу, в отличие от ситуаций, когда админ даже не знает, что его файлы битые. Еще раз. Сервера с бэкапами ставят НЕ для того чтобы узнать что файлы побились. А для того чтобы вынуть с них исправные файлы когда они побились у юзерей по какой-то причине. > Зато на диск в этом случае пишется гораздо меньше данных, что уменьшает > его износ, и, как следствие, не так быстро происходит вылет всего > диска, что куда критичнее одного сбойного файла. И оно как бы круто, только когда вылетит вся стопа "бэкапов" - линчевать тебя будут всем офисом.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (-), 04-Янв-17, 21:29
	От повреждения файла или чанка в диф. бэкапах спасает только полное его копирование, что в описанном решении с ZFS, что в твоем "нормальном бэкапном софте". С ZFS это тоже можно реализовать, простейший способ - копировать снапшоты в другой пул раз в неделю, либо архивировать в тот же пул. ZFS в целом дает непревзойденный пока практически нигде уровень достуности и надежности данных. Насчет консистентности, все вменямые БД умеют делать консистентный дамп по умолчанию, не будет никакого "жесткого краха" при восстановлении. Если нет, то как правило есть спец. режим для хот бэкапа, как в случае с ораклом. В общем, непонятно, чего ты развопился и о каком нормальном софте, который решает эти проблемы, ты говоришь.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 13-Янв-17, 16:30
	> От повреждения файла или чанка в диф. бэкапах спасает только полное его > копирование, что в описанном решении с ZFS, что в твоем "нормальном > бэкапном софте". Просто нормальный бэкапный софт все это умеет вообще без приявзки к файлухе и каких либо допущений о меганадежных хранилках. Ну то-есть для хранения бэкапов не обязательно городить супернадежный (и поэтому архидорогой) стораж. Достаточно вменяемую схему бэкапов и хранение на нескольких разных серверах, в нескольких физических локациях. Например, на случай если какая там хранилка решит выгореть синим пламенем целиком. > С ZFS это тоже можно реализовать, простейший способ - > копировать снапшоты в другой пул раз в неделю, либо архивировать в тот же пул. Оно как бы можно, но это как бы закат солнца вручную. А в тот же пул - чревато тем что у вас случится catastrophic failure в вашей мегахранилке который будет запроектной аварией для ZFS и вам вынесет все бэкапы одним махом. Что наверное не здорово. У упомянутых вендырей нарулить бэкап на несколько физически разных серверов - совершенно не вопрос. > ZFS в целом дает непревзойденный пока практически нигде > уровень достуности и надежности данных. До тех пор пока хранилка не изволила выгореть синим пламенем целиком, ага. Поэтому те кто повменяемее - бэкапаются на несколько географически разделенных серверов. При этом им значительно менее страшен что маски-шоу что возгорания в серверной. А вот файлуха при этом уже намного менее принципиальна. Если у вас бэкапы на пяти разных серверах, парочка серверов даже может испортиться и даже выгореть совсем. > Насчет консистентности, все вменямые БД умеют делать консистентный дамп по умолчанию, Но для этого им надо отдельно сигналить. В результате одмин с зээфэсом и скриптиками займется переизобретением того что до него придумали цать контор, сделав это к тому же куда лучше. > не будет никакого "жесткого краха" при восстановлении. Если нет, то как правило > есть спец. режим для хот бэкапа, как в случае с ораклом. Ну да, все так. Вот только этот режим надо явно запрашивать и, пардон, бэкапный софт именно вот это и делает. А тут самому придется для каждой хрени разбираться как это делается. По сути начав изображать из себя вендора софта для бэкапов, только хреново и криво. > В общем, непонятно, чего ты развопился и о каком нормальном софте, который > решает эти проблемы, ты говоришь. А чтобы это стало понятно - надо в этой области немного повертеться. Так то понятно что свои костыли не пахнут.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Твой факапчик (?), 04-Янв-17, 21:49
	Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 (которая подразумевает два бэкапа на другие машины, один из которых вообще в максимально удалённую часть планеты), а он тебе про то, как из-за одного сбойного сектора у тебя вся инфраструктура годами работающая прям обязана навернуться, вместе с ремоутными бэкапами и континентом на котором они хранились. Ты ему пишешь, что количество копий блоков настраивается, а он такой в пьяном угаре с пеной у рта продолжает, от праздников ещё не отошёл, дальше шпарит про то, что это якобы только дифференциальные бэкапы умеют, а всё остальное проделки коммуняк. Ты сразу напиши один раз, что ты тут продаёшь, маркетолух, и не дури людям голову. А то бреда ты накидал, а солюшн так и не предложил.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	84. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 13-Янв-17, 16:36
	> Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 (которая подразумевает > два бэкапа на другие машины, Хм, я как-то пропустил этот момен. > Ты сразу напиши один раз, что ты тут продаёшь, маркетолух, Да ничего я не продаю. Просто констатирую что полно коммерческих решений которые все это уже делают, без привязок к файлухе, с возможностью развернуть свой сервер бэкапа за какие-то минуты и как раз нарулить бэкапный план с раскидыванием на географиески разные сервера. А ZFS тут ни в п..., ни в красну армию. Делать отдельно взятый сервер бэкапов сверхнадежным нафиг надо, бэкапы места занимают немеряно и удорожать хранилище под них - сомнительная радость. Вот географически раскидать - очень хорошая идея. А от zfs единственная польза разве что проверка чексум.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 06-Янв-17, 22:06
	Чувак, ты не прав ))) Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz, BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, даем ZFS команду принять замену. Все! В зависимости от размера диска и загруженности пулла система придет в норму максимум через сутки ))) Куда страшнее "умные" дисковые контроллеры!!! Если накроется такой контроллер, пулл восстановить на новом контроллере, с вероятностью 99% не удастся. Для ZFS чем тупее контроллер, тем лучше.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	85. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 13-Янв-17, 16:57
	> Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz, ...то мы вспоминаем что бэкапы нужны раз в сто лет а хоанилка начинает удорожаться. > BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, > даем ZFS команду принять замену. Все! Это в теории. А на практике случаи разные бывают. Вон на лисяре описан случай когда файлуха просто не смонтировалась. Хорошо если ты джеди и можешь вручную, хексэдитором, всех нае..., но это наверное не про обычного оператора бэкапов. > В зависимости от размера диска и загруженности пулла система придет в норму > максимум через сутки ))) А в течение этих суток на остальные диски будет повышенная нагрузка и спасибо если ничего новенького в результате не помрет. Ну и в целом супернадежные многодисковые хранилки стоят денег а проблему например пожара в серверной или иных катастрофических отказов - не решают. > Куда страшнее "умные" дисковые контроллеры!!! Вот это да - если уникум подохнет и у людей не было запаски, это полный попадец. Прошареный народ закупает запаски. На самом деле для бэкапов актуальнее не суперхранилки а просто настроенное раскидывание по разным серверам. Спасает от всего, начиная от маски шоу и заканчивая выгоранием или затоплением серверной. > Если накроется такой контроллер, пулл восстановить на новом контроллере, с вероятностью > 99% не удастся. Для ZFS чем тупее контроллер, тем лучше. Да там и ZFS не больно нужно. Нужно раскидать бэкапы на несколько серверов в раных локациях и горя не знать. Одна мегахранилка никак не решает проблему что она может утонуть, сгореть или ее унес ОМОН. Или вот например файлуха не смонтировалась, а по увещеваниям саней это should never happen, который быстро превращается в "что хотите, то и делайте!".
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема