Полгода назад, вышел указ президента,
от 30.03.2022 № 166 "О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации". И тут выяснилось что и мы тоже. Из это выходит что вся инфраструктура переходит на Линукс. А точнее на Астра Линукс, и всё что с ней связано.
Черновой вариант перехода. (Ну как-то так)
Итого: АД на АЛД, документооборот с *одна прога на оракле* на 1с, производственная программа с что-то-там* на 1с (скорее всего), 1с на 1с (ну да), Лоцман+Компас на Лоцман+компас (обещают к 25 году допилить на Линукс), CAD Windows на CAD Linux (не имеющие аналогов в мире).
ALD pro, RuPost и Брест скачать просто так нельзя (запросим, но это попозже). Для тестов были скачаны Астра Линукс 1.7 СЕ и РуБэкап (и всякая мелочь типа мой офис....). Неделя всяких тестов - офис как офис (ну понятно что без VBA), принтеры печатают (но не все), рубэкап после BackupExec - просто адЪ и израиль. (это пока идёт вариант чернового-чернового замещения, даже не преальфа).
Вопрос в том - кто-то уже переходил на такое? Хотелось бы узнать про подводные камни (хотя кто их скажет). Как-то сумбурно, но я хз что писать и спрашивать.
пысы РуБэкап - УжасныйУжас.
Пока в блоги, если решат что и в другое - так тому и быть.
Комментарии
а что резервного капирование прог настолько мало что токма РуБэкап?? или по умолчанию может быть ток РуБэкап?
Только отечественное (ну вы понимаете). Или скрипты. Скрипты ещё хуже.
Под пингвином в Сети сидел в середине 1990-х ещё. Как с серверов так и с консолей. Зависит от удобства пользователей и рук Админа. Ни в Политехе ни в ФТИ и некоторых других проблем с пингвином особо не было. 27 лет как, Слава Линусу и Столману!
Есть проги кои работают корректно только в старых версиях винды, а есть что и окошка ДОС 4-6.22 тщательно настроенное требуют - профессиональные программы, для некоторых старые компы держать проще. Расчёт оптики в Земаксе и в некрасивой, неудобной, но из ИТМО программы 1990-х будет разительно отличен в пользу последних. То же по ряду других расчётов.
Винду обычно требовали CAD и отдельные расчётки. Остальное под "большими" Юниксами работало, лучший их них по отзывам админов и профессоров с факультета кибернетики была Digital Unix+железо в виде 2-процессорных серверов, они с PDP11 сидели и пользовались ПО перекомпилированными аж 1960-х иногда - зверски оптимизированные программы, в кэш 1 уровня альфы (у тех что видел от 8+8к был) влазили многие матрицосчитающие.
Офис заменяется с открытым кодом или же своими (мир праху Лексикона - отличный редактор для больших текстов был, их таблицами не пользовался а последний “Лексикон 97” кажется был). Потом офис, официалки в т.ч., теперь в основном открытого кода - разницы нет и русские проги неудобные пока ввиду непонятного форматирования текста.
Немного не по теме, но офис в части excel не особо заменяется в случае сложных таблиц. типа бюджета предприятия.
Т.е. если с нуля таблицу делать, то, возможно. и заменится. А существующую не всегда получится даже открыть.
Acronis вроде тоже нашенское.
Весьма условно - весь российский отдел разработки вывезли в Болгарию еще в 2014-ом году.
Акронис остался для ненашего рынка, его аналог Кибербекап - для нашего.
Да, в текущих условиях с точки зрения бизнеса сидеть на двух стульях, возможно, и есть наилучшее из возможных решений. Тем не менее, они одни из первых начали топтать тропинку для весьма популярной ныне "релокации" - мне это очень не понравилось с моральной точки зрения.
Как техническое решение, он, возможно и хорош - просто я в силу специфики работы имел с ним дело с оборотной стороны, но не буду вдаваться в детали. В конце концов, много ли в своей жизни видел хорошего врач проктолог?
Врач видит облегчение состояние своего пациента. Это его моральная награда.
Это была просто шутка, которой я иногда подбадривал наших приунывших молодых инженеров технической поддержки. Ведь это достаточно тяжело в моральном плане - изо дня в день решать проблемы, котороые создал не ты, в то время как клиент орёт лично на тебя, ведь ему очень больно, обидно, и зачастую при этом он еще и теряет свои деньги. Поэтому мы часто использовали аналогии из медицины, с той оговоркой, что нам-то легче, ведь никто не умирает. Хуже было, когда "игра в больничку" заканчивалась и начиналась "игра в войнушку" - полный завал, людей и времени на всех не хватает, все орут и в то же время идёт битва за показатели.
Я тоже инженер техподдержки. Мне, похоже, повезло с клиентами - на меня ни разу не орали за 15 лет.
Ну прям так, чтобы орали действительно не очень часто бывает. Но различного негатива прилетает обычно достаточно много. Даже сам факт того, что видишь продукт преимущественно с проблемной стороны налагает свой отпечаток.
Это конечно ДА, но тут больше особенность характера играет роль - стакан наполовину пуст или полон. Я это явно осознал по промежуточным итогам перехода заказчика на Линукс, что проводим сейчас. Основной вывод - да, неудобно и медленно, но ведь работает!
На всякий случай сразу оговорюсь - я с вами не спорю, просто поддерживаю приятную беседу :)
В Линуксе могут медленно работать портированные решения, которые изначально разрабатывались для другой операционной системы - например приложение на .NET работающее на Linux через Mono. Родное ПО работает также быстро (я уже давно не интересуюсь баталиями Windows против Linux, Linux против Mac т.д.). Думаю, вы тоже это прекрасно понимаете.
Еще момент про техническую поддержку - есть разница, что за продукт и с кем общаешься на другой стороне. Это может быть какое-то корпоративное решение, когда в техническую поддержку обращаются специалисты (разного уровня квалификации, но тем не менее). А может быть продукт для массового пользователя, когда приходят очень разные люди. В первом случае работать существенно проще и комфортнее - легче что-то бъяснить, выше уровень терпимости. Зачастую предполагается дальнейшее сотрудничество и люди как-то пытаются наладить контакт, не грубят, с пониманием относятся к возможным задержкам, понимают что есть out-of-scope. Во втором же случае всё существенно хуже. Но зато там чаще встречаются всякие забавные ситуации.
Скрипты не хуже. Скрипты - универсально, гибко, бесплатно, а также удобно для админа в плане "job security" тупо потому что никто не хочет в них разбираться.
В дистрибутиве есть бакула и рсинк... но, возможно, у них есть какие-либо свои требования.
Гляну, заранее спасибо.
Могу порекомендовать BAREOS. Успешно пользовал для бэкапа серверов и рабочих станций, использую ленточную библиотеку. Не могу сказать, как его завести под астрой (в моём случае был центос), наверное, надо попробовать бинарники для Дебиан.
Я тоже в одном месте использую bareos, но мне он представляется весьма геморройным продуктом. Одно то, что из консоли управления нельзя менять конифгурацию, для управления конфигурацией надо вручную править кучу отдельных файлов, уже выглядит диковато.
Гляну, ну а вдруг
бакулу кстати кто-то наш придумал.
rsync это вещь
Овладевайте трактором* (С)
*командной строкой
а что у veeam -впрде российская ничего нет?
Педевикия пишет - "Штаб-квартира компании находится в городе Бар, Швейцария.", хз, скорее всего нет.
Для начала, если не ошибаюсь, Veeam - только под Windows. По крайней мере не так давно так было.
У нас на Астра Линуксе работает 3 информационные системы - Это системы специализированного документооборота с различной функциональностью
SQL какая?
Postgrepro
А у вас базы поштучно нормально бэкапятся и восстанавливаются?
Мне просто интересноПросто в документашках от рубэкапа на это ничего. Там тупо однада база и всё, её и архивят и восстанавливают.В двух системах копии баз создаются скриптами, восстановление с дампа - без проблем. Переносили с сервера на сервер через дамп.
В одной системе база работает на кластере, и по расписанию скриптами снимается дамп.
Это без рубэкапа? Просто скриптами
Я руковожу разработками и таких деталей не знаю. Я думаю, что просто скриптами, потому что в описании мы никакого дополнительного продукта не указываем
Не хочу обидеть вас лично, но и промолчать не могу, извините.
Именно этот подход и загнал разработку ПО в глубокую задницу. Весь менеджемент знает только "быстрее и дешевле", это же эффективнее, детали им ни к чему.
это же скл сервер, просто скрипта в одну строчку достаточно, только если вам не потребуются дифференцирование бэкапы, тогда может строчек кода и поболее будет
вот как раз постгрес РК простейшим скриптом сделать - как два байта переслать! у него встроенный pg_dump нормально работает.
знаком с ним с 1999 года - уверен в этом на 100%, много раз занимался в разных вариантах - и восстановлением и пррсто переносом.
причём там можно и боком и прискоком. но надо попробовать какой вариант вам подходит, докцию читать обязательно!
Бэкап баз данных это отдельная песня.
Штатный pg_dump как раз работает с одной конкретной базой, и утверждается, что при этом с ней можно работать (читать и даже писать) - в случае больших объёмов и частых изменений у меня в этом есть сомнения, но может и допилили.
Если нужно быстро поднять все сервисы после сбоя железа, то лучше будет файловый бэкап - мы использовали zfs snapshot раздела, где лежат данные postgres + bacula
Еще можно поиграться с "online backup" - сконфигурировать WAL archiving и забирать WAL files (и обязательно чистить их на боевом сервере, иначе быстро место засирается). Это самый геморойный способ, но зато можно держать stand-by реплику, останавливать её для файлового бэкапа и т.п.
И да, если переходите на Linux - то не надо бояться скриптов.
Штатный pg_dump делает sql дамп конкретной базы, работать с ней можно но могут быть нюансы.
как вариант бэкапа имеет смысл для маленьких баз.
Файловым бэкапом вы можете спокойно получить неконсистентное состояние, вариант со снапшотами может использоваться для различных вариантов ci/cd когда надо получить много копий боевой базы большого размера для целей тестирования, но вариант получить тыкву вместо базы при восстановлении сильно не нулевой.
Если вы так бэкапите, то лучше пересмотрите этот процесс. ))
online backup "сконфигурировать WAL archiving" это как раз и есть правильный вариант
в процессе делается заморозка файловой структуры базы и все изменения пишутся в бинлоги
обвязывать это скриптами можно, но в общем бесмысленно, есть ряд вполне официальных тулзовин которые признает сообщество разработчиков postgresql
указал их в прошлом комментарии.
Для последних версий postgresql есть еще варианты ))
Спасибо, будем читать
Ключевые моменты из моего краткого выступления:
1. Бэкап баз данных - отдельный вид искусства;
2. Универсальные решения всегда хуже специализированных;
3. Не бывает идеального решения, приходится выбирать оптимальное, причём критерии оптимальности могут быть разные.
Да, эти риски разумеется учитвыались и тестировались. В нашем случае была важна скорость возвращения системы в строй. В целом zfs показала себя неплохо, в случае получения "тыквы" просто будет откат на большее время (а восстановление из бэкапа это всегда потеря части данных). Bacula тоже особого отвращения не вызывала.
Для своих сервисов я использовал репликацию, тут тоже не всё так идеально. Ну и в любом случае - теперь это головняк буржуйских админов, "а я остаюся с тобою, родная моя сторона..."
Ещё раз спасибо, буду на неделе всё сводить и думать. Хотя ключевое решение буду принимать не я.
На здоровье. Вы делаете хорошее и нужное дело. Задача весма непростая, по результатам вы рискуете или сгореть или же наоборот - набить кучу экспы и поднять уровень ;)
Еще слово в защиту файлового бэкапа, который тут критикуют (я не агитирую за него, это просто одно из множества решений) - если есть техническая возможность останавливать сервис на время резервного копирования, то проблем с консистентностью данных не будет.
Техническая есть, производственной нет.
Даже ночью.
Таки да. Хотя с учётом всего с чем я работал - от см1420 до ..., будет проще, но не легче.
Ну я примерно это и имел в виду - значит нет.
Успехов вам!
Я уже на чём только не работал, и всякие Юниксы\Линуксы, и Нетварь, и Винда... Тут просто пока не понятно что именно будет и, самое главное, что можно использовать.
РК для базы с файловой системы? это просто смешно! разве что для мускула проканает...
вот про WAL - нормальная тема
если это постгрес
wal-g
wal-e
pgbackrest
штатные утилиты с обвязкой
все опенсорс, бэкап востановление без всяких проблем
полное, инкрементальное и тд
+ постоянно бинлоги
возможность восстановления на любой момент времени на глубину бэкапирования.
бэкапит куда угодно.
вообще специализированного ПО для бэкапов море
но оно не коробочное, берете инженера, ставите задачу, он настраивает
+ регламенты востановления и проверки бэкапов.
Огромное спасибо.
Астра разве выпустила 1.7 СЕ?
orel-2.12.45.5-23.07.2022_07.53.iso - это астра 1.6 на Дебиан 9... от 1.7 на дебиан 10 не сказать что принципиально отличается, но многие системные библиотеки достаточно неплохо подросли в версиях.
При этом нужно проверить, есть ли Брест и Термидеск под 1.7.
Сорян ))) 1.7. SE. Теперь у них (вникли к просьбам) один установщик, а в конце выбираешь Орёл\Смоленск.
штаб квартира уже в швейцарии но создали росияне,хз чьи они
Страницы