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

👆 А начинающего автора следует поддержать подпиской, потому что на текущем этапе это для него лучшая мотивация. Лучше донатов, правда!

Ммммм, как же мне нравятся холивары между сектой свидетелей докера и сектой свидетелей пакетов...

Сам я в холиварах давно стараюсь не участвовать, поэтому отпишусь здесь, у себя.

Вынесем за скобки текущую работу. Без докера и кубера сейчас никуда, мы бы просто захлебнулись в сборках и раскатках. Но текущей работой жизнь ведь и не заканчивается, правда?

Возьмем, к примеру, маленькую галеру на пяток бэкендеров и пару фронтов. Есть пара-тройка активных проектов, десяток на поддержке, пара в перспективе. Вот скажите, что в таких реалиях админу проще? Пилить ансибл под каждый проект для сборки и деплоя на дев/прод — или использовать единожды написанные шаблонный пайплайн Гитлаба, шаблонные докерфайлы и шаблонный же композфайл, точечно инжектируя нужные изменения? Десяток несложных проектов могут крутиться (и крутятся) в дев-окружении на одной виртуалке о четырех головах ядрах, у каждого свои зависимости могут быть — попробуйте их развернуть на одном хосте, чтоб они друг другу не мешали, и обновление работало без вашего участия месяцами и ничего не ломало? Я верю, у вас получится — но давайте при этом сравним трудозатраты?

При этом я совершенно точно не стану пихать в докер, например, Nextcloud для домашнего пользования, особенно, если задумаю ставить его на маломощное железо типа Raspberry Pi. Тут это явно будет лишним: Клауд обновляется не так уж и часто, да плюс к этому пихать его в контейнер — не самая лучшая затея, с учетом его архитектуры... Уж кто-кто, а он точно при установке на хост конфигурируется куда проще и понятней.

Совершенно точно не потащу в докер Samba (написал — и понял, что хочу попробовать, вот такой я странный). Офисная файлопомойка обновляется крайне редко, правильно настроенная работает годами, ломающие изменения редки, конфиги для знающего человека простые. Плюс, как правило, под нее выделяется отдельная виртуалка, не отягощенная более никаким функционалом. (А DC ставят на голой самбе только конченные извращенцы типа меня в прошлом, граблей хватает, особенно если домен изначально был виндовый)

Люди еще возражают против почтовиков в докере, но у меня есть собственноручно развернутый в бою mailcow-dockerized на пару десятков пользователей, работает без нареканий второй год. Хотя могу и iRedMail накатить, и голые postfix+dovecot.

Тут главное помнить: серебряных пуль не существует. Решение применять или не применять какую-либо технологию каждый принимает сам, исходя из потребностей и квалификации, главное тут — осознавать ответственность за принятое решение. Особенно, если эта ответственность материальная.

А накосячить можно при любом подходе. Никто от этого не застрахован.

А про секты было только в прошлую пятницу.

🔥Хотите упростить сбор логов, метрик и трейсов в своей инфраструктуре? Grafana Alloy — мощный инструмент, который унифицирует доставку данных и интегрируется с Prometheus, Loki, Tempo и другими сервисами.

⚡️17 марта в 20.00 мск приглашаем на открытый вебинар "Grafana Alloy - универсальный инструмент доставки логов, метрик и трейсов", на котором узнаем:
- Как Grafana Alloy решает проблемы передачи данных в сложных системах?- Чем он отличается от Fluentd, Vector и других агентов?
- Как настроить отказоустойчивость и балансировку нагрузки?
- Лучшие практики маршрутизации, фильтрации и трансформации данных.Регистрируйтесь и внедряйте Grafana Alloy в своих проектах!

👉Регистрация: https://otus.pw/ljG6/?erid=2W5zFFyDLYp 

Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики.

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Установка облачного файлового сервиса Seafile на Ubuntu Server

Облачные сервисы для хранения и обмена файлами давно стали привычными и популярными как среди простых пользователей, так и в корпоративной среде.

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

Это может быть связано как с объемом хранимых данных, так и с требованиями безопасности или конфиденциальности.

В этом случае обратите внимание на Seafile - простой и производительный облачный файловый сервис, который несложно установить самостоятельно.

