The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск утилиты для резервного копирования rclone 1.35"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Ссылки "<<" и ">>" открывают первые и последние 10 сообщений.
. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/
Сообщение от Михрютка (ok), 05-Янв-17, 00:34 
> Таки более-менее крупные компании усвоили некоторые простые вещи. Кто по хорошему, кто
> после пары злых факапов. Самое смешное что бэкапный софт весьма умеренно
> пиратят. Саппорт не пиратится, а без саппорта такие вещи...

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

> С другой стороны вон тут буратино вгружал дамп мускуля месяц. Неуспешно. Питонисты
> - это вот так.

у меня был сотрудник, который три месяца пытался восстановить базу oracle из резервной копии на удаленную площадку. так и не восстановил. я не стал делать из этого глобальные выводы про ПО оракл и dba оракла.

>> так в промышленном софте тоже желающих разбираться не нашлось, последний оператор
>> после аппаратного отказа просто остановил сервер бэкапов, написал заявление и уволился.
> В промышленном софте разбирающихся все-таки есть и не настолько уникальны. А еще
> у них саппорт есть. И это именно тот случай когда за
> саппорт может иметь смысл заплатить. Не круто если все упало, а
> чувак которые писал мегашнягу - умотал на Бали на месяц.

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

мой пойнт в том, что брейнфак код можно писать на любом языке и конфигурации. мой пойнт, что никакая "промышленная" система не спасет от неквалифицированных и безответственных операторов. что толку, что я сдал СРК с РЭ, заботливо написанным по всем канонам СКД, если человек, у которого возникли вопросы по эксплуатации, даже не удосужился заглянуть ни в него, ни в документацию вендора, ни в конфигурацию системы? многабукав ниасилил, как раньше говорили.

верно и обратное - никакое "самопальное" ПО не испортит хорошего инженера и не помешает ему спроектировать качественнное решение, закрывающее вопросы заказчика. HACMP полно адских скриптов на ksh чуть более чем наполовину, это не мешает ему быть а) проприетарным б) поддерживаемым и в) вполне работоспособным решением.

> А все просто: в backup exec и mssql для таких развлечений таки
> придется немного разобраться. И поэтому операторы бэкапов по нормальному отдельная профессия.
> А если у вас там был один эникей на все -
> вы и получаете то самое. И таки раскладывать сиквеля по файликам
> - вы там спросите DBA чем все это чревато и какие
> там заморочки с консистентностью и проч. Потому что "если вам кажется
> что дела идут хорошо - значит вы просто чего-то не заметили".

я не знаю, какие заморочки с консистентностью и т.п. в BE+MSSQL и не горю желанием разбираться, пока я не owner этих систем.

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

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

> Бимерская ета зарекомендовала себя склонной к издыханию и глюкам по поводу и
> без. А потом операторам бэкапов приходится осваивать несвойственные функции, если в
> энтерпрайзе не было DBA по db2. Наверное это сложно назвать достоинством.

вам это рабинович напел или вы на собственный опыт опираетесь? бо мой персональный опыт как раз говорит об обратном. единственные случаи, когда мне пришлось вспоминать о db2 при работе с tsm, в основном относились к наладке ha кластеров, и это не называлось "несвойственные функции", это называлось "обеспечить работу одного инстанса db2 на двух или более разных хостах". в остальном db2 ведет себя тихо и смирно. как и любая другая БД пока в нее не лезут шаловливые ручки локальных девелоперов.

>> единственно у меня с select-то быстрее выходит сказать, какой
>> там у клиентов тренд по объему данных на пулах,
> Простите, в типичной бэкапной системе все это всем глубоко ПО-Ю. Настраивается шедулинг
> бэкапов, ротация и все такое, и система требует минимум внимания. Вспоминают
> про это в основном когда что-то навернулось или надо новых клиентов
> добавить. Откуда в принципе и следует возможность сгрузить на бэкап операторов
> какие-нибудь смежные административные функции по движкам или системам которые они знают.
> Но все-таки это не эникеи, "и упаси тебя перепутать хиппи с
> толкиенистом".

в моих типичных СРК не ПО-Ю, как вы пишете, такие показатели, как RTO, например. если вы умеете это определять божьим духом с минимумом внимания, запишите меня на свой семинар плз. ротация как раз беспокоит меньше всего, при отстутствии требований комплаенса или конкретных требований клиента на это можно смело забить. добавление новых клиентов тем паче не моя задача, а задача провизионирования. моя задача, чтобы активные данные начали восстанавливаться в течение 10-15 минут с момента запроса на восстановление и восстановились в указанное мной время.

> ИМХО от бэкапного софта требутся все-таки не отчеты и даже не select
> прежде всего. Знаете, если у вас пожар - вас от пожарного
> крана интерсует наличие воды и шланга. А то что он видите
> ли не совсем правильно покрашен и надпись не по фэншую -
> может и хрен бы с ним в этом случае, а?

иногда от таких отчетов зависит вообще наличие пожарного крана.

теперь, как на это влияет то, запускает диспетчер бэкапов бэкап на клиенте бэкап агентом по конфигурации или скриптъ какой нибудь на питоне/перле/портянкобаше/тикле/визуляр-барсике/жабаскрипте/систэмдэ/что-там-ненавидят-на-лоре-на-этой-неделе? мне что-то кажется, что никак.

как влияет на RPO+RTO открытость/закрытость кода решения или его сопровождение красной/голубой-в-полосочку/бородатой-с-рогами конторой? мне что-то кажется, что никак.

война окончилась, всем спасибо, все свободны.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Выпуск утилиты для резервного копирования rclone 1.35, opennews, 03-Янв-17, 10:12  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру