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

Инцидент с СУБД проекта GitLab, opennews (??), 01-Фев-17, (0) [смотреть все] Хипстеры DROP PgSQL бэкапы не нужны ага,,,, Аноним (-), 14:25 , 01-Фев-17, (2) –3 Доверяйте облакам, говорили они Держите все свои важные данные в облаках Они от, Аноним (-), 14:27 , 01-Фев-17, (3) +36 // просто ещё не реализовали облаков для облаков Вот тогда-то заживём , Аноним (-), 14:54 , 01-Фев-17, (10) +14 // реализовали - они ж написали, мы регулярно бэкпались в azure Но что-то пошло н, . (?), 15:15 , 01-Фев-17, (18) +1 // нашли в чём бэкапится, алекс (??), 20:09 , 02-Фев-17, (101) –1 Ну так раз в 6 часов - это разве не регулярно Если хочешь чаще - то бесплатного, Аноним (-), 21:51 , 01-Фев-17, (61) +4 Да это просто жесть Как-так это все школьники организовали и забыли про бекапы, Аноним (-), 14:36 , 01-Фев-17, (5) –3 // они не забыли So in other words, out of 5 backup replication techniques deployed, . (?), 15:03 , 01-Фев-17, (13) +16 // кстати, это был хороший админ, поскольку догадался сделать _нештатный_ бэкап до , . (?), 15:14 , 01-Фев-17, (17) +9 // кого уволить кто нанял недостаточно админов , поледанныхотсутств (?), 16:26 , 01-Фев-17, (34) как это его уволить Это ж человек, тяжким трудом сэкономивший фирме N admin_sa, . (?), 18:17 , 02-Фев-17, (95) +1 Да де-лы не знающие, что бэкапы которые успешно не развернули хоть раз - не бэк, IB (?), 15:20 , 01-Фев-17, (22) +1   // Все очень сильно зависит от размера этого самого бекапа Знаю одну контору у кот, Pavel (??), 15:36 , 01-Фев-17, (26) +2   А развернуть тестовую базу раз в полгода никому в голову не приходило , Аноним (-), 16:23 , 01-Фев-17, (33) +7   Уверенность в одном из 146 бэкапов это Важно Никакой связи с Чуровым, сов, Andrey Mitrofanov (?), 16:30 , 01-Фев-17, (36) +4   Предлагаю вариант развернуть хотя бы раз , Аноним (-), 16:40 , 01-Фев-17, (39) +5   бывает, что не на чем например кластер из 11 хостов c vmware 60VM , тома на м, anonymous (??), 13:23 , 02-Фев-17, (82) –1   в dev null , tacitusdef (??), 18:06 , 02-Фев-17, (92)   а потом ORA 0600 или как там правильно, давно не видал и мы идем искать новую, . (?), 18:12 , 02-Фев-17, (94) +1   Ну лучше чем в 0 , vitalif (ok), 12:09 , 02-Фев-17, (81)   Что за детский сад Отдельный сервер, которые стягивает свежайший бэкап, развора, Аноним (-), 20:00 , 01-Фев-17, (60)   Все отдельные сервера заняли вэб-макаки под свои докеры с нодами , Led (ok), 00:09 , 02-Фев-17, (68) +2   разница существенная - во втором случае, ты заметишь проблему только через недел, Аноним (-), 17:05 , 02-Фев-17, (87) +1   Нет пути ТМ Усё пропалоушеф Ц Люто плюсую, пиши ещё - завтра пятница , Andrey Mitrofanov (?), 19:03 , 02-Фев-17, (99)   Нужно хотя бы раз развернуть бекап, чтобы проверить, что там есть все, что нужно, XoRe (ok), 23:33 , 01-Фев-17, (66)   ух ты, давно я не брал в руки шашек В смысле, что они, оказывается, для этого к, . (?), 18:08 , 02-Фев-17, (93) +1   Попадался мне на LORе один чел, который запаковал каталог gzip ом без tar а Ути, ivn86 (ok), 11:30 , 02-Фев-17, (80) +1   Хм Что-то тут не так в этом комментарии gzip на каталог, если с флагом -r, даст, freehck (ok), 03:04 , 03-Фев-17, (104) +1   С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout Но челу нужен был файл, ivn86 (ok), 07:35 , 03-Фев-17, (105) +1   Понял Весьма удивлён изобретательности человека Так отстрелить себе ногу -- эт, freehck (ok), 09:52 , 03-Фев-17, (107) +2   Чувак на самом деле не сильно виноват, а виноват тот кто не настроил процесс тес, Аноним (56), 19:17 , 01-Фев-17, (56) +1 // а это тот чувак и был в числе прочих Но никакого дополнительного времени на э, . (?), 18:01 , 02-Фев-17, (91) +3 Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1 p s , Аноним (-), 17:02 , 01-Фев-17, (44) +1 // Раскраска подсказок, пауза перед нажатием энтера вплоть до посидеть на руках, п, Michael Shigorin (ok), 22:59 , 01-Фев-17, (64) +1 // Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от hostnam, KonstantinB (ok), 02:48 , 02-Фев-17, (71) +2 Да ладно, покажи, чоуж , Аноним (-), 05:37 , 02-Фев-17, (74) +3 А покажите, действительно , Michael Shigorin (ok), 15:40 , 02-Фев-17, (86) –1 Не работать уставшим, посидеть подумать, угу Особенно когда стоят над душой и н, Аноним (-), 10:14 , 02-Фев-17, (77) +2 если я нечаянно доломаю -- ты правда починишь нет тогда не мешай делать, чт, Michael Shigorin (ok), 15:38 , 02-Фев-17, (85) я тебе страшный девопский тайна открою ее даже Шигорин не знает, потому что аль, . (?), 00:14 , 03-Фев-17, (102) то-то у нас zabbix допиливали - https support zabbix com browse ZBXNEXT-22, Michael Shigorin (ok), 00:19 , 03-Фев-17, (103) –2 Это еще хорошо, если только 2 А если их 42 на 3-х мониторах и там еще закла, SysA (?), 11:07 , 02-Фев-17, (79) Когда в голове дэдлайны, а над головой ПиЭмы, про бэкапы не думают , Led (ok), 00:07 , 02-Фев-17, (67) +4 Не было, и вот опять , Аноним (-), 14:40 , 01-Фев-17, (6) +3 Надежность выбора технологий уровня GitLab,GiHub профинансировал ZFS OnLinux и и, Аноним (-), 14:45 , 01-Фев-17, (8) +1 // ZFS головного мозга дeтектед , Аноним (-), 15:01 , 01-Фев-17, (12) –1 уровня линyпс тут и постгрез, с его невменяемой неработающей без ручного пинани, . (?), 15:10 , 01-Фев-17, (15) –8 // Поднял один раз, ни разу не пинал, все работает ЧЯДНТ , KonstantinB (ok), 15:30 , 01-Фев-17, (24) +3 // один разДаже фраза есть такая один раз не , Аноним (-), 16:39 , 01-Фев-17, (38) –3 да я и много раз поднимал, всё чудесно работает для тех кто руками не умеет даже, эцсамое (ok), 17:07 , 01-Фев-17, (45) +1 Ну да, был бы оракл, или mssql, то этого бы никогда не случилось Гарантирую Без, Аноним (-), 23:18 , 01-Фев-17, (65) // _этого_ - ручного стирания каталогов под репликацию - да, никогда не случилось б, Аноним (-), 17:27 , 02-Фев-17, (88) +1 То есть, раньше реплики БД у них не было Хипстота , Аноним (-), 15:06 , 01-Фев-17, (14) +1 // Была, но из-за атаки вторая БД начала лагать и репликация отвалилась В попытке п, Аноним (-), 19:08 , 01-Фев-17, (55) +1 // Это выглядит как желание прибить муху которая сидит на кнопке запуска ядерных ра, Аноним (56), 19:21 , 01-Фев-17, (57) +4 // Удаление содержимого директории data на сервере куда будет производиться реплика, Аноним (-), 08:59 , 02-Фев-17, (75) +1 mv data old-datamkdir data, qqq (??), 08:53 , 03-Фев-17, (106) +1 надо б на досуге посмотреть результат этого действа на живом постгрезе - полагаю, пох (?), 17:19 , 03-Фев-17, (108) +1 https www youtube com watch v nc0hPGerSd4 Live Stream восстановления , burik666 (ok), 15:14 , 01-Фев-17, (16) +5 // а может ради этого всё и задумывалось , Аноним (-), 16:06 , 01-Фев-17, (31) +3 // Куда донаты кидать , Аноним (-), 16:41 , 01-Фев-17, (40) +3 Прикольно Одного из них Ёрик зовут Бедный Ёрик С , Аноним (-), 17:42 , 01-Фев-17, (46) +1 // Еще и спец по СУБД Точно бедный , Аноним (-), 17:51 , 01-Фев-17, (47) Нормальное дело Можно подумать, никто из вас reboot не в том окошке мультиплек, aNoN (?), 15:17 , 01-Фев-17, (20) +12 // Набрать ребут не в том окне - нормально Не нормально иметь единственный сервер,, Аноним (-), 15:20 , 01-Фев-17, (21) +2 // Первый раз - невнимательность Регулярно - СДВ СДВГ Лечится Симптомы СДВ 1 н, Аноним (-), 16:29 , 01-Фев-17, (35) // Зато в мериканнии детишек с этим заболеванием лечат медицинским кокаином Че, Andrey Mitrofanov (?), 16:45 , 01-Фев-17, (41) –3 Признавайся, где ты спер мою биографию , Аноним (-), 17:52 , 01-Фев-17, (48) тыщи вас , Аноним (-), 18:23 , 02-Фев-17, (96) clear config гораздо интереснее И бесплатного резерва в 50 мощности обычно нет, Аноним (-), 17:51 , 02-Фев-17, (90) +1 А-ха-ха до боли знакомая ситуация Сам так делал не раз , Аноним (-), 15:20 , 01-Фев-17, (23) +1 http checkyourbackups work , Shamil (?), 15:31 , 01-Фев-17, (25) +2 // http www worldbackupday com ru , user (??), 15:55 , 01-Фев-17, (29) +3 Только зануды делают резервные копии настоящие мужчины просто закачивают все ва, Аноним (-), 15:40 , 01-Фев-17, (27) +2 // http russianfedora pro posts kernelorg-otkazyvaetsia-ot-ftp-serverov , Neptus (?), 15:47 , 01-Фев-17, (28) +5 // на по - , Michael Shigorin (ok), 18:40 , 02-Фев-17, (97) Просто На В Git Же , Andrey Mitrofanov (?), 16:33 , 01-Фев-17, (37) +1 гитлабживи, Аноним (-), 15:55 , 01-Фев-17, (30) +7 у них все на Azurenuff said, omnomnin (?), 16:06 , 01-Фев-17, (32) +4 Вот, что бывает с ручным devops NixOS - наше всё , Аноним (-), 16:49 , 01-Фев-17, (42) –5 // И что, там возможно настроить репликацию в PostgreSQL одной опцией А если в эти, www2 (ok), 18:40 , 01-Фев-17, (49) // Можно Фишка с Nixos в воспроизводимости проверил в vbox, задеплоил https git, Аноним (-), 18:50 , 01-Фев-17, (51) –1 // в любой системе управления конфигурациями так можно да даже и с шелл-скриптами , й (?), 00:44 , 02-Фев-17, (70) +1 Все можно сделать одной опцией , даже с puppet или скриптом bash Только nix ni, Аноним (-), 18:54 , 01-Фев-17, (53) –2 И безотносительно nixos, надо правильно мыслить Не репликацию постгрес, а серве, Аноним (-), 19:02 , 01-Фев-17, (54) // и в датацентре сами собой воздвигаются новые стойки, из воздуха в них запрыгиваю, пох (?), 17:28 , 03-Фев-17, (109) –1 Все злорадные такие То ли себя безгрешными считают, то ли GitLab не любят Я, в, www2 (ok), 18:47 , 01-Фев-17, (50) +7 // Да ерунда же, просто ребята настолько легкомысленные, что 5 вариантов бекапа сде, Аноним (56), 19:27 , 01-Фев-17, (58) +1 Я так понимаю DoS-атака в итоге оказалась успешной , Гентушник (ok), 19:30 , 01-Фев-17, (59) +6 // Да, в некотором смысле это новый класс -- можно назвать SDoS, self denial of , Michael Shigorin (ok), 18:42 , 02-Фев-17, (98) +1 Атака второго порядка целью и жертвой оказался тот, кто чинил тот первый прост, Andrey Mitrofanov (?), 19:09 , 02-Фев-17, (100) +1 мда, такие вот нынче специалисты, Аноним (-), 22:14 , 01-Фев-17, (62) –5 // Люди такие всегда , Andrey Mitrofanov (?), 09:35 , 02-Фев-17, (76) +1 минусуют видимо те, кто тоже на работе так лажает , Junker (?), 01:47 , 05-Фев-17, (112) а што все возбудились-то так, как будто на деньги кто-то попал хипсторская конто, Михрютка (ok), 00:12 , 02-Фев-17, (69) –2 // У гитлаба бизнес - в продаже gitlab ee, а gitlab com - это так демостенд, там, Аноним (-), 03:08 , 02-Фев-17, (72) +1 // ну так вот инвестор на деньги и попал - он не с платных функций живет, а с цены , пох (?), 17:30 , 03-Фев-17, (110) На волне хайпа с гитлабом хотелось бы узнать, а чем и как в вашей организации ор, QuAzI (ok), 10:26 , 02-Фев-17, (78) –1 // Бесплатных не бывает Есть платный относительно дешевый enterprise, которым по, Андрейка (ok), 13:53 , 02-Фев-17, (83) // вы заблуждаетесь в смысле - надежных платных тоже не бывает не бывает Бывает , Аноним (-), 17:44 , 02-Фев-17, (89) +1 // Вы из какого-то 20 века что ли Гарантия восстановления данных заключается не в , Андрейка (ok), 14:35 , 06-Фев-17, (113) –2 Гонору у вас конечно много, с этим не поспоришь, но где пруфы дайте ссылку что, QuAzI (ok), 00:28 , 07-Фев-17, (114) +1 Андрейка, а иметь всю эту архитектуру, полиси, и т ддействительно дешевле чем ра, Аноним (-), 10:40 , 13-Фев-17, (115) и как это помогает, когда у вас 50 серверов , ALex_hha (ok), 19:29 , 04-Фев-17, (111) 2,3,5,6,8,14,16,20,23,25,27,30,32,42,50,59,62,69,78,111