https://interface31.ru/tech_it/2023/09/ustanovka-oblachnogo-faylovogo-servisa-seafile-na-ubuntu-server.html

​​И снова про RouterOS 7

В комментариях в очередной раз задавали вопрос: а что не так с RouterOS 7? Почему мы не планируем писать по ней статей и вообще не советуем к применению.

Начнем с очевидных вещей: RouterOS пока не может называться стабильной системой и дело не только в возможных ошибках, хотя и их хватает, достаточно почитать лог изменений и посчитать сколько раз там встречается слово fixed, а также с какой скоростью начинают выходить минорные релизы, преимущественно из исправлений.

Во-вторых – RouterOS 7 продолжает развиваться и изменения часто вносятся очень серьезные. Если взять две наши статьи про ROS 7 которые касаются OpenVPN и WireGuard, то на сегодня они порядком устарели. Поэтому подобные материалы придется переписывать постоянно, либо всегда помнить, что инструкция может быть не актуальной.

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

Это перекликается также с тем моментом, что многие вещи в ROS 7, например, маршрутизация, сделана иначе чем в ROS 6 и полноценно подружить новые устройства с сетью на старых устройствах бывает задачей нетривиальной. А после очередных обновлений в RouterOS 7 данный квест возможно придется пройти заново.

Теперь что касается старых устройств. Про все, что не на платформе ARM можно сразу смело забыть. hAP, hEX, 2011 и т.д. – это не для ROS 7, поставить вы, конечно можете, но ничего хорошего из этого не получится, новая ОС существенно требовательнее к ресурсам. Нет, работать за редким исключением, вроде hAP lite, будет, но нагрузка на устройство существенно вырастет.

При этом каких-то существенных отличий, кроме WireGuard, у новой версии ОС нет. Особенно таких, ради которых надо срочно на нее переходить. Хотя, безусловно, по многим возможностям она интереснее и перспективнее «шестерки».

Но следует понимать, что разработчики фокусируются именно на новых устройствах и именно на них «семерка» будет полноценно работать. Совместимость со старыми сохраняется, но то, что она будет соответствовать вашим ожиданиям – никто не обещал.

Как быть? В большинстве случаев следует оставаться на старой и стабильной ROS 6, которая вдоль и поперек изучена и не преподносит сюрпризов.

Семерка? Ну только когда она идет с новыми устройствами и когда вам безальтернативно эти устройства нужны. Во всяком случае на критические участки ставить их я бы не стал.

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

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

Где ROS 7 можно использовать уже сейчас? Дома, в филиалах с небольшой нагрузкой и на иных некритичных участках сети с небольшой нагрузкой, желательно на новых устройствах. Изучать, разбираться и готовиться к более широкому внедрению.

Канал о захватывающем мире IT-инфраструктуры, где опытные сисадмины и DevOps-инженеры делятся уникальными кейсами и решениями технических задач. 🔧

Собрана подборка самых важных постов для вас:

• Топ-3 самых популярных характеристик ПК в Steam

• История VPN: от военных технологий до повседневного использования

• Доклад от Сбера - Будущее 2035

• Как устроен даркнет

• Криптовалюта: цифровая революция денег

• Сравнение двух разных технологий ИИ 2024 и 2025 (видео)

Присоединяйтесь, чтобы быть в курсе последних новостей из мира IT, изучать передовые технологии и обмениваться опытом с профессиональным сообществом и участвовать в конкурсах, где мы разыгрываем книги и курсы.

Mikrotik и несколько провайдеров. Резервирование каналов

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

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

https://interface31.ru/tech_it/2023/03/mikrotik-i-neskol-ko-provayderov-rezervirovanie-kanalov.html

​​Субботнее, о жизни. Вкалывают роботы, но почему несчастлив человек?

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

В общем слово за слово и выяснилось, что с широким внедрением самообслуживания позитива они не испытывают, даже сейчас, когда этих касс всего две и люди все еще активно идут на «живые» кассы.

Причина проста – уже сейчас смен стало меньше, так как кассы самообслуживания даже в небольшом количестве эффективно снижают потребность в человеческом ресурсе.

Меньше смен – меньше заработная плата, которая там и так невелика. А небольшие по площади магазины уже давно перешли на схему «один сотрудник и несколько касс самообслуживания».

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

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

История эта не нова и данное явление даже имеет свой термин – технологическая безработица, только вот тем, кто попал под него здесь и сейчас легче не становится.

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

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

Но специалист средней квалификации на то и специалист средней квалификации. Мозги там есть и как-то работают, поэтому переобучиться и сменить профессию особой проблемой не было.

А вот с автоматизацией низкоквалифицированных позиций все хуже. Да, появляется отдельный рынок вакансий для тех, кто должен сопровождать и поддерживать эти автоматы. Но вы представляете вчерашнего кассира Пятерочки в роли хотя бы специалиста первой линии поддержки?

Плюс к этому вишенкой на торте закрывается еще один социальный канал. Как раньше? Нет работы – или в Пятерочку, там люди всегда нужны. А сегодня люди из Пятерочки сами ищут куда податься.

При этом в долговременном плане особой проблемы нет. Просто какие-то профессии исчезнут, вместо них появятся новые. Как нет сегодня таких профессий как копировщик или прачка.

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

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

К чему все это? А к тому, что если твою профессию можно заменить роботом, то ее очень скоро заменять роботом. И он будет вместо тебя вкалывать, только вот счастья тебе это не принесет.

​​Мы пахали, я и трактор…

Чарльз Ганьон (Charles Gagnon), мэйнтейнер проекта Dash to Panel, объявил, о поиске нового сопровождающего, которому он мог бы передать управление. Панель создана в 2016 году на основе проекта Dash to Dock и насчитывает более 4 млн загрузок. Чарльз участвует в разработке с 2018 года и в своё время сменил на посту мэйнтейнера Джейсона ДеРоуза (Jason DeRose), основателя проекта.

Объявление об уходе Чарльза спровоцировала негативная реакция сообщества на попытки собрать пожертвования, которые были восприняты как слишком назойливые и агрессивные.

Чарльз закрепил в панели на первом месте в области ярлыков приложений анимированную кнопку с изображением красного сердца, при нажатии на которую появлялось сообщение о сборе пожертвований. Закрыть сообщение можно было только после истечения 20-секундного обратного отчёта.

Недовольство вызвало то, что кнопка занимает первое место в панели, отвлекает назойливой анимацией и отнимает время на ожидание возможности скрытия. Один из участников обсуждения поставил вопрос: насколько можно доверять проекту, ключевой разработчик которого позволяет себе подобное неуважение к пользователям. В ответ Чарльз не стал убирать кнопку, а лишь переместил её в конец списка.

К обсуждению подключился Джейсон ДеРоуз, основатель проекта, отошедший от разработки в 2021 году, который написал, что реализованная навязчивая реклама противоречит духу созданного им проекта и что проект существует благодаря вкладу многих людей.

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

Но если мы зайдем на страницу проекта на GitHub и посмотрим список контрибьюторов, то обнаружим, что основной вклад в проект внес именно Чарльз Ганьон – 823 коммита, на втором месте автор проекта Джейсон ДеРоуз – 227 коммитов. На третьем месте Philipp Unger со 155 коммитами.

Остальные участники внесли от 20 коммитов и менее, т.е. фактически не проявили заметного участия. Если взять тройку лидеров, то Чарльз Ганьон внес 68% коммитов за все время существования проекта.

Но если мы посмотрим на графики активности, то увидим, что Джейсон ДеРоуз после 2018 года практически отошел от дел, а все это время, в течении шести с лишним лет проект тянул Чарльз Ганьон.

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

Семья, почему-то, не хочет кушать доширак и одеваться в секонд-хенде и все чаше начинает косо смотреть на занятия главы семейства, которые отнимают время и ничего не приносят взамен.

Донаты? Ну вы, наверное, уже поняли, как оно работает. Если ведущий разработчик был вынужден достаточно навязчивым образом привлечь внимание к этой проблеме.

Его прекрасно можно понять, потому что выслушивать постоянные упреки домашних про непонятно на что потраченное время – это не самая здоровая и вдохновляющая атмосфера.

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

