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

Инцидент с СУБД проекта 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]

78. "Инцидент с СУБД проекта GitLab"	–1 +/–
Сообщение от QuAzI (ok), 02-Фев-17, 10:26
На волне хайпа с гитлабом хотелось бы узнать, а чем и как в вашей организации организуются бекапы? А то что-то всё плохо с хорошим инструментом для бекапов, куда ни глянь - разваливающиеся на бегу костыльные велосипеды
Ответить | Правка | Наверх | Cообщить модератору

	83. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Андрейка (ok), 02-Фев-17, 13:53
	Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемся Гарантия восстановления данных - 100% (да-да, это бывает), скорость восстановления == скорость записи на диск по сети, т.е. зависит от железки куда рестор делаешь Если по сути - бэкапим диск на блочном уровне (для того же postgresql этого достаточно), для всяких mysql/mssql есть плагины (работает как mysqlproxy, отслеживая изменение состояния снапшота во время бэкапа) Ну и главное не чем бэкапить, а какая policy. Если policy правильная, то все будет хорошо У нас полиси такая: - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных типа СУБД - раз в час - Успешный бэкап сжимается и реплицируется на другой континент раз в 4 часа - Реплика бэкапа раз в сутки сливается в облако S3, а оттуда в долговременное хранилище - Раз в сутки бэкап разворачивается на stage-сервер и по нему гоняются автоматические тесты, которые в том числе позволяют установить точность восстановления на 95% - DWH собирает для основной базы KPI отчеты и stage-сервер сравнивает развернутый бэкап создавая аналогичные отчеты час-в-час, кроме последнего (текущего) часа - его еще нет в бэкапе Все делается автоматически, на CICD сервере При миграции данных (программисты выпускают новую версию), перед деплоем делается обязательный бэкап НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным. Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами (code/change review) Ну и помимо всякого - все действия логируются, по каждому инциденту заводится тикет в джире и не закрывается, пока root cause не будет устранена, покрыта тестами и мониторингом и автоматизирована В общем - главное архитектура :-)
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (-), 02-Фев-17, 17:44
	> Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемся вы заблуждаетесь...в смысле - надежных платных тоже не бывает. > Гарантия восстановления данных - 100% (да-да, это бывает) не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая, чем потери бизнеса. > Ну и главное не чем бэкапить, а какая policy. Если policy правильная, главное - что бэкапать. У вас очень мало данных и много лишних денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?). > У нас полиси такая: > - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных "отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется, я уже слегка спойлерю) > типа СУБД - раз в час у вас _очень_ мало данных. > НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным. > Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода > команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами и когда коммитилка и аппрувилка навернулись - мы делаем - что? > Ну и помимо всякого - все действия логируются, по каждому инциденту заводится у вас не только очень мало данных, но и очень мало настоящей работы (ну да, потому что данных мало). Есть время тыцать мышью в неторопливый интерфейс жиры (на что обычно уходит куда больше времени, чем на саму работу). Поверьте, вы не гитлаб. > В общем - главное архитектура :-) главное - забиться в норку, где хорошо платят, вкусно кормят и можно развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага. А быть админом гитлаба, как видим, действительно плохо. гитхабу, думаю, не легче.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Инцидент с СУБД проекта GitLab"	–2 +/–
	Сообщение от Андрейка (ok), 06-Фев-17, 14:35
	> вы заблуждаетесь...в смысле - надежных платных тоже не бывает. > не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая, > чем потери бизнеса. Вы из какого-то 20 века что ли? Гарантия восстановления данных заключается не в том, что вам кто-то что-то заплатит. Нет. А в том, что технически решение: а) проверяет готовый бэкап б) реплицируется, в том числе в write only storage (т.е. без возможности "случайно" удалить реплику, если мастер грохнулся) > главное - что бэкапать. У вас очень мало данных и много лишних > денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?). Ну "мало" или "много" понятия относительные. 15-20Тб в СУБД (postgres), ну и так, по мелочи еще 50Тб наберется менее критических данных > "отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так > много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши > действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется, > я уже слегка спойлерю) 30-50Тб это мало, что Вы :-) 200Тб - это еще куда ни шло. И это только одна полка, а их само собой несколько. failover, катастрофоустойчивость и т.д. А про "нет денег", так это Вы, наверное, к русскому бизнесу привыкли, да? Сочувствую Если на бэкап бизнес-критических данных нет денег, то такой бизнес лучше вообще не начинать, ну а Вам в такой компании работать не рекомендую > у вас _очень_ мало данных. Сколько для Вас - много данных? Ну, с какого числа оно хотя бы перестает быть "мало данных". Это понятия относительные >> команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами > и когда коммитилка и аппрувилка навернулись - мы делаем - что? Коммитилка/Апрувилка - это Jenkins, который хранит свой конфиг в git, а образ виртуалки бэкапится. Если оно вдруг сломалось, то поднимается за 15 минут двумя-тремя командами, одна из которых apt-get install jenkins на чистой виртуалке > Есть время тыцать мышью в неторопливый интерфейс жиры (на что обычно уходит > куда больше времени, чем на саму работу). Ага. Agile слышали. Или вы до сих пор по email инциденты трекаете? Вы точно из 20 века > Поверьте, вы не гитлаб. Мы - больше чем gitlab. По многим показателям > главное - забиться в норку, где хорошо платят, вкусно кормят и можно > развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага. > А быть админом гитлаба, как видим, действительно плохо. Завидуйте молча. Зависть вообще - смертный грех. Уверен на 99.9% вы даже не на уровне админа гитлаба
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от QuAzI (ok), 07-Фев-17, 00:28
	Гонору у вас конечно много, с этим не поспоришь, но ~где пруфы~ дайте ссылку что почитать конкретнее же?
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (-), 13-Фев-17, 10:40
	Андрейка, а иметь всю эту архитектуру, полиси, и т.д действительно дешевле чем раз в 6 лет потерять последние 6 часов данных и сутки простоя? Или у вас это не считали?
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

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

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