Сообщения

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

	22. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от IB (?), 01-Фев-17, 15:20
	> они не забыли: Да де-лы не знающие, что "бэкапы которые успешно не развернули хоть раз - не бэкапы" должны страдать!
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	26. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Pavel (??), 01-Фев-17, 15:36
	Все очень сильно зависит от размера этого самого бекапа. Знаю одну контору у которой дамп БД делается в течении ~30 часов и следом начинается следующий дамп. Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачивать ибо это бессмысленно, и они нужны только на совсем крайний случай когда умерли все реплики и реплики отстающие на 6, 12 и 24 часа от мастера. И да, вариант что из дампа ничего не развернётся совершенно не нулевой.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Инцидент с СУБД проекта GitLab"	+7 +/–
	Сообщение от Аноним (-), 01-Фев-17, 16:23
	А развернуть тестовую базу раз в полгода никому в голову не приходило?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Инцидент с СУБД проекта GitLab"	+4 +/–
	Сообщение от Andrey Mitrofanov (?), 01-Фев-17, 16:30
	> А развернуть тестовую базу раз в полгода никому в голову не приходило? Уверенность в одном из 146 (*) бэкапов это Важно. (*)Никакой связи с Чуровым, совпадение: 365.24/2*24/30 = 146.096.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Инцидент с СУБД проекта GitLab"	+5 +/–
	Сообщение от Аноним (-), 01-Фев-17, 16:40
	> Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачивать Предлагаю вариант: развернуть хотя бы раз.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от anonymous (??), 02-Фев-17, 13:23
	бывает, что не на чем. например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300 и оракловая база, которая бэкапится отдельно. да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще одной такой системы нет.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от tacitusdef (??), 02-Фев-17, 18:06
	в /dev/null?
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . (?), 02-Фев-17, 18:12
	> бывает, что не на чем. > например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300 > и оракловая база, которая бэкапится отдельно. > да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще > одной такой системы нет. а потом "ORA 0600"(или как там правильно, давно не видал) и мы идем искать новую работу? ;-) [нет, я понимаю, что там кластер, массив с избыточностью, кроссчек и все такое, но оракл такой изобретательный ;-) ] все ж таки 60vm это еще не фатально, можно биться с начальством за тестовую ферму.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	81. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от vitalif (ok), 02-Фев-17, 12:09
	Ну лучше чем в 0.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	60. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (-), 01-Фев-17, 20:00
	Что за детский сад? Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть неделю. Главное автоматически.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	68. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Led (ok), 02-Фев-17, 00:09
	> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиков Все "отдельные сервера" заняли вэб-макаки под свои "докеры с нодами".
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (-), 02-Фев-17, 17:05
	> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант > для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть > неделю. разница существенная - во втором случае, ты заметишь проблему только через неделю (или не заметишь вовсе, потому что развернуть-то оно развернуло, а внутри лажа). Соответственно, будь тамошний админ таки же как ты - и не постели соломку лично - им бы пришлось откатиться на бэкап недельной, а  не шестичасовой, тухлости. Или двухнедельной. Или вообще никакого. А цена этого "отдельного сервера", который, частенько, не отдельный сервер вовсе, а отдельный кластер на пяток стоек - очень и очень немаленькая. А инвестор жадный. Ну и учти, что если бэкап восстанавливать неделю - то ты потеряешь половину пользователей. То есть в какой-то момент становится понятным, что ну...вообще-то...ну хорошо бы в принципе иметь бэкап хотя бы вот для запуска тестового инстанса при мега-апгрейде инфраструктуры, но пользы от него не так много, как хотелось бы. > Главное автоматически. наоборот - главное, хоть иногда человеческим глазом смотреть. Иначе, как и в этом случае, может оказатьтся, что гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор. А для этого опять же надо чтобы у админов на это было время и вдохновение. А не 23:00, а таск все еще не закрыт.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	99. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Andrey Mitrofanov (?), 02-Фев-17, 19:03
	>>Какая разница сколько это занимает, хоть неделю. >тухлости. Или двухнедельной. Или вообще никакого. > очень немаленькая. А инвестор жадный. >восстанавливать неделю - то ты потеряешь половину пользователей. >> Главное автоматически. >гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор. "Нет пути."ТМ > А для этого опять же надо чтобы у админов на это было > время и вдохновение. А не 23:00, а таск все еще не > закрыт. "Усё пропалоушеф."Ц +++Люто плюсую, пиши ещё - завтра пятница.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от XoRe (ok), 01-Фев-17, 23:33
	> Естественно никто даже не пробовал их разворачивать ибо это бессмысленно Нужно хотя бы раз развернуть бекап, чтобы проверить, что там есть все, что нужно. Для примера - у mysql есть хранимые процедуры и функции (stored routines (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. А если не указать, не сохраняет. Если они активно использовались, но дамп делался без них... Есть шанс узнать что-то новое для себя в самый неподходящий для этого момент. Дело в том, что если про эту опцию не знать, можно потратить много времени на поиск причины. С виду то как - дамп вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время на вытаскивание этих хранимок из кода или девелоперской среды.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	93. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . (?), 02-Фев-17, 18:08
	> Для примера - у mysql есть хранимые процедуры и функции (stored routines > (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. А ух ты, давно я не брал в руки шашек. В смысле, что они, оказывается, для этого ключик сделали (правда, судя по ману - кривой, портит даты, не от того юзера заводит). вообще-то сохраняет, но если mysqldump --all ;-) Приятные последствия при мерже на другой кластер - побочный эффект ;-) А их использование по прежнему разваливает репликацию, или это я тоже уже от жизни на пять лет отстал? > вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время > на вытаскивание этих хранимок из кода или девелоперской среды. а они там - опа, не той версии и "той" вообще нигде нет ;-) P.S. чего только не узнаешь странного, тролля на опеннете
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от ivn86 (ok), 02-Фев-17, 11:30
	> Естественно никто даже не пробовал их разворачивать Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл. Т.е. с виду всё хорошо. И только когда возникла необходимость его распаковать чел понял, что исходный каталог он уже не получит.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	104. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от freehck (ok), 03-Фев-17, 03:04
	> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл Хм. Что-то тут не так в этом комментарии. gzip на каталог, если с флагом -r, даст вам на выходе каталог с .gz-шниками. А без флага -r вообще откажется работать. Какой же там файл получился на выходе? К тому же через прогнозируемое время. И в довесок прогнозируемого объёма.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от ivn86 (ok), 03-Фев-17, 07:35
	>> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл > Хм. Что-то тут не так в этом комментарии. > gzip на каталог, если с флагом -r, даст вам на выходе каталог > с .gz-шниками. А без флага -r вообще откажется работать. > Какой же там файл получился на выходе? К тому же через прогнозируемое > время. И в довесок прогнозируемого объёма. С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout. Но челу нужен был файлик и он перенаправил stdout в файлик: https://www.linux.org.ru/forum/general/11356750 Речь не о том, что даже стандартными утилитами в неумелых руках можно выстрелить себе в коленку, а о том, что его при этом ничего не смутило -- файл то большой, значит все данные в нём есть, значит проверять ничего не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от freehck (ok), 03-Фев-17, 09:52
	> С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout. Понял. Весьма удивлён изобретательности человека. Так отстрелить себе ногу -- это ещё додуматься надо. :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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