Но в данном случае попытка монетизации наткнулась на негатив со стороны сообщества и Чарльз Ганьон ожидаемо махнул рукой, мол скребитесь, как хотите, я устал, я ухожу.

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

Поэтому, если не произойдет чуда и в проект не придет молодой и энергичный разработчик, то в перспективе ближайших лет Dash to Panel ждет стагнация с последующим забвением.

Зато «сообщество» в очередной раз показало «кто здесь власть».

Перечитывать старые заметки бывает полезно. Снова нашел и снова перечитал. Потому как на злобу дня.

😉 Наводил порядок вчера в избранном на Инфостарте и наткнулся на статью, точнее рассказ. Из названия не совсем понятно о чем он, поэтому перечитал.

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

Также уверен, что каждый из нас в такой ситуации оказывался, не с той, так с иной стороны баррикад. А то и с обоих.

В общем читаем и высказываем свое мнение: https://infostart.ru/1c/articles/1472447/

На мой взгляд - рассказ не плохой, на подумать и сделать выводы. А то и глянуть на себя со стороны.

​​Стандартные директории для монтирования в Linux

FHS (File System Hierarchy Standard) предполагает наличие двух каталогов для монтирования файловых систем: /mnt и /media

📀 Директория /media служит для монтирования съемных носителей (оптические диски, флешки), которые автоматически монтируются системой в подкаталоги это директории. Монтировать туда что-либо руками не рекомендуется.

🗃 А вот каталог /mnt как раз предназначен для ручного монтирования временных файловых систем. При этом крайне желательно также использовать подкаталоги, хотя если вам надо примонтировать диск буквально на 5 минут, слить/залить, то монтирование непосредственно в /mnt тоже допустимы.

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

☝️Несколько слов про монтирование, обычно монтируют по старинке:

mount /dev/sda2 /mnt/my_disk

Но лучше потратить немного больше времени и смонтировать диск через UUID, для этого сначала узнаем его:

lsblk -f 

а затем выполним:

mount -U 79c53a40-7768-4ee4-a313-4dc579fc1a3e /mnt/my_disk

Также допускается синтаксис:

mount --uuid 79c53a40-7768-4ee4-a313-4dc579fc1a3e /mnt/my_disk
mount UUID=79c53a40-7768-4ee4-a313-4dc579fc1a3e /mnt/my_disk

❓Что это дает? А это дает гарантию, что в указанную точку будет смонтировано именно это устройство, несмотря на подключения и отключения других устройств, что важно, если вы используете сменные носители или подключили диск временно.

😁 Ну а Алиса упорно продолжает считать. что "монтирование дисков в Linux" выглядит как-то так:

Как выстроить карьерный трек в DevOps

...и не сойти при этом с ума 🤪

В теории вроде бы всё понятно, но как перенести её на свой собственный опыт?

На курсе «DevOps Upgrade» можно не только прокачать необходимые хард- и софт-скиллы, но и выстроить карьерную стратегию, составить качественное резюме и подготовить портфолио.

Как это сделать:

1️⃣ Перейти на страницу курса
2️⃣ В разделе оплаты выбрать тариф «Комфорт Карьера»
3️⃣ Выбрать способ оплаты и дождаться старта потока
4️⃣ Пройти видеокурс «Администрирование Linux», который идёт в подарок до 21 марта — чтобы на 100% быть готовым к обучению.

Что входит в тариф «Комфорт Карьера»:
🔸Видеоуроки и практика на виртуальных стендах
🔸Q&A-сессии и встречи с ментором
🔸Telegram-чат с ментором и спикерами курса
🔸3 индивидуальные встречи с ментором
🔸Помощь с резюме и портфолио
🔸Рекомендательное письмо

‼️ На тарифе «Комфорт Карьера» осталось 2 места, так что рекомендуем поторопиться. Старт потока — 31 марта.

Подробности — на сайте.

#реклама
О рекламодателе

Продолжаем вчерашнюю тему:

Монтирование файловых систем при помощи systemd

Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений.

Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем.

https://interface31.ru/tech_it/2022/09/montirovanie-faylovyh-sistem-pri-pomoshhi-systemd.html

