⇨ Депрессия и эмоциональное выгорание айтишника - личная история DevOps
Личная история известного блогера. Ещё по первым старым его видео думал, что человек нездоров. Реально это было заметно. В итоге так оно и было. Поучительная история, рекомендую посмотреть, даже если сейчас вам это неактуально. Распространённая тема, когда в погоне за карьерой и деньгами теряют здоровье. Кстати, автор поднимает в том числе тему ночных дежурств и побудок, которую я тоже не раз поднимал у себя на канале и рекомендовал от них отказываться. Нашлось немало людей, которые их оправдывали, что для меня удивительно. Некоторые даже говорили, что отказываться от ночных дежурств непрофессионально, якобы ты не хочешь брать ответственность за свою инфру (которая на самом деле не твоя).
⇨ Лучший будильник на алерты
Шуточка для любителей ночных дежурств.
⇨ Build your own HomeLab Firewall! // OPNSense Tutorial
Обзор программного шлюза OPNSense, который я недавно рекомендовал к установке, как замену pfSense.
⇨ Zulip - Open Source, Self Hosted, team and organization communication platform
Подробный обзор неплохого чат-сервера, который можно бесплатно развернуть у себя. Я знаю этот продукт, внедрял его, писал про него статью, делал заметки. Посмотрел видео, с тех пор Zulip не сильно изменился. Этот чат интересный и необычный, не похож на условные клоны Slack, типа Mattermost или Rocket.Chat, которые первое время старались его скопировать.
⇨ How to structure your HomeLab network?
Пример того, как можно организовать локальную сеть с изоляцией сегментов.
⇨ SDN в Proxmox — мощный инструмент для управления сетями. Как работают виртуальные сети и зоны.
Хорошее подробное видео на тему работы SDN в Proxmox. Описание, схемы, примеры, настройки. Всё присутствует.
⇨ RTX 5090 laptop - ЛУЧШАЯ видеокарта для ноутбука? LLM в ноутбуке.
Тесты топовой видеокарты для ноутбука. Конечно, всё это очень дорого, неудобно и заметно слабее десктопа. Но для ноутов ничего быстрее нет.
⇨ N8N. Автоматизируй процессы в пару кликов.
Примеры использования популярной платформы для автоматизации. Много раз про неё упоминал, видео приводил. Посмотрите, если кто ещё не знаком. Очень интересная тема. У видео длинное введение. Если более-менее понимаете, что такое n8n, то можно сразу примерно на середину перематывать, где идут примеры.
⇨ Управляемый свитч Sodola — обзор, настройка VLAN и возможностей Managed Switch
Обзор необычного 9-ти портового свитча, где 8 портов 2.5G и один 10G. Мне было интересно посмотреть обзор, хотя у меня нет ни одного устройства, которое бы поддерживало такие скорости. Удивился, что подобные свитчи такие дешёвые (6-10 т.р.). Я думал, это что-то на богатом, а оказывается, что уже давно нет.
⇨ Балансировка в nginx proxy manager (npm). Как и зачем?
Обзор неплохой веб панели для настройки Nginx в качестве обратного прокси. Я давно знаю этот продукт, писал про него. Он простой и удобный.
⇨ rwMarkable - Simple Self-Hosted Notes & Checklists (No Database Required!)
Обзор очень простого сервиса для хранения личных заметок. Их существуют десятки. В этом ничего примечательного не увидел, но посмотрите, может вам понравится. Мне кажется, в таких инструментах самое главное, чтобы вам лично понравился и показался удобным интерфейс. Всё остальное вторично, так как в реальности какой-то большой функциональности не надо, хотя кажется, что чем больше программа умеет, тем лучше. Тут хорошо то, что все заметки хранятся в текстовых файлах, без использования СУБД.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Депрессия и эмоциональное выгорание айтишника - личная история DevOps
Надежный хостинг FirstVDS! Переходи по ссылке и получай скидку 25% на первый месяц на любой тариф https://firstvds.ru/s/xi5dt
Психология айтишников довольно таки сложная штука. Эмоциональное выгорание, депрессия среди программистов не редкое дело. Все из…
Психология айтишников довольно таки сложная штука. Эмоциональное выгорание, депрессия среди программистов не редкое дело. Все из…
2👍51👎3
Меня постоянно в комментариях спрашивают, как я всё успеваю - настраивать системы, писать публикации, отвечать в чате и всё это в дополнение к большой семье. У меня 4-ро детей от 1 года до 11 лет. По сути малыши ещё. В последнее время я закончил стройку дома и переехал жить в Подмосковье. Устроил тут детей в сады, школы. Обустраиваю новую жизнь.
Давно не пишу о личном, чтобы не размывать тематику канала. Он и так по какой-то причине выпал из рекомендаций Telegram, хотя ничего не менял в основной тематике за последние 5 лет.
Не открою никому никакого секрета, потому что его нет. Я много успеваю, потому что много всего делаю и веду параллельно несколько проектов. Просто скрупулёзно и аккуратно день за днём тружусь, по шагам двигаясь к целям. Отмечу основные моменты:
1️⃣ Всегда и всё записываю, планирую. Для этого использую Singularity. Веду календари, списки дел. Без этого никуда. Текстовые заметки веду в Joplin. Туда тоже всё подряд пишу, чтобы ничего не забыть - и личное, и по работе.
2️⃣ Не отдыхаю с пожирателями времени. То есть не играю в компьютерные игры, не смотрю сериалы, не смотрю развлекательные ролики на ютубе. Да и кино не смотрю. Если только вместе с семьёй что-то вечером в выходные.
3️⃣ У меня везде выключены уведомления. Если я делаю какое-то дело, то меня ничего не отвлекает. Никаких чатов, уведомлений на смартфоне и т.д. Даже если тихо в помещении, надеваю либо беруши, либо наушники с шумоподавлением. Мне так проще концентрироваться. Музыку или что-то другое в фоне никогда не ставлю.
4️⃣ У меня стандартный подход к любому сложному масштабному делу. Просто беру и понемногу начинаю что-то делать. Не откладываю, не изучаю днями тему и т.д. Важно начинать делать, даже если не будет сразу получаться хорошо. В процессе делания всё начинает со временем складываться, как нужно. Главное - хоть небольшими шажками, но идти вперёд без остановок.
Например, я задумал раскрутить сайт и несколько лет каждую неделю обязательно писал статью. 5 лет назад я захотел раскрутить Telegram канал. Поставил себе цель - каждый будний день писать по 2 публикации. И все 5 лет следую этому правилу. Практически без исключений. Кто постоянно читает, это видит. То есть по сути всё просто. Бери и делай. Не ложусь спать, пока не подготовлю публикации. Для меня желанная награда - закончить все обязательные дела до 22 часов и спокойно лечь спать.
5️⃣ База для эффективной деятельности - поддержка семьи. Ты много успеваешь и мотивирован к продуктивной деятельности, когда тебя поддерживают и ты видишь, для чего трудишься.
Создание семьи - такое же дело, как и все остальные. Само по себе это не получается хорошо. В какой-то момент я решил, что хочу семью и много детей и стал действовать в прямом смысле - искать подходящую женщину, готовить почву для совместной жизни. Первый блин был комом, развёлся. Но продолжил двигаться дальше, набравшись опыта. На самотёк не пускал.
В завершении немного про выгорание напишу свои мысли. У меня такой график, что со стороны посмотреть - свихнуться можно, выгореть, всё бросить и уехать в самоизоляцию. Я никому свою жизнь не советую, поэтому и не пишу особо об этом. Каждому своё.
Самое главное - найти это своё и действовать по своим желаниям. Когда у тебя желания не твои, а навязанные, и ты действуешь по навязанным мотивам - выгораешь, тебя ничего не радует, жизнь рушится. Потому что это не твоя жизнь. Нужно найти себя, жить своей жизнью и ни о чём не жалеть. Меня супруга иногда спрашивает, когда очень устаю, не жалею ли я, что жизнь сложилась так, а не иначе. Вообще никогда не жалею. Всё сложилось так, как я захотел и сделал. Если кому и могу дать рекомендацию или пожелание, так это сделать так, как ты по-настоящему хочешь.
📌 Заметки по теме:
- Как у меня организован рабочий процесс
- Про детей
- Как я подхожу к любому делу
- Мужчины, будьте мужчинами
- Как не задалбываться на работе
- Как я развивался и искал себя
- Плюсы и минусы фриланса
- Не переезжайте в мегаполисы
- Из чего состоит успех в делах
- Всегда ищите то, что нравится
- Просто делай маленькие шаги каждый день
- Интервью со мной
#мысли
Давно не пишу о личном, чтобы не размывать тематику канала. Он и так по какой-то причине выпал из рекомендаций Telegram, хотя ничего не менял в основной тематике за последние 5 лет.
Не открою никому никакого секрета, потому что его нет. Я много успеваю, потому что много всего делаю и веду параллельно несколько проектов. Просто скрупулёзно и аккуратно день за днём тружусь, по шагам двигаясь к целям. Отмечу основные моменты:
Например, я задумал раскрутить сайт и несколько лет каждую неделю обязательно писал статью. 5 лет назад я захотел раскрутить Telegram канал. Поставил себе цель - каждый будний день писать по 2 публикации. И все 5 лет следую этому правилу. Практически без исключений. Кто постоянно читает, это видит. То есть по сути всё просто. Бери и делай. Не ложусь спать, пока не подготовлю публикации. Для меня желанная награда - закончить все обязательные дела до 22 часов и спокойно лечь спать.
Создание семьи - такое же дело, как и все остальные. Само по себе это не получается хорошо. В какой-то момент я решил, что хочу семью и много детей и стал действовать в прямом смысле - искать подходящую женщину, готовить почву для совместной жизни. Первый блин был комом, развёлся. Но продолжил двигаться дальше, набравшись опыта. На самотёк не пускал.
В завершении немного про выгорание напишу свои мысли. У меня такой график, что со стороны посмотреть - свихнуться можно, выгореть, всё бросить и уехать в самоизоляцию. Я никому свою жизнь не советую, поэтому и не пишу особо об этом. Каждому своё.
Самое главное - найти это своё и действовать по своим желаниям. Когда у тебя желания не твои, а навязанные, и ты действуешь по навязанным мотивам - выгораешь, тебя ничего не радует, жизнь рушится. Потому что это не твоя жизнь. Нужно найти себя, жить своей жизнью и ни о чём не жалеть. Меня супруга иногда спрашивает, когда очень устаю, не жалею ли я, что жизнь сложилась так, а не иначе. Вообще никогда не жалею. Всё сложилось так, как я захотел и сделал. Если кому и могу дать рекомендацию или пожелание, так это сделать так, как ты по-настоящему хочешь.
- Как у меня организован рабочий процесс
- Про детей
- Как я подхожу к любому делу
- Мужчины, будьте мужчинами
- Как не задалбываться на работе
- Как я развивался и искал себя
- Плюсы и минусы фриланса
- Не переезжайте в мегаполисы
- Из чего состоит успех в делах
- Всегда ищите то, что нравится
- Просто делай маленькие шаги каждый день
- Интервью со мной
#мысли
Please open Telegram to view this post
VIEW IN TELEGRAM
18👍337👎4
Давно запланировал актуализировать подборку self-hosted серверов для установки чат-сервера. Недавно пробовал и писал про Mattermost. Плюс, у меня было много заметок про Rocket.Chat.
Следующим по популярности и набору возможностей по моему мнению идёт Zulip. На днях как раз смотрел обзор этого чата. Автор сказал, что за последнее время вышло много обновлений, чат изменился в лучшую сторону. Я с ним знаком и внедрял его несколько лет назад. Решил посмотреть на него снова, что он из себя представляет на сегодняшний день.
У Zulip есть одна особенность, которая его отличает от остальных чатов - отдельные ветки обсуждений в рамках одного канала. К примеру, можно создать чат ИТ-отдел и в нём выделить несколько тем со своим ветвлением диалогов. Например - закупки, поддержка пользователей, настройка серверов, заявки и т.д.
Отмечу некоторые особенности Zulip:
▪️Голосовые и видео звонки возможны только через стороннюю интеграцию, например Jitsi.
▪️Есть удобная встроенная утилита для бэкапа, восстановления, переноса сервера.
▪️Нормальный перевод на русский язык. Не идеальный, но и не кровь из глаз.
▪️Ограничение free версии - пуш уведомления только для 10-ти пользователей.
▪️Есть возможность интеграции с AD.
▪️Поддержка ботов. Их много, они бесплатные, список тут.
▪️Есть утилита для миграции со Slack, Mattermost, Rocket.Chat.
▪️Код полностью открыт, self-hosted версия замкнута на себя.
Установить Zulip можно как напрямую, так и в Docker. Сами разработчики рекомендуют ставить напрямую, если у вас нет единого стандарта запуска приложений в докере. С их слов управлять не в докере будет проще: "Deploying with Docker moderately increases the effort required to install, maintain, and upgrade a Zulip installation".
Последую их совету и установлю напрямую. Делается это очень просто с помощью автоматического установщика. Я заранее подготовил доменное имя, чтобы сразу же во время установки получить сертификаты.
Установщик ругнулся на отсутствие swap. Создал его. После этого установка прошла нормально. Если у вас нет настроенного доменного имени и для теста вы хотите использовать самоподписанный сертификат, то добавьте ключ
В конце получил уникальную ссылку для создания организации. Создал её вместе с учётной записью администратора. Далее вы попадаете в список чатов. Мне лично с первого взгляда понравился веб интерфейс. Он будет, как обычно, неизменен и в браузере, и в клиенте, который можно установить на компьютер и смартфон. Есть даже CLI версия клиента.
Для клиентов есть как онлайн установщик, так и полностью автономный. Клиент, как обычно, написан на чём-то тяжёлом и модном, а конкретно на JavaScript. Скорее всего используется Electron, но я не уточнял. Нативный легковесный клиент есть только у Telegram, так что тут выбирать не приходится. У всех современных чатов тормозные клиенты.
Для регистрации пользователей в обязательном порядке используется подтверждение по email. Обойти это не получится. Так что для дальнейших тестов вам придётся настроить отправку по SMTP. При первом входе вам предложат прочитать инструкцию. Там всё просто.
Я немного потестировал чат, установил клиента. Лично мне он понравился больше Rocket.Chat и Mattermost. Лёгкий, лаконичный дизайн. Настроек и возможностей больше, чем у Mattermost и меньше, чем у Rocket, но мне этим Рокет и не нравится. Там такое меню управления переполненное, что заходить лишний раз не хочется. У Zulip всего немного и по делу. Логично и удобно распределено, переведено. Много полезных ботов с интеграциями.
Если бы сейчас надо было внедрять новый чат, думаю, что остановился бы на Zulip.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#chat
Следующим по популярности и набору возможностей по моему мнению идёт Zulip. На днях как раз смотрел обзор этого чата. Автор сказал, что за последнее время вышло много обновлений, чат изменился в лучшую сторону. Я с ним знаком и внедрял его несколько лет назад. Решил посмотреть на него снова, что он из себя представляет на сегодняшний день.
У Zulip есть одна особенность, которая его отличает от остальных чатов - отдельные ветки обсуждений в рамках одного канала. К примеру, можно создать чат ИТ-отдел и в нём выделить несколько тем со своим ветвлением диалогов. Например - закупки, поддержка пользователей, настройка серверов, заявки и т.д.
Отмечу некоторые особенности Zulip:
▪️Голосовые и видео звонки возможны только через стороннюю интеграцию, например Jitsi.
▪️Есть удобная встроенная утилита для бэкапа, восстановления, переноса сервера.
▪️Нормальный перевод на русский язык. Не идеальный, но и не кровь из глаз.
▪️Ограничение free версии - пуш уведомления только для 10-ти пользователей.
▪️Есть возможность интеграции с AD.
▪️Поддержка ботов. Их много, они бесплатные, список тут.
▪️Есть утилита для миграции со Slack, Mattermost, Rocket.Chat.
▪️Код полностью открыт, self-hosted версия замкнута на себя.
Установить Zulip можно как напрямую, так и в Docker. Сами разработчики рекомендуют ставить напрямую, если у вас нет единого стандарта запуска приложений в докере. С их слов управлять не в докере будет проще: "Deploying with Docker moderately increases the effort required to install, maintain, and upgrade a Zulip installation".
Последую их совету и установлю напрямую. Делается это очень просто с помощью автоматического установщика. Я заранее подготовил доменное имя, чтобы сразу же во время установки получить сертификаты.
# mkdir zulip && cd zulip# curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz# tar -xf zulip-server-latest.tar.gz# ./zulip-server-*/scripts/setup/install --push-notifications --certbot \ --email=zeroxzed@gmail.com --hostname=340751.simplecloud.ruУстановщик ругнулся на отсутствие swap. Создал его. После этого установка прошла нормально. Если у вас нет настроенного доменного имени и для теста вы хотите использовать самоподписанный сертификат, то добавьте ключ
--self-signed-cert.В конце получил уникальную ссылку для создания организации. Создал её вместе с учётной записью администратора. Далее вы попадаете в список чатов. Мне лично с первого взгляда понравился веб интерфейс. Он будет, как обычно, неизменен и в браузере, и в клиенте, который можно установить на компьютер и смартфон. Есть даже CLI версия клиента.
Для клиентов есть как онлайн установщик, так и полностью автономный. Клиент, как обычно, написан на чём-то тяжёлом и модном, а конкретно на JavaScript. Скорее всего используется Electron, но я не уточнял. Нативный легковесный клиент есть только у Telegram, так что тут выбирать не приходится. У всех современных чатов тормозные клиенты.
Для регистрации пользователей в обязательном порядке используется подтверждение по email. Обойти это не получится. Так что для дальнейших тестов вам придётся настроить отправку по SMTP. При первом входе вам предложат прочитать инструкцию. Там всё просто.
Я немного потестировал чат, установил клиента. Лично мне он понравился больше Rocket.Chat и Mattermost. Лёгкий, лаконичный дизайн. Настроек и возможностей больше, чем у Mattermost и меньше, чем у Rocket, но мне этим Рокет и не нравится. Там такое меню управления переполненное, что заходить лишний раз не хочется. У Zulip всего немного и по делу. Логично и удобно распределено, переведено. Много полезных ботов с интеграциями.
Если бы сейчас надо было внедрять новый чат, думаю, что остановился бы на Zulip.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#chat
2👍76👎5
Относительно недавно (2018 год) по меркам Linux в составе базовых системных утилит популярных дистрибутивов появилась утилита choom. Узнал о ней случайно. В Debian и Ubuntu она есть по умолчанию, отдельно ставить не надо. В других не проверял.
Забегая вперёд скажу, что лично я для неё применения не увидел, но решил всё равно написать для общего образования. Кому-то может пригодится. Не просто же так её написали и добавили в дистрибутивы. С помощью choom можно управлять таким параметром, как OOM score adjustment (oom_score_adj). На его основе OOM-killer принимает решение о том, какой процесс завершить при нехватке оперативной памяти в системе.
Choom работает с запущенными процессами на лету, используя их pid. Примерно так:
Посмотрели текущее значения
Проверяем:
Oom_score стал 0, а oom_score_adj, как и указали -1000. В данном примере pid 1994 - это процесс mariadbd. Удобней было бы сделать сразу вот так:
Вообще, принцип работы OOM-killer довольно замороченный. Как видно, у него есть два параметра oom_score и oom_score_adj. Первый показывает текущие накопленные баллы, которые динамически изменяются в зависимости от различных условий, а второй - это то, что задаётся вручную и тоже влияет на oom_score. Сделав oom_score_adj минимальным, то есть -1000, мы и oom_score уменьшили.
Вручную всё это менять имеет смысл только в каких-то отладочных целях. Для постоянной работы этими параметрами удобнее управлять через systemd. Просто указываем в unit файле сервиса нужные значения:
Перезапускаем сервис и проверяем. В случае с mariadb это будет выглядеть так. Делаем корректировку стандартного юнита:
Добавляем в конфигурацию:
Перечитываем параметры юнита и перезапускаем его.
Проверяем значение:
По сути choom удобен именно для просмотра. Смотреть значения с помощью утилиты быстрее и проще, чем напрямую:
Она по сути именно это и делает. И меняет значение тоже переопределяя именно эти параметры.
На практике я никогда не занимался настройкой
Исключение, наверное, для каких-то специфических случаев, когда целенаправленно нужно использовать всю память сервера, но при этом гарантированно иметь работающим какое-то приложение. Я не могу придумать таких примеров, но думаю, что они есть. Если кто-то знает такие истории, поделитесь в комментариях. Когда вам приходилось целенаправленно настраивать OOMScoreAdjust? В голову приходят агенты мониторинга. Желательно, чтобы они всегда работали, но на практике я не видел, чтобы их первым отключал OOM-killer.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #systemd
Забегая вперёд скажу, что лично я для неё применения не увидел, но решил всё равно написать для общего образования. Кому-то может пригодится. Не просто же так её написали и добавили в дистрибутивы. С помощью choom можно управлять таким параметром, как OOM score adjustment (oom_score_adj). На его основе OOM-killer принимает решение о том, какой процесс завершить при нехватке оперативной памяти в системе.
Choom работает с запущенными процессами на лету, используя их pid. Примерно так:
# choom -p 1994pid 1994's current OOM score: 684pid 1994's current OOM score adjust value: 0Посмотрели текущее значения
oom_score и oom_score_adj. Для того, чтобы максимально уменьшить шанс для процесса быть убитыми, ему нужно присвоить параметр oom_score_adj -1000. Соответственно, параметр 1000 будет означать максимальный шанс. То есть там разбег от -1000 до 1000. И чем меньше значение, тем меньше шанса быть завершённым. # choom -p 1994 -n -1000Проверяем:
# choom -p 1994pid 1994's current OOM score: 0pid 1994's current OOM score adjust value: -1000Oom_score стал 0, а oom_score_adj, как и указали -1000. В данном примере pid 1994 - это процесс mariadbd. Удобней было бы сделать сразу вот так:
# choom -p $(pidof mariadbd) -n 1000Вообще, принцип работы OOM-killer довольно замороченный. Как видно, у него есть два параметра oom_score и oom_score_adj. Первый показывает текущие накопленные баллы, которые динамически изменяются в зависимости от различных условий, а второй - это то, что задаётся вручную и тоже влияет на oom_score. Сделав oom_score_adj минимальным, то есть -1000, мы и oom_score уменьшили.
Вручную всё это менять имеет смысл только в каких-то отладочных целях. Для постоянной работы этими параметрами удобнее управлять через systemd. Просто указываем в unit файле сервиса нужные значения:
[Service]............OOMScoreAdjust=-800............Перезапускаем сервис и проверяем. В случае с mariadb это будет выглядеть так. Делаем корректировку стандартного юнита:
# systemctl edit mariadbДобавляем в конфигурацию:
[Service]OOMScoreAdjust=-800Перечитываем параметры юнита и перезапускаем его.
# systemctl daemon-reload# systemctl restart mariadbПроверяем значение:
# choom -p $(pidof mariadbd)pid 2274's current OOM score: 152pid 2274's current OOM score adjust value: -800По сути choom удобен именно для просмотра. Смотреть значения с помощью утилиты быстрее и проще, чем напрямую:
# cat /proc/2274/oom_score# cat /proc/2274/oom_score_adjОна по сути именно это и делает. И меняет значение тоже переопределяя именно эти параметры.
На практике я никогда не занимался настройкой
OOMScoreAdjust. Если на сервере кончается память и приходит OOM-killer - это аварийная ситуация. Надо идти и разбираться, куда утекает память и почему её не хватает. Обычно после этого её должно хватать. Исключение, наверное, для каких-то специфических случаев, когда целенаправленно нужно использовать всю память сервера, но при этом гарантированно иметь работающим какое-то приложение. Я не могу придумать таких примеров, но думаю, что они есть. Если кто-то знает такие истории, поделитесь в комментариях. Когда вам приходилось целенаправленно настраивать OOMScoreAdjust? В голову приходят агенты мониторинга. Желательно, чтобы они всегда работали, но на практике я не видел, чтобы их первым отключал OOM-killer.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #systemd
3👍84👎1
Собрал подборку из заметок на канале на тему инструментов для ведения документации. Ни разу этого не делал, а материала накопилось прилично. В списке явно прослеживаются 2 категории продуктов:
🔹классические в формате wiki;
🔹статические генераторы.
Так что список будет состоять из двух этих категорий, и в конце всё остальное, что останется, в третьей.
Wiki:
◽️DocuWIKI, MediaWiki - по ним не было отдельных заметок, но не мог пропустить эти очень старые и известные продукты. Я сам не раз составлял документацию в DocuWIKI. Это очень простая wiki-подобная панель управления документами, которая работает на php, не требует СУБД, а все заметки хранит в текстовых md файлах. Очень легко бэкапить и синхронизировать документацию.
◽️Wiki.js - современная реализация технологии wiki. Очень хорошая функциональность. Среди всех современных wiki, это самая навороченная и красивая. Там и API, и аутентификаций куча всяких, продвинутый поиск, синхронизация с git и многое другое.
◽️BookStack - ещё один движок на базе wiki, но не только. Больше похож на классическую CMS на PHP, которая в том числе поддерживает wiki. Это для любителей олдскула, хотя проект не брошен. Развивается и поддерживается. Есть аутентификация через AD.
Статические генераторы:
◽️MkDocs - как мне кажется, наиболее популярный генератор именно для документации. С его помощью написана документация для многих известных проектов. Например - Rocky Linux. Принцип там такой - пишите документация в формате md, хранить можно в git. Отдельно пишите инструкцию по генерации сайта в формате yaml. И после каждого обновления контента запускаете генерацию новых страничек или всего сайта.
◽️Hugo - это в целом самый популярный генератор статических сайтов, который в том числе используют для документации, но вообще он для сайтов общего назначения. Многие техноблогеры используют этот движок для своих блогов.
◽️Antora - продвинутый инструмент для ведения документации профессиональными техническими писателями. Там есть деление на продукты, вертки, версии. Управление документацией ведётся по принципу docs as code.
◽️Grav - универсальная CMS, которая в том числе подходит для хранения документации. У неё есть отдельная тема для синхронизации контента с git репозиторием. Сама CMS вместе с markdown редактором работает на PHP. Это может быть удобно, если хочется писать текст во встроенном редакторе, а не где-то на стороне.
◽️Docusaurus - ещё один статический генератор, который изначально был заточен под ведение документации и написан в Facebook. У него простой, лаконичный дизайн, интеграция с git, документы хранит в формате md. Написан на Go, расширяется плагинами. Нормальное современное решение для простой документации.
Разное:
◽️Onlyoffice - это целый портал для совместной работы, который включает в том числе отдельный раздел для wiki. Но лично мне нравится в нём вести текстовую документацию в формате обычных документов docx и xlsx с общим доступом к файлам. Это в целом удобно, так как хранится наглядная история версий, можно скачать файл локально, куда-то переслать, поработать с ним на компе в десктопном редакторе.
Перечислил то, что знал и частично использовал. Если у вас есть ещё рекомендации бесплатных продуктов для ведения документации, поделитесь в комментариях.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wiki #docs #подборка
🔹классические в формате wiki;
🔹статические генераторы.
Так что список будет состоять из двух этих категорий, и в конце всё остальное, что останется, в третьей.
Wiki:
◽️DocuWIKI, MediaWiki - по ним не было отдельных заметок, но не мог пропустить эти очень старые и известные продукты. Я сам не раз составлял документацию в DocuWIKI. Это очень простая wiki-подобная панель управления документами, которая работает на php, не требует СУБД, а все заметки хранит в текстовых md файлах. Очень легко бэкапить и синхронизировать документацию.
◽️Wiki.js - современная реализация технологии wiki. Очень хорошая функциональность. Среди всех современных wiki, это самая навороченная и красивая. Там и API, и аутентификаций куча всяких, продвинутый поиск, синхронизация с git и многое другое.
◽️BookStack - ещё один движок на базе wiki, но не только. Больше похож на классическую CMS на PHP, которая в том числе поддерживает wiki. Это для любителей олдскула, хотя проект не брошен. Развивается и поддерживается. Есть аутентификация через AD.
Статические генераторы:
◽️MkDocs - как мне кажется, наиболее популярный генератор именно для документации. С его помощью написана документация для многих известных проектов. Например - Rocky Linux. Принцип там такой - пишите документация в формате md, хранить можно в git. Отдельно пишите инструкцию по генерации сайта в формате yaml. И после каждого обновления контента запускаете генерацию новых страничек или всего сайта.
◽️Hugo - это в целом самый популярный генератор статических сайтов, который в том числе используют для документации, но вообще он для сайтов общего назначения. Многие техноблогеры используют этот движок для своих блогов.
◽️Antora - продвинутый инструмент для ведения документации профессиональными техническими писателями. Там есть деление на продукты, вертки, версии. Управление документацией ведётся по принципу docs as code.
◽️Grav - универсальная CMS, которая в том числе подходит для хранения документации. У неё есть отдельная тема для синхронизации контента с git репозиторием. Сама CMS вместе с markdown редактором работает на PHP. Это может быть удобно, если хочется писать текст во встроенном редакторе, а не где-то на стороне.
◽️Docusaurus - ещё один статический генератор, который изначально был заточен под ведение документации и написан в Facebook. У него простой, лаконичный дизайн, интеграция с git, документы хранит в формате md. Написан на Go, расширяется плагинами. Нормальное современное решение для простой документации.
Разное:
◽️Onlyoffice - это целый портал для совместной работы, который включает в том числе отдельный раздел для wiki. Но лично мне нравится в нём вести текстовую документацию в формате обычных документов docx и xlsx с общим доступом к файлам. Это в целом удобно, так как хранится наглядная история версий, можно скачать файл локально, куда-то переслать, поработать с ним на компе в десктопном редакторе.
Перечислил то, что знал и частично использовал. Если у вас есть ещё рекомендации бесплатных продуктов для ведения документации, поделитесь в комментариях.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wiki #docs #подборка
2👍105👎2
Mikrotik меня на днях удивил. Увидел мельком в одном из видео на ютубе упоминание функции Kid Control. Думаю, такой, что это за контроль, впервые слышу. Открываю RouterOS 7 и и вижу там IP ⇨ Kid Control. Очень удивился. Я вообще впервые увидел этот раздел.
Думаю, наверное это в 7-й версии появилось, поэтому я не видел. Я все старые устройства оставил на родной для них 6-й версии. Специально не обновлял. А с 7-й мало работал, только с новыми устройствами.
Захожу в RouterOS 6, а там этот контроль тоже есть. Тут я ещё сильнее удивился. Пошёл в поиск, оказалось, что эта функциональность появилась в 2017 году. Как я умудрился не то, что её ни разу не заметить лично, но даже не слышать никогда о ней. Проходил обучение MTCNA, не помню, чтобы там об этом шла речь. Либо у меня из памяти всё это вылетело.
Проверил поиск по каналу, ни разу не писал о нём, значит не знал. Посмотрел поиск по чату, нашёл одно упоминание. Мне как раз говорят, что есть детский контроль, а я удивился и спросил, что это такое. Ну и благополучно забыл, хотя написал: "Пипец. Столько лет настраиваю Микротики. Никогда не замечал и не заглядывал в этот раздел. Даже не знал про его существование."
Дело в том, что я настраиваю детям ограничения, но делаю это примерно так:
Создаю списки устройств детей и делаю для них правила, которые начинают работать в ночное время, чтобы выключать доступ в интернет. У меня родительский контроль так работал. А он оказывается примерно так же, но в другой форме организован в отдельном разделе.
В общем, чтобы в очередной раз об этом не забыть, пишу заметку и рассказываю, как этот родительский контроль работает.
В разделе IP ⇨ Kid Control есть 2 вкладки: Kids и Devices. В раздел Kids добавляем ребёнка и назначаем ему часы, когда интернет будет работать. Там же можно настроить ограничение скорости. В целом это тоже может быть полезно. Для того, чтобы делать уроки, смотреть расписание и искать какую-то текстовую информацию большая скорость не нужна. Можно ограничить, чтобы не работали видео и не было соблазна быстренько что-то посмотреть. А вечером, когда уроки закончены, ограничение убрать.
В Devices добавляем по MAC адресу устройства ребёнка и привязываем их к нему.
Такой вот нехитрый контроль, который по факту делает примерно то же самое, что и я вручную. Для ограничения интернета добавляет и убирает блокирующие правила в файрвол для IP адресов устройств детей. А для ограничения скорости добавляет правила в Queues ⇨ Simple Queues.
Я этот же контроль придумал сам, только скорость не ограничивал. Большого смысла в этом не вижу. У меня дети по факту уроки нормально делают самостоятельно днём и с интернетом. Отключаю вечером, чтобы не было лишних разговор и разбирательств перед сном. Смартфоны тоже выключаются. Время пришло, всё автоматически выключилось. Спорить и что-то просить не у кого. Все идут чистить зубы и спать.
Вроде разработчики постарались сделать удобно, но по факту получилось так себе. Списки IP адресов устройств формируются на основе таблицы ARP. Если перезагрузить роутер в тот момент, когда устройства детей выключены, их IP адресов в ARP таблице не будет. Динамические правила в файрвол не добавятся. Я сначала не понял, почему там после перезагрузки пусто. Потом сообразил, когда посмотреть таблицу ARP и не увидел там нужных устройств.
Такая реализация может запутать в настройке файрвола. Проще как я раньше делал, писать правила с указанием времени вручную. Они всегда перед глазами, хоть и отключаются вне заданного диапазона времени.
#mikrotik #дети
Думаю, наверное это в 7-й версии появилось, поэтому я не видел. Я все старые устройства оставил на родной для них 6-й версии. Специально не обновлял. А с 7-й мало работал, только с новыми устройствами.
Захожу в RouterOS 6, а там этот контроль тоже есть. Тут я ещё сильнее удивился. Пошёл в поиск, оказалось, что эта функциональность появилась в 2017 году. Как я умудрился не то, что её ни разу не заметить лично, но даже не слышать никогда о ней. Проходил обучение MTCNA, не помню, чтобы там об этом шла речь. Либо у меня из памяти всё это вылетело.
Проверил поиск по каналу, ни разу не писал о нём, значит не знал. Посмотрел поиск по чату, нашёл одно упоминание. Мне как раз говорят, что есть детский контроль, а я удивился и спросил, что это такое. Ну и благополучно забыл, хотя написал: "Пипец. Столько лет настраиваю Микротики. Никогда не замечал и не заглядывал в этот раздел. Даже не знал про его существование."
Дело в том, что я настраиваю детям ограничения, но делаю это примерно так:
/ip firewall address-list
add address=192.168.137.110 list=Ivan
add address=192.168.137.111 list=Olga
/ip firewall filter
add action=reject chain=forward reject-with=icmp-network-unreachable src-address-list=Ivan time=\
22h-7h,sun,mon,tue,wed,thu,fri,sat
add action=reject chain=forward reject-with=icmp-network-unreachable src-address-list=Olga time=\
21h-7h,sun,mon,tue,wed,thu,fri,sat
Создаю списки устройств детей и делаю для них правила, которые начинают работать в ночное время, чтобы выключать доступ в интернет. У меня родительский контроль так работал. А он оказывается примерно так же, но в другой форме организован в отдельном разделе.
В общем, чтобы в очередной раз об этом не забыть, пишу заметку и рассказываю, как этот родительский контроль работает.
В разделе IP ⇨ Kid Control есть 2 вкладки: Kids и Devices. В раздел Kids добавляем ребёнка и назначаем ему часы, когда интернет будет работать. Там же можно настроить ограничение скорости. В целом это тоже может быть полезно. Для того, чтобы делать уроки, смотреть расписание и искать какую-то текстовую информацию большая скорость не нужна. Можно ограничить, чтобы не работали видео и не было соблазна быстренько что-то посмотреть. А вечером, когда уроки закончены, ограничение убрать.
В Devices добавляем по MAC адресу устройства ребёнка и привязываем их к нему.
Такой вот нехитрый контроль, который по факту делает примерно то же самое, что и я вручную. Для ограничения интернета добавляет и убирает блокирующие правила в файрвол для IP адресов устройств детей. А для ограничения скорости добавляет правила в Queues ⇨ Simple Queues.
Я этот же контроль придумал сам, только скорость не ограничивал. Большого смысла в этом не вижу. У меня дети по факту уроки нормально делают самостоятельно днём и с интернетом. Отключаю вечером, чтобы не было лишних разговор и разбирательств перед сном. Смартфоны тоже выключаются. Время пришло, всё автоматически выключилось. Спорить и что-то просить не у кого. Все идут чистить зубы и спать.
Вроде разработчики постарались сделать удобно, но по факту получилось так себе. Списки IP адресов устройств формируются на основе таблицы ARP. Если перезагрузить роутер в тот момент, когда устройства детей выключены, их IP адресов в ARP таблице не будет. Динамические правила в файрвол не добавятся. Я сначала не понял, почему там после перезагрузки пусто. Потом сообразил, когда посмотреть таблицу ARP и не увидел там нужных устройств.
Такая реализация может запутать в настройке файрвола. Проще как я раньше делал, писать правила с указанием времени вручную. Они всегда перед глазами, хоть и отключаются вне заданного диапазона времени.
#mikrotik #дети
👍129👎8
📊 Пришло время очередного опроса. Давно хотел его организовать, да всё забывал. На другое отвлекался. Тема очень дискуссионная. На канале не раз поднимались споры на этот счёт, но никогда не было опроса.
Интересно посмотреть на распределение по вопросу, кто каким текстовым редактором пользуется в консоли Linux. Скажу за себя. Я использую
Если стоит
Вариант ответа будет только один. Так что выбирайте тот, что вам больше нравится, даже если работаете в разных.
#опрос
Интересно посмотреть на распределение по вопросу, кто каким текстовым редактором пользуется в консоли Linux. Скажу за себя. Я использую
mcedit. Не считаю его очень удобным, но привык. Мои потребности закрывает, так как я особо много в консоли не редактирую. Если что-то большое, масштабное, то делаю на компьютере в VSCode.Если стоит
nano, то буду работать в нём. Vi или vim не люблю, закрою, если случайно откроется 😆 Но приходится мириться, так как по visudo открывается. Я обычно не переназначаю. Хотя это было раньше, на rpm дистрибутивах, с которыми я всё реже взаимодействую. В deb visudo открывает nano. И это здорово. Про vi теперь не вспоминаю.Вариант ответа будет только один. Так что выбирайте тот, что вам больше нравится, даже если работаете в разных.
#опрос
👍70👎3
Какой текстовый редактор вы предпочитаете для работы в консоли ОС на базе Linux?
Anonymous Poll
20%
mcedit
19%
vim
51%
nano
5%
vi
0%
emacs
2%
neovim
1%
Другой (напишу в комментариях)
3%
Не работаю в консоли Linux (посмотреть результаты)
👍94👎3
На днях на хабре прочитал полезную статью, поэтому решил акцентировать ваше внимание на ней. Я в принципе не знал, что так можно сделать. Не приходилось сталкиваться.
⇨ Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
Думаю у многих всё ещё трудятся устаревшие операционные системы Windows. По моим наблюдениям, чаще всего это Windows Server 2012 R2. Не помню уже чем они в то время так привлекали внимание, но мне кажется, их наустанавливали значительно больше, чем последующих 2016-х и 2019-х. Таковые имеются и у меня.
По понятным причинам, установить обновления на Windows Server 2012 R2 либо сложно, либо невозможно, потому что в свободный доступ они больше не публикуются. Есть обходные пути, но не сказать, что они простые.
Автор предлагает следующий простой и эффективный способ защиты удалённых подключений.
1️⃣ Разворачиваем роль центра сертификации.
2️⃣ Выпускаем сертификаты для пользователей.
3️⃣ На целевых серверах, куда пользователи будут подключаться по SMB или RDP, на штатном файрволе настраиваем правила входящих соединений, где включаем параметр Разрешить только безопасное подключение. Дополнительно можно ограничить список компьютеров, с которых разрешено подключаться. Если это не терминальный сервер, а обычный, куда по RDP подключаются только админы, можно ограничить список компьютеров.
4️⃣ Отдельно создаём правило для безопасных соединений, где включаем проверку подлинности компьютера, если настраивали ограничения по ним, и проверку подлинности пользователя, которая выполняется с помощью ранее выпущенного сертификата с нашего CA.
Теперь если у пользователя нет сертификата, в подключении будет отказано. Это не даёт стопроцентной защиты, но заметно сужает вектор атак, так как без сертификата по RDP или SMB уже не подключиться. А именно в этих сервисах обычно находят фатальные уязвимости.
Настраивается всё это относительно просто. В статье пошаговая инструкция. Странно, что у статьи так мало просмотров и совсем нет комментариев. Мне кажется, довольно актуальная информация. Меня постоянно беспокоят эти устаревшие системы. Конечно, их надо обновлять, но как это обычно бывает, не всегда это просто сделать по различным причинам. А где-то и невозможно. Я лично обслуживал системы для станков, которые нельзя было обновить. Продавалась связка станок-компьютер с драйверами под конкретную версию.
#windows #security
⇨ Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
Думаю у многих всё ещё трудятся устаревшие операционные системы Windows. По моим наблюдениям, чаще всего это Windows Server 2012 R2. Не помню уже чем они в то время так привлекали внимание, но мне кажется, их наустанавливали значительно больше, чем последующих 2016-х и 2019-х. Таковые имеются и у меня.
По понятным причинам, установить обновления на Windows Server 2012 R2 либо сложно, либо невозможно, потому что в свободный доступ они больше не публикуются. Есть обходные пути, но не сказать, что они простые.
Автор предлагает следующий простой и эффективный способ защиты удалённых подключений.
Теперь если у пользователя нет сертификата, в подключении будет отказано. Это не даёт стопроцентной защиты, но заметно сужает вектор атак, так как без сертификата по RDP или SMB уже не подключиться. А именно в этих сервисах обычно находят фатальные уязвимости.
Настраивается всё это относительно просто. В статье пошаговая инструкция. Странно, что у статьи так мало просмотров и совсем нет комментариев. Мне кажется, довольно актуальная информация. Меня постоянно беспокоят эти устаревшие системы. Конечно, их надо обновлять, но как это обычно бывает, не всегда это просто сделать по различным причинам. А где-то и невозможно. Я лично обслуживал системы для станков, которые нельзя было обновить. Продавалась связка станок-компьютер с драйверами под конкретную версию.
#windows #security
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
На многих предприятиях остаются всё ещё работать старые версии операционных систем windows, которые не обновляются, или просто не установлены обновления по непонятным причинам. Типичный ответ у...
👍121👎2
Как понять, что системе на базе Linux требуется перезагрузка? Самый простой способ - использовать программу needrestart (deb дистрибутивы) или needs-restarting (rpm дистрибутивы). Я про неё подробно рассказывал. Её можно использовать для собственного мониторинга. Также другой софт может на неё опираться. Например, Lynis.
Needrestart установлен не всегда и не везде. Например, в базовых образах LXC контейнеров в Proxmox его нет. Если система не ваша, то самостоятельно лучше ничего не ставить.
Косвенно узнать, что у нас со службами и перезагрузкой можно очень простым и привычным способом, но для других задач. На помощью придёт lsof.
Тут видно удалённые файлы системных сервисов, таких как systemd, sshd, ну и bash заодно. То есть было обновление, приехали новые версии этих файлов, заменили старые. Но так как службы не перезапускались, они до сих пор используют удалённые файлы.
Для systemd существует специальная команда для полного перезапуска службы в том числе после обновления:
Её, кстати, часто ошибочно предлагают ИИ, когда изменяются настройки юнитов. Использовать её в этом случае не стоит. К сожалению, эта команда не всегда помогает запустить systemd с обновлённым бинарём. В таком случае поможет только перезагрузка.
С другими службами проще. Для обновления
А вот если изменился systemd, glibc или ядро, то тут без reboot уже не обойтись. Ядро, кстати, можно так посмотреть:
Это текущая версия, а вот список установленных ядер:
Установлен пакет с более свежим ядром. Надо перезагружаться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Needrestart установлен не всегда и не везде. Например, в базовых образах LXC контейнеров в Proxmox его нет. Если система не ваша, то самостоятельно лучше ничего не ставить.
Косвенно узнать, что у нас со службами и перезагрузкой можно очень простым и привычным способом, но для других задач. На помощью придёт lsof.
# lsof -nP +L1 | grep '(deleted)'
systemd-l 488 root txt REG 8,1 281096 0 270929 /usr/lib/systemd/systemd-logind (deleted)
dockerd 526 root txt REG 8,1 75181152 0 265728 /usr/sbin/dockerd (deleted)
sshd 532 root txt REG 8,1 1265432 0 262298 /usr/sbin/sshd (deleted)
systemd 582 root txt REG 8,1 92544 0 270899 /usr/lib/systemd/systemd (deleted)
(sd-pam) 584 root txt REG 8,1 92544 0 270899 /usr/lib/systemd/systemd (deleted)
bash 647 root txt REG 8,1 1265648 0 263309 /usr/bin/bash (deleted)
Тут видно удалённые файлы системных сервисов, таких как systemd, sshd, ну и bash заодно. То есть было обновление, приехали новые версии этих файлов, заменили старые. Но так как службы не перезапускались, они до сих пор используют удалённые файлы.
Для systemd существует специальная команда для полного перезапуска службы в том числе после обновления:
# systemctl daemon-reexec
Её, кстати, часто ошибочно предлагают ИИ, когда изменяются настройки юнитов. Использовать её в этом случае не стоит. К сожалению, эта команда не всегда помогает запустить systemd с обновлённым бинарём. В таком случае поможет только перезагрузка.
С другими службами проще. Для обновления
sshd и bash достаточно переподключиться по SSH. В новой сессии загрузятся уже новые бинарники.А вот если изменился systemd, glibc или ядро, то тут без reboot уже не обойтись. Ядро, кстати, можно так посмотреть:
# uname -r
6.1.0-35-amd64
Это текущая версия, а вот список установленных ядер:
# dpkg -l | grep linux-image
.................................
ii linux-image-6.1.0-39-amd64 6.1.148-1 amd64 Linux 6.1 for 64-bit PCs (signed)
Установлен пакет с более свежим ядром. Надо перезагружаться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
1👍150👎1
Поделюсь с вами необычным сервисом. Необычен он тем, что полностью бесплатно даёт интересные возможности, правда нужны они далеко не всем.
⇨ https://tastewp.com
С помощью этого сервиса можно бесплатно, без регистрации и вообще каких-то дополнительных действий получить себе в управление на 2-е суток чистую версию Wordpress.
Актуально это будет только тем, кто работает с Wordpress. Очень удобно проверить какие-то темы, плагины, загрузить бэкап своего сайта и посмотреть, как он заработает в новом окружении.
Свежесозданный сайт на удивление очень быстро работает. Удобно что-то проверять, смотреть. На своих серверах такой скорости работы админки не видел.
#бесплатно #wordpress
⇨ https://tastewp.com
С помощью этого сервиса можно бесплатно, без регистрации и вообще каких-то дополнительных действий получить себе в управление на 2-е суток чистую версию Wordpress.
Актуально это будет только тем, кто работает с Wordpress. Очень удобно проверить какие-то темы, плагины, загрузить бэкап своего сайта и посмотреть, как он заработает в новом окружении.
Свежесозданный сайт на удивление очень быстро работает. Удобно что-то проверять, смотреть. На своих серверах такой скорости работы админки не видел.
#бесплатно #wordpress
👍46👎1
backup-postgresql-restic.sh
2.1 KB
🔥 Бэкап баз postgresql с помощью restic!
Вновь возвращаюсь к очень удобному инструменту для бэкапов restic. Последнее время часто стал его использовать. Дальше вы поймёте, почему. На создание бэкапов баз данных с его помощью меня навела вот эта статья:
⇨ Restic: эффективное резервное копирование из Stdin
Автор с помощью restic дампит базы данных в Kubernetes. Я немного переделал его решение для своих локальных бэкапов. Основная проблема, которая там решена - корректная отработка ошибок снятия дампа. Я до этого сам не догадался, правда не сильно и пытался, поэтому дампил по старинке сначала в файл, проверял, а потом уже куда-то на хранение отправлял.
Но можно всё это сделать на лету и с проверкой ошибок. То есть делается дамп и тут же через pipe отправляется в restic. Этот способ удобен по нескольким причинам:
1️⃣ Самое основное - сырые дампы в restic очень хорошо дедуплицируются и экономят место. Если между дампами небольшие изменения, то даже хранение большого количества файлов за разные дни не съедает место на хранилище в отличие от обычного хранения в исходном виде на файловой системе.
2️⃣ Прямая отправка данных с pg_dump в restic исключает промежуточное сохранение, что существенно экономит ресурс SSD дисков, если у вас много баз приличного размера. Да и банально быстрее получается.
3️⃣ Если во время снятия дампа будет ошибка, то такой бэкап помечается отдельным тэгом и по этому тэгу вы сможете понять, что у вас какая-то проблема. Я специально проверил этот момент. Отрабатывает корректно. Если дамп прерывается по какой-то причине и не завершается без ошибок, то этот бэкап помечается отдельным тэгом.
В статье у автора подробно всё рассказано, не буду на этом останавливаться. Покажу свой итоговый скрипт, который бэкапит дампы условно локально, а не в S3. Если надо в S3 или куда-то ещё, то просто измените переменную
Надо убрать ключ
Это, как я понял, связано с тем, что ключ
И ещё важный момент. Не забудьте сохранить пароль от репозитория, который тоже задаётся в скрипте. Так как пароль передаётся в виде переменной окружения, его можно хранить где-то отдельно и подгружать перед запуском основного скрипта. Я в предыдущей заметке про restic упоминал об этом и показывал пример в конце.
Сам скрипт прикрепил к сообщению. Также продублировал его в публичный репозиторий. Не забудьте поменять переменные под свои нужды и окружение.
Полезные материалы по теме:
▪️Описание Restic с примерами
▪️Мониторинг Restic с помощью Zabbix и Prometheus
▪️Бэкап с помощью Restic в S3 на примере Selectel
Restic очень удобный инструмент для бэкапов. Рекомендую присмотреться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #restic
Вновь возвращаюсь к очень удобному инструменту для бэкапов restic. Последнее время часто стал его использовать. Дальше вы поймёте, почему. На создание бэкапов баз данных с его помощью меня навела вот эта статья:
⇨ Restic: эффективное резервное копирование из Stdin
Автор с помощью restic дампит базы данных в Kubernetes. Я немного переделал его решение для своих локальных бэкапов. Основная проблема, которая там решена - корректная отработка ошибок снятия дампа. Я до этого сам не догадался, правда не сильно и пытался, поэтому дампил по старинке сначала в файл, проверял, а потом уже куда-то на хранение отправлял.
Но можно всё это сделать на лету и с проверкой ошибок. То есть делается дамп и тут же через pipe отправляется в restic. Этот способ удобен по нескольким причинам:
В статье у автора подробно всё рассказано, не буду на этом останавливаться. Покажу свой итоговый скрипт, который бэкапит дампы условно локально, а не в S3. Если надо в S3 или куда-то ещё, то просто измените переменную
REPO_PREFIX в скрипте и добавьте переменных для доступа к бакетам. Плюс, я поменял формат хранения данных. Вместо tar выгружаю в текстовый sql файл. Мне так удобнее. Ещё исправил там небольшую ошибку, которую выявил во время тестов. В строке:restic forget -r "${REPO_PREFIX}/$db" --group-by=tags --keep-tag "completed"Надо убрать ключ
--group-by=tags, иначе команда на очистку будет возвращать ошибку:refusing to delete last snapshot of snapshot group "tags [job-8dd4f544]"Это, как я понял, связано с тем, что ключ
--keep-tag не позволяет удалить при группировке по тэгам полную группу тэгов, если в ней не останется хотя бы одного снепшота. А так как у нас все тэги с job уникальны, все проблемные снепшоты будут с уникальными тэгами и по сути одни в группе. Поэтому группировку --group-by=tags надо убрать. По крайней мере у меня, когда я убрал, ошибка ушла и очистка стала нормально отрабатывать. В доках это так объясняется: "The forget command will exit with an error if all snapshots in a snapshot group would be removed as none of them have the specified tags."И ещё важный момент. Не забудьте сохранить пароль от репозитория, который тоже задаётся в скрипте. Так как пароль передаётся в виде переменной окружения, его можно хранить где-то отдельно и подгружать перед запуском основного скрипта. Я в предыдущей заметке про restic упоминал об этом и показывал пример в конце.
Сам скрипт прикрепил к сообщению. Также продублировал его в публичный репозиторий. Не забудьте поменять переменные под свои нужды и окружение.
Полезные материалы по теме:
▪️Описание Restic с примерами
▪️Мониторинг Restic с помощью Zabbix и Prometheus
▪️Бэкап с помощью Restic в S3 на примере Selectel
Restic очень удобный инструмент для бэкапов. Рекомендую присмотреться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #restic
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍111👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Youtube показал в рекомендациях тематический шорт:
▶️ POV: You are a Sys Admin
Смотрю, много просмотров и лайков для нашей темы. Думаю, что-то интересное. Посмотрел раз, два, три. Потом включил перевод, посмотрел ещё пару раз и не понял. В чём тут юмор? Прочитал комментарии и всё равно не понял.
Решил спросить у ChatGPT. Как оказалось, видео с ютуба он смотреть не может. Пришлось скачать и загрузить ему в чат. На что он ответил, что видео видит, а звук не слышит. Загрузил ему субтитры на английском. И он мне всё объяснил.
------------------------------------------------------
◽️Сотрудник просит change request (официальное разрешение на изменения), чтобы поработать с серверами.
◽️Само по себе это звучит абсурдно, ведь change request обычно оформляют для изменения серверов, а не для того, чтобы только начать работать с ними.
◽️Он возмущается: «Что я, инженер первой линии (tier one)?» — намекая, что такие формальности и бюрократия свойственны для самых простых задач.
◽️Финал: «IT-менеджер бы меня убил» — подчеркивает, что без бумажки он вообще не имеет права ничего делать, иначе будут большие проблемы.
Юмор в том, что ролик высмеивает реальность работы системных администраторов: иногда вместо настоящей технической работы больше времени уходит на согласования, бюрократию и правила «чтобы никто не тронул сервер без бумажки».
Давай разберём по слоям, на чём держится шутка в этом видео:
🔹 1. Буквальный уровень
Фраза «i need a change request to work on these servers» звучит нелепо: админ вроде бы просто хочет поработать, но ему нужен специальный документ. Для несведущего зрителя это выглядит как чрезмерная бюрократия.
🔹 2. Ирония
Ирония в том, что админ должен запрашивать разрешение на то, что по его должности и так входит в обязанности. Это как если бы водитель автобуса просил письменное разрешение, чтобы завести двигатель.
🔹 3. Профессиональный юмор
Change request — реальный процесс в ITIL/DevOps, когда любое изменение инфраструктуры фиксируется и согласовывается.
Tier one (1-я линия поддержки) — обычно выполняет простые задачи (перезапуск, проверка логов), а не занимается управлением серверами.
Герой намекает, что бюрократия опускает его уровень работы до "самых простых тикетов".
🔹 4. Гипербола (преувеличение)
«The IT manager would literally kill me» — естественно, менеджер никого не убьёт. Но преувеличение подчёркивает, насколько строго относятся к процедурам.
👉 Получается, это мета-юмор про корпоративные процессы в IT: формальности порой важнее самой работы.
То, что герой каждый раз рукой касается сервера, добавляет ещё один слой юмора:
Буквально — он демонстрирует: «Вот эти самые серверы, с которыми я хочу поработать». Жест подчёркивает объект, о котором идёт речь.
Визуальный акцент — чтобы зритель не потерял контекст: всё время идёт речь именно про «железо», а не про абстрактные тикеты.
Ирония — он показывает, что сервер прямо здесь, под рукой, но при этом он не имеет права его трогать без бумажки. Контраст: физически доступ есть, а формально — нет.
Эффект комичности — повторение жеста делает сцену карикатурной. Сначала это естественно, а потом — всё более нелепо, словно герой доказывает очевидное: «Вот же они! Но я не могу их трогать!»
------------------------------------------------------
Как вам такой анализ от ИИ просто на основании короткого видео и нескольких строк субтитров? И это бесплатная версия. Я просто никогда не работал в крупном IT, поэтому юмора не понял.
#юмор #AI
Смотрю, много просмотров и лайков для нашей темы. Думаю, что-то интересное. Посмотрел раз, два, три. Потом включил перевод, посмотрел ещё пару раз и не понял. В чём тут юмор? Прочитал комментарии и всё равно не понял.
Решил спросить у ChatGPT. Как оказалось, видео с ютуба он смотреть не может. Пришлось скачать и загрузить ему в чат. На что он ответил, что видео видит, а звук не слышит. Загрузил ему субтитры на английском. И он мне всё объяснил.
------------------------------------------------------
◽️Сотрудник просит change request (официальное разрешение на изменения), чтобы поработать с серверами.
◽️Само по себе это звучит абсурдно, ведь change request обычно оформляют для изменения серверов, а не для того, чтобы только начать работать с ними.
◽️Он возмущается: «Что я, инженер первой линии (tier one)?» — намекая, что такие формальности и бюрократия свойственны для самых простых задач.
◽️Финал: «IT-менеджер бы меня убил» — подчеркивает, что без бумажки он вообще не имеет права ничего делать, иначе будут большие проблемы.
Юмор в том, что ролик высмеивает реальность работы системных администраторов: иногда вместо настоящей технической работы больше времени уходит на согласования, бюрократию и правила «чтобы никто не тронул сервер без бумажки».
Давай разберём по слоям, на чём держится шутка в этом видео:
🔹 1. Буквальный уровень
Фраза «i need a change request to work on these servers» звучит нелепо: админ вроде бы просто хочет поработать, но ему нужен специальный документ. Для несведущего зрителя это выглядит как чрезмерная бюрократия.
🔹 2. Ирония
Ирония в том, что админ должен запрашивать разрешение на то, что по его должности и так входит в обязанности. Это как если бы водитель автобуса просил письменное разрешение, чтобы завести двигатель.
🔹 3. Профессиональный юмор
Change request — реальный процесс в ITIL/DevOps, когда любое изменение инфраструктуры фиксируется и согласовывается.
Tier one (1-я линия поддержки) — обычно выполняет простые задачи (перезапуск, проверка логов), а не занимается управлением серверами.
Герой намекает, что бюрократия опускает его уровень работы до "самых простых тикетов".
🔹 4. Гипербола (преувеличение)
«The IT manager would literally kill me» — естественно, менеджер никого не убьёт. Но преувеличение подчёркивает, насколько строго относятся к процедурам.
👉 Получается, это мета-юмор про корпоративные процессы в IT: формальности порой важнее самой работы.
То, что герой каждый раз рукой касается сервера, добавляет ещё один слой юмора:
Буквально — он демонстрирует: «Вот эти самые серверы, с которыми я хочу поработать». Жест подчёркивает объект, о котором идёт речь.
Визуальный акцент — чтобы зритель не потерял контекст: всё время идёт речь именно про «железо», а не про абстрактные тикеты.
Ирония — он показывает, что сервер прямо здесь, под рукой, но при этом он не имеет права его трогать без бумажки. Контраст: физически доступ есть, а формально — нет.
Эффект комичности — повторение жеста делает сцену карикатурной. Сначала это естественно, а потом — всё более нелепо, словно герой доказывает очевидное: «Вот же они! Но я не могу их трогать!»
------------------------------------------------------
Как вам такой анализ от ИИ просто на основании короткого видео и нескольких строк субтитров? И это бесплатная версия. Я просто никогда не работал в крупном IT, поэтому юмора не понял.
#юмор #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍64👎13
Субботняя тема, непосредственно с IT не связанная. Скорее с рабочим местом. Давно планировал купить себе датчик CO2, чтобы проверять воздух в разных комнатах дома и прежде всего у своего рабочего места.
Я в этой теме не разбираюсь и никогда не интересовался ей. Потратил некоторое время, чтобы выбрать какое-то не самое дешёвое, но и не очень дорогое устройство, которое позволило бы хоть и с погрешностями, но оценить качество воздуха. Если хотите сэкономить себе время и не выбирать самостоятельно, можете купить то же самое, что и я.
Задача выбора непростая, так как на каждый прибор есть как куча положительных, так и отрицательных отзывов. Причём последние связаны зачастую с браком или какими-то другими повреждениями, так что для массовых продуктов не так просто по отзывам и обзорам оценить качество.
Я в итоге купил себе анализатор воздуха Qingping Air Monitor 2 (CGS2) (~9000 р.). По моим тестам он работает адекватно и предсказуемо. Корректно отображает CO2 уличного воздуха, предсказуемо показывает повышение при закрытых форточках в комнате, резко повышает значения при дыхании на него.
Я его протестировал в разных помещениях и режимах проветривания. Мои ощущения полностью совпали с показаниями. Спать в спальне с наглухо закрытыми форточками некомфортно, но приоткрытая дверь и микро проветривание в окнах полностью решают эту проблему. Всю ночь ppm не более 1000.
В кабинете при закрытом окне через пол часа ppm уходит за 1200 и становится душновато. Откинутая форточка решает этот вопрос. Я так обычно и работаю.
Ну и в целом в доме всё проверил. У меня нет управляемой централизованной принудительной вентиляции, но приколхожена полуавтоматическая своя, которая делалась по наитию. На удивление, получилось неплохо. Постоянный тёплый пол и проветривание в ванной комнате через откинутую форточку тянут воздух с другого конца дома из кухонной вытяжки, которая в стене и всегда открыта. В итоге в гостинной и по пути следования воздуха всегда свежо. При включении кухонной вытяжки, воздух идёт в обратном направлении, так как она мощная.
А общий воздуховод, проходящий через второй этаж, случайно проходит рядом с радиатором батареи, нагревается и на постоянке уверенно тянет наверх воздух, несмотря на несколько поворотов. Плюс, на втором этаже в санузле принудительно можно включить вытяжку, чтобы ускорить проветривание.
Получается, что ничего особо делать не надо, как только где-то приоткрываешь форточку на зимнее проветривание, через неё начинает понемногу тянуть, чего хватает для проветривания помещения. Распахивать не обязательно. В квартире, к примеру, это так не работает.
Так что с одной стороны устройство удобное, могу рекомендовать. С другой стороны мои ощущения меня не подводили, и без него я всё делал правильно. Повышение СО2 я очень хорошо ощущаю. Всегда и везде приоткрываю окна, если нет принудительной вентиляции. Так что просто приобрёл современную игрушку.
Помимо CO2 в устройстве сменный картридж для анализа мелких и средних частиц пыли, термометр (я сравнил с другими в доме, показывает корректно), измеритель влажности. Проверить его нечем, показывает последние дни 60%, что совпадает плюс-минус с тем, что сейчас должно быть на улице. Отопление пока не включено, так что похоже на правду. Ну и уровень шума, что тоже более-менее корректно, так как видно изменение на датчике при звуках в помещении. Но мне лично это вообще не актуально.
За городом по пыли показания хорошие. Да это и без приборов заметно. Пыли в разы меньше, чем в городской квартире. Нет такого, что неделю не пользовался предметом и он весь запылился. Так что за здоровьем все за город, на удалёнку.
Это не реклама, мне никто не платил и не заказывал её, поэтому ни ссылок, ни магазинов не привожу. Просто поделился полезной в хозяйстве вещью. Я бы советовал в первую очередь проверить воздух в спальне. Мне кажется, это важнее всего. Днём можно ощутить плохой воздух, а вот когда спишь, уже не управляешь этим.
#железо
Я в этой теме не разбираюсь и никогда не интересовался ей. Потратил некоторое время, чтобы выбрать какое-то не самое дешёвое, но и не очень дорогое устройство, которое позволило бы хоть и с погрешностями, но оценить качество воздуха. Если хотите сэкономить себе время и не выбирать самостоятельно, можете купить то же самое, что и я.
Задача выбора непростая, так как на каждый прибор есть как куча положительных, так и отрицательных отзывов. Причём последние связаны зачастую с браком или какими-то другими повреждениями, так что для массовых продуктов не так просто по отзывам и обзорам оценить качество.
Я в итоге купил себе анализатор воздуха Qingping Air Monitor 2 (CGS2) (~9000 р.). По моим тестам он работает адекватно и предсказуемо. Корректно отображает CO2 уличного воздуха, предсказуемо показывает повышение при закрытых форточках в комнате, резко повышает значения при дыхании на него.
Я его протестировал в разных помещениях и режимах проветривания. Мои ощущения полностью совпали с показаниями. Спать в спальне с наглухо закрытыми форточками некомфортно, но приоткрытая дверь и микро проветривание в окнах полностью решают эту проблему. Всю ночь ppm не более 1000.
В кабинете при закрытом окне через пол часа ppm уходит за 1200 и становится душновато. Откинутая форточка решает этот вопрос. Я так обычно и работаю.
Ну и в целом в доме всё проверил. У меня нет управляемой централизованной принудительной вентиляции, но приколхожена полуавтоматическая своя, которая делалась по наитию. На удивление, получилось неплохо. Постоянный тёплый пол и проветривание в ванной комнате через откинутую форточку тянут воздух с другого конца дома из кухонной вытяжки, которая в стене и всегда открыта. В итоге в гостинной и по пути следования воздуха всегда свежо. При включении кухонной вытяжки, воздух идёт в обратном направлении, так как она мощная.
А общий воздуховод, проходящий через второй этаж, случайно проходит рядом с радиатором батареи, нагревается и на постоянке уверенно тянет наверх воздух, несмотря на несколько поворотов. Плюс, на втором этаже в санузле принудительно можно включить вытяжку, чтобы ускорить проветривание.
Получается, что ничего особо делать не надо, как только где-то приоткрываешь форточку на зимнее проветривание, через неё начинает понемногу тянуть, чего хватает для проветривания помещения. Распахивать не обязательно. В квартире, к примеру, это так не работает.
Так что с одной стороны устройство удобное, могу рекомендовать. С другой стороны мои ощущения меня не подводили, и без него я всё делал правильно. Повышение СО2 я очень хорошо ощущаю. Всегда и везде приоткрываю окна, если нет принудительной вентиляции. Так что просто приобрёл современную игрушку.
Помимо CO2 в устройстве сменный картридж для анализа мелких и средних частиц пыли, термометр (я сравнил с другими в доме, показывает корректно), измеритель влажности. Проверить его нечем, показывает последние дни 60%, что совпадает плюс-минус с тем, что сейчас должно быть на улице. Отопление пока не включено, так что похоже на правду. Ну и уровень шума, что тоже более-менее корректно, так как видно изменение на датчике при звуках в помещении. Но мне лично это вообще не актуально.
За городом по пыли показания хорошие. Да это и без приборов заметно. Пыли в разы меньше, чем в городской квартире. Нет такого, что неделю не пользовался предметом и он весь запылился. Так что за здоровьем все за город, на удалёнку.
Это не реклама, мне никто не платил и не заказывал её, поэтому ни ссылок, ни магазинов не привожу. Просто поделился полезной в хозяйстве вещью. Я бы советовал в первую очередь проверить воздух в спальне. Мне кажется, это важнее всего. Днём можно ощутить плохой воздух, а вот когда спишь, уже не управляешь этим.
#железо
1👍128👎9
К заметкам про Restic уже не раз упоминали веб панель к нему Backrest. У меня были большие надежды на эту панель, но они не оправдались. Я почему-то думал, что это будет панель для управления множеством распределённых по хостам экземплярам Restic. Он работает по модели push, то есть сам отправляет данные в репозиторий и поэтому должен быть установлен локально.
С такой архитектурой затруднено централизованное управление. Это должна быть какая-то сторонняя система для установки самого restic, раскатки конфигураций на него и отслеживания выполнений заданий бэкапа. Для этого, к примеру, подойдёт Ansible Semaphore.
Я рассчитывал увидеть подобную панель, но с акцентом именно на возможности restic. Но увы. Backrest не про это. С её помощью можно настраивать только локальный бэкап на конкретном одиночном хосте. Для меня вообще неактуальна подобная функциональность, потому что я предпочитаю такие вещи настраивать в консоли на скриптах.
Тем не менее, я развернул Backrest и попробовал. Она вполне удобна для тех, кому нужен веб интерфейс для настройки. Одним из явных удобств этой панели будет возможность просматривать и скачивать файлы из снепшотов в репозиотрии. Да и просто просмотр выполненных заданий и содержимое репозитория в браузере выглядит наглядно и удобно.
Запустить Backrest можно как локально, установив вручную из бинарника и создав службу, так и автоматически в Doсker Compose. Я выбрал второе. Немного доработал пример из репозитория. Получилось вот так:
Обращаю внимание на подключаемую директорию
◽️id_ed25519 - приватный ключ для доступа к серверу, делаем так:
id_ed25519.pub добавляем на удалённом сервере в
◽️known_hosts - файл с открытым ключом удалённого сервера. Подключитесь к нему с какого-нибудь сервера, а потом скопируйте сохранённую строку из
После запуска контейнера можно идти на порт 9898 и настраивать бэкап через браузер. Первым делом надо добавить Repo. Для SFTP строка Repository URI будет примерно такая:
После этого можно создавать задание для бэкапа. Я в своём примере бэкаплю директорию
Примеры настроек Repo и задания для бэкапа показал внизу на картинках.
Теперь можно либо вручную сделать бэкап здесь же, либо дождаться планировщика. Перейдя в репозиторий, можно посмотреть Snapshots уже сделанных бэкапов, увидеть список файлов в них и по желанию что-то восстановить. Для восстановления удобно использовать директорию tmp, которую добавили в compose.
В целом нормальная, удобная панель, если для вас актуальна такая функциональность. Будет хорошим решением локальных бэкапов для тех, у кого рабочая машина на Linux. Для бэкапа и восстановления файлов с серверов, я думаю, можно обойтись и без веб интерфейса.
⇨ 🌐 Сайт / Исходники
#backup #restic
С такой архитектурой затруднено централизованное управление. Это должна быть какая-то сторонняя система для установки самого restic, раскатки конфигураций на него и отслеживания выполнений заданий бэкапа. Для этого, к примеру, подойдёт Ansible Semaphore.
Я рассчитывал увидеть подобную панель, но с акцентом именно на возможности restic. Но увы. Backrest не про это. С её помощью можно настраивать только локальный бэкап на конкретном одиночном хосте. Для меня вообще неактуальна подобная функциональность, потому что я предпочитаю такие вещи настраивать в консоли на скриптах.
Тем не менее, я развернул Backrest и попробовал. Она вполне удобна для тех, кому нужен веб интерфейс для настройки. Одним из явных удобств этой панели будет возможность просматривать и скачивать файлы из снепшотов в репозиотрии. Да и просто просмотр выполненных заданий и содержимое репозитория в браузере выглядит наглядно и удобно.
Запустить Backrest можно как локально, установив вручную из бинарника и создав службу, так и автоматически в Doсker Compose. Я выбрал второе. Немного доработал пример из репозитория. Получилось вот так:
services:
backrest:
image: garethgeorge/backrest:latest
container_name: backrest
hostname: backrest
volumes:
- ./backrest/data:/data
- ./backrest/config:/config
- ./backrest/cache:/cache
- ./backrest/tmp:/tmp # для восстановления бэкапов
- ./.ssh:/root/.ssh # для доступа к repo по sftp
- /path/to/local/repos:/userdata # локальная директория, которая бэкапится
- /path/to/local/repos:/repos # для использования в качестве local repo
environment:
- BACKREST_DATA=/data
- BACKREST_CONFIG=/config/config.json
- XDG_CACHE_HOME=/cache
- TMPDIR=/tmp
- TZ=Europe/Moscow
ports:
- "9898:9898"
restart: unless-stopped
Обращаю внимание на подключаемую директорию
.ssh. Она нужна для подключения репозитория по SFTP. По мне, так это самый простой и удобный способ подключиться к удалённому хосту для хранения бэкапов на нём. В этой директории должны быть 2 файла: ◽️id_ed25519 - приватный ключ для доступа к серверу, делаем так:
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"id_ed25519.pub добавляем на удалённом сервере в
authorized_keys.◽️known_hosts - файл с открытым ключом удалённого сервера. Подключитесь к нему с какого-нибудь сервера, а потом скопируйте сохранённую строку из
known_hosts в этот файл. После запуска контейнера можно идти на порт 9898 и настраивать бэкап через браузер. Первым делом надо добавить Repo. Для SFTP строка Repository URI будет примерно такая:
sftp:user@10.20.1.24:/mnt/backup. Остальные параметры указывайте по потребностям.После этого можно создавать задание для бэкапа. Я в своём примере бэкаплю директорию
/var/log, которую примапил в композ файле к /userdata.Примеры настроек Repo и задания для бэкапа показал внизу на картинках.
Теперь можно либо вручную сделать бэкап здесь же, либо дождаться планировщика. Перейдя в репозиторий, можно посмотреть Snapshots уже сделанных бэкапов, увидеть список файлов в них и по желанию что-то восстановить. Для восстановления удобно использовать директорию tmp, которую добавили в compose.
В целом нормальная, удобная панель, если для вас актуальна такая функциональность. Будет хорошим решением локальных бэкапов для тех, у кого рабочая машина на Linux. Для бэкапа и восстановления файлов с серверов, я думаю, можно обойтись и без веб интерфейса.
⇨ 🌐 Сайт / Исходники
#backup #restic
👍50👎5