​​Куда я попал и где мои вещи?

Рано или поздно любой администратор попадает на незнакомый ему сервер. Как быстро разобраться в ситуации и определить, где тут и что?

Начните с команды:

hostnamectl 

Она покажет основную информацию о системе, а также поможет определить тип платформы и наличие виртуализации.

Затем будет полезно определиться в каком часовом поясе живет сервер и какое на нем текущее время:

timedatectl

Этим действием никак не следует пренебрегать, мы не раз сталкивались с различными нелепыми и неприятными историями, связанными с «неправильным» временем.

После этого сразу же посмотрим локаль, чтобы понимать в какой языковой среде мы работаем:

locale

Теперь посмотрим активные службы в системе:

systemctl list-units --type=service

И активные таймеры:

systemctl list-units --type=timer

В современных системах таймеры заменяют задания Cron, но не отменяют их. Поэтому также проверяем и его:

crontab -l

Также systemd сегодня используется для монтирования файловых систем, особенно съемных и сетевых. Поэтому смотрим и их:

systemctl list-units --type=mount

И изучаем содержимое fstab:

cat /etc/fstab

А все имеющиеся в наличии блочные устройства можно посмотреть командой:

lsblk

Также полезно проверить и USB-устройства:

lsusb

Затем посмотрим какие порты слушает наш сервер, сначала на TCP:

ss -tpln

Потом на UDP:

ss -upln

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

Для тех, кто не спит. Кто начинал свой путь в IT вот с такого девайса?

Хватит топтаться на месте!

Конференция TEAMLY WORK MANAGEMENT 2025 — это прорыв в управлении процессами, который уже работают у лидеров рынка. Узнайте, как сделать вашу команду мощнее, а процессы — быстрее!

Её главная идея в том, что теперь стратегическими активами являются культура знаний, использование AI и прозрачность рабочих процессов. 

Среди спикеров Анатолий Вассерман, Виталий Чесноков, Максим Ильяхов и ещё более 13 именитых лидеров в мире диджитала и бизнеса.

3 конференц-зала, где нон-стопом идут доклады и дискуссии от экспертов, мастер-классы и бизнес-игры. Крутой нетворкинг с основателями и руководителями крупного бизнеса. Бонусом: кофе-брейки и сытный фуршет.

Всё это счастье пройдет 8 апреля в ЦДП (Москва, ул. Покровка, 47). 

🎟 Билеты уже в продаже. Места ограничены, так что не тяните.
👉 А по промокоду СЕРВЕР скидка 50% на любой билет!

Встречаемся на TEAMLY WORK MANAGEMENT 2025!

История вычислительной техники. Программируемые калькуляторы СССР

Развитие вычислительной техники в СССР имело свои особенности и разительно отличалось от ситуации на Западе. Если там компьютеры широко шагнули в массовый сегмент в конце 70-х годов, то в СССР практически до самого его распада компьютер был средством роскоши и ни о какой массовой доступности их говорить не приходилось.

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

https://interface31.ru/tech_it/2024/04/istoriya-vychislitelnoy-tehniki-programmiruemye-kalkulyatory-sssr.html

​​Логическая бомба

Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.

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

Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.

Рассмотрим классический пример, очистка устаревших данных, например, бекапов:

find  -type f -mtime +90 -exec rm -rf {} \;

Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.

1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.

Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.

2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.

3️⃣ Теперь – самое неочевидное – find, который не рекомендуется использовать в скриптах в силу ряда особенностей. В частности, если нам попадется файл с пробелами в имени, то строка будет разбита на две, что приведет к неожиданным последствиям. Чаще всего удаление не произойдет, но может случиться разное.

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

Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).

Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:

find /mnt/backup/ -type f -printf '%T@ "%p"\n' | \
sort -n | \
head -n -90 | \
awk '{print $2}' | \
xargs -I {} rm {}

Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.

Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.

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

Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.

Допустим, наши бекапы имеют имя base1-YYYY-MM-DD.dump, поэтому добавляем в строку поиска новое условие:

find /mnt/backup/increment/ -type f -name "base1*.dump" -printf '%T@ "%p"\n'

Или даже

find... -name "base1-*-*-*.dump"...

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

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