Недавно поднимал тему переезда домена от одного регистратора к другому. Косвенно захватил тему переноса DNS записей. У меня уже ранее была один раз ситуация, когда я по какой-то причине потерял DNS записи, которые пришлось восстанавливать. Уже не помню подробностей истории. Ещё тогда я подумал, что неплохо бы было их забэкапить в любом виде, просто чтобы было.
В то время вопрос не проработал и ничего не сделал. Это не такая уж критическая информация, если у вас не десятки поддоменов и каких-то специфических сервисов со своими TXT записями. Можно всё восстановить вручную, но придётся вспоминать и открывать разные источники. На это уйдёт время. Проще будет, если хоть в каком-то виде вся эта информация будет храниться с обновлением хотя бы раз в месяц.
Решил посмотреть, есть ли какие готовые решения на этот счёт. Вот что нашёл.
◽️octoDNS - утилита, которая хранит настройки DNS записей в формате yaml и имеет интеграцию с публичными провайдерами или локальными DNS серверами. Поддерживает многих популярных западный провайдеров, типа Amazon Route 53, Azure DNS, Cloudflare DNS и т.д. и ни одного российского. По факту это не только бэкап конфигурации, но и управление. То есть типичный подход инфраструктуры как код с хранением DNS зон в GIT. С помощью octoDNS записи можно переносить от одного провайдера к другому.
◽️DNSControl - примерно то же самое, что и octoDNS, но зоны хранятся в формате языка программирования JavaScript. Не кажется это удобным. Не знаю, почему так сделано. По возможностям и интеграциям не увидел принципиальной разницы с octoDNS.
Для российских хостеров эти утилиты не подходят. Надо либо модуль интеграции самим писать, либо использовать что-то другое. Можно пойти более простым путём.
◽️Бэкап записей через API. Почти у всех крупных провайдеров есть API для управления зонами. ИИ без проблем напишет интеграцию. Достаточно скормить ему документацию и сказать, что тебе нужно. Я проверил на примере Selectel.
Но тут возникает другой вопрос. Для доступа к зонам нужен токен. Если зоны на разных учётках или у разных хостеров, то муторно настраивать везде доступы. Если задача не добавлять или менять записи, а только смотреть, доступ через API не особо нужен. Это публичные данные, которые можно прочитать напрямую.
◽️Бэкап записей через dig. Можно взять любую утилиту для просмотра DNS записей и сохранить её вывод. В Linux для этого обычно используют dig. Смотреть можно так:
Достаточно сохранить вывод для всех зон, вот тебе и бэкап. По типам записей и доменам можно пройтись в цикле:
Получается аккуратный список DNS записей доменов. У этого способа есть один существенный минус - все поддомены надо добавлять вручную. Нет возможности получить точный публичный список поддоменов. Его придётся вести вручную. Напрямую все поддомены забрать можно только у DNS хостера через его API. Так что выбирайте сами, какой способ вам больше подойдёт.
Я остановился на подобном скрипте. Мне его хватает. Буду запускать раз в неделю на бэкап сервере с консолью Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#dns #backup
В то время вопрос не проработал и ничего не сделал. Это не такая уж критическая информация, если у вас не десятки поддоменов и каких-то специфических сервисов со своими TXT записями. Можно всё восстановить вручную, но придётся вспоминать и открывать разные источники. На это уйдёт время. Проще будет, если хоть в каком-то виде вся эта информация будет храниться с обновлением хотя бы раз в месяц.
Решил посмотреть, есть ли какие готовые решения на этот счёт. Вот что нашёл.
◽️octoDNS - утилита, которая хранит настройки DNS записей в формате yaml и имеет интеграцию с публичными провайдерами или локальными DNS серверами. Поддерживает многих популярных западный провайдеров, типа Amazon Route 53, Azure DNS, Cloudflare DNS и т.д. и ни одного российского. По факту это не только бэкап конфигурации, но и управление. То есть типичный подход инфраструктуры как код с хранением DNS зон в GIT. С помощью octoDNS записи можно переносить от одного провайдера к другому.
◽️DNSControl - примерно то же самое, что и octoDNS, но зоны хранятся в формате языка программирования JavaScript. Не кажется это удобным. Не знаю, почему так сделано. По возможностям и интеграциям не увидел принципиальной разницы с octoDNS.
Для российских хостеров эти утилиты не подходят. Надо либо модуль интеграции самим писать, либо использовать что-то другое. Можно пойти более простым путём.
◽️Бэкап записей через API. Почти у всех крупных провайдеров есть API для управления зонами. ИИ без проблем напишет интеграцию. Достаточно скормить ему документацию и сказать, что тебе нужно. Я проверил на примере Selectel.
Но тут возникает другой вопрос. Для доступа к зонам нужен токен. Если зоны на разных учётках или у разных хостеров, то муторно настраивать везде доступы. Если задача не добавлять или менять записи, а только смотреть, доступ через API не особо нужен. Это публичные данные, которые можно прочитать напрямую.
◽️Бэкап записей через dig. Можно взять любую утилиту для просмотра DNS записей и сохранить её вывод. В Linux для этого обычно используют dig. Смотреть можно так:
# dig ya.ru A +noall +answer# dig ya.ru MX +noall +answer# dig ya.ru TXT +noall +answerДостаточно сохранить вывод для всех зон, вот тебе и бэкап. По типам записей и доменам можно пройтись в цикле:
#!/usr/bin/env bash
DOMAINS_LIST="domains.txt"
BACKUP_DIR="./dns_backups"
mkdir -p "$BACKUP_DIR"
DATE=$(date +%F_%H%M%S)
for DOMAIN in $(cat "$DOMAINS_LIST"); do
OUTFILE="${BACKUP_DIR}/${DOMAIN}_${DATE}.zone"
echo "### $DOMAIN ###" > "$OUTFILE"
for TYPE in NS A AAAA CNAME MX TXT SRV; do
echo "" >> "$OUTFILE"
echo "### $TYPE ###" >> "$OUTFILE"
dig "$DOMAIN" "$TYPE" +noall +answer >> "$OUTFILE"
done
echo "saved: $OUTFILE"
done
Получается аккуратный список DNS записей доменов. У этого способа есть один существенный минус - все поддомены надо добавлять вручную. Нет возможности получить точный публичный список поддоменов. Его придётся вести вручную. Напрямую все поддомены забрать можно только у DNS хостера через его API. Так что выбирайте сами, какой способ вам больше подойдёт.
Я остановился на подобном скрипте. Мне его хватает. Буду запускать раз в неделю на бэкап сервере с консолью Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#dns #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍92👎4
Недавно по лентам каналов проскочил анонс бесплатной программы для бэкапа и переноса почты из почтовых ящиков - Mail-Archiver. Тема интересная и актуальная, потому что такого рода программ практически нет. Я обычно новый софт смотрю, прикидываю, будет ли он мне полезен и откладываю на полгода-год, чтобы настоялся. Если получает развитие, то пробую, если разработка не продолжается, то забываю.
Про Mail-Archiver впервые услышал в видеообзоре, который был в недавней подборке. Когда мне нужно забэкапить или перенести почтовый ящик с почтового сервера, который я не обслуживаю, и, соответственно, не имею напрямую доступ к исходникам писем, то беру imapsync. Это простой и надёжный инструмент, который позволяет по imap забирать почту с одного почтового сервера и складывать на другой. Для бэкапа достаточно поднять свой вспомогательный imap сервер, который примет почту. В своё время делал большие миграции с бесплатной почты для домена от Яндекс на другие сервера, когда первый убрал бесплатные тарифы.
Возвращаюсь к Mail-Archiver. Это веб интерфейс к сборщику почты из ящиков по протоколу imap. Я его попробовал. Поставить очень просто. В репозитории есть готовый
Внешне веб интерфейс собран на базе какого-то типового фреймворка для админок. Выглядит для своих задач нормально. Настойка максимально простая:
1️⃣ Добавляете новый почтовый ящик, указав имя сервера, логин, пароль, imap порт.
2️⃣ Запускаете вручную синхронизацию.
3️⃣ Смотрите почту через веб интерфейс панели. Можете сразу по всем добавленным ящикам в едином списке. В некоторых случаях это может оказаться полезным. Либо же выбираете отдельно ящики или конкретные папки в них.
4️⃣ При желании архив можно выгрузить в формате EML или MBox, предварительно сжав в ZIP. С большими ящиками скорее всего будут проблемы.
5️⃣ Все письма из одного ящика можно скопировать в другой. В том числе в отдельную папку. То есть можно на каком-то почтовом сервере для бэкапов сделать общий ящик и складывать туда в каждую папку письма какого-то отдельного ящика.
В целом панелька удобная. Я без проблем всё настроил. Но есть несколько важных нюансов:
1️⃣ Синхронизация писем идёт медленно. В среднем из ящика забирает 1-2 письма в секунду. Большие ящики будут очень долго синхронизироваться.
2️⃣ Вся почта хранится в SQL базе, конкретно в PostgreSQL. В целом это неплохо с точки зрения быстрого поиска по большому архиву. Но накладывает соответствующие требования к процессору и дискам, чтобы переваривать большие объёмы почты. Вообще не понятно, как эта панель будет работать, если туда загрузить несколько ящиков гигабайт по 50. У меня, к примеру, в обслуживании, таких полно.
3️⃣ Нет настраиваемых задач для регулярного бэкапа. Он запускается только вручную или по какому-то своему расписанию раз в 15 минут. Я вроде всё проверил, и панель, и документацию. Не нашёл, как этим управлять. Странно, что не сделали настраиваемый планировщик. Он тут напрашивается.
Mail-Archiver неплохо решает заданную задачу. Для личного использования или набора ящиков небольших объёмов будет удобен. Для больших почтовых ящиков и серверов, скорее всего не подойдёт. Но там странно было бы надеяться на бэкап через imap. Большие ящики надо бэкапить с уровня хранилища почты.
Отдельно отмечу возможность создавать учётные записи пользователей самой панели, к которым можно добавлять разные почтовые ящики с общим поиском по ним. Для каких-то задач это может быть простым и удобным решением.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #backup
Про Mail-Archiver впервые услышал в видеообзоре, который был в недавней подборке. Когда мне нужно забэкапить или перенести почтовый ящик с почтового сервера, который я не обслуживаю, и, соответственно, не имею напрямую доступ к исходникам писем, то беру imapsync. Это простой и надёжный инструмент, который позволяет по imap забирать почту с одного почтового сервера и складывать на другой. Для бэкапа достаточно поднять свой вспомогательный imap сервер, который примет почту. В своё время делал большие миграции с бесплатной почты для домена от Яндекс на другие сервера, когда первый убрал бесплатные тарифы.
Возвращаюсь к Mail-Archiver. Это веб интерфейс к сборщику почты из ящиков по протоколу imap. Я его попробовал. Поставить очень просто. В репозитории есть готовый
docker-compose.yml. Если не хотите менять стандартные учётки, то можно вообще ничего не менять в файле. Я только свой часовой пояс указал.Внешне веб интерфейс собран на базе какого-то типового фреймворка для админок. Выглядит для своих задач нормально. Настойка максимально простая:
В целом панелька удобная. Я без проблем всё настроил. Но есть несколько важных нюансов:
Mail-Archiver неплохо решает заданную задачу. Для личного использования или набора ящиков небольших объёмов будет удобен. Для больших почтовых ящиков и серверов, скорее всего не подойдёт. Но там странно было бы надеяться на бэкап через imap. Большие ящики надо бэкапить с уровня хранилища почты.
Отдельно отмечу возможность создавать учётные записи пользователей самой панели, к которым можно добавлять разные почтовые ящики с общим поиском по ним. Для каких-то задач это может быть простым и удобным решением.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍95👎2
Расскажу про одну интересную утилиту, которая поможет в строительстве своих велосипедов и костылей как на одиночных серверах, так и в пайплайнах. Речь пойдёт про сервер для вебхуков, который так и называется - webhook. С его помощью можно инициировать запуск локальных команд или скриптов через HTTP запросы.
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
Пишем простенький скрипт
Пишем конфиг в формате yaml для webhook в файл
Запускаем сервер с этим вебхуком:
По умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#cicd #devops
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
# apt install webhookПишем простенький скрипт
top-proc.sh, который будет записывать в текстовый файл отсортированный по нагрузке список процессов в системе:#!/usr/bin/env bash/usr/bin/mkdir -p /var/log/proclog/usr/bin/ps aux --sort=-pcpu,+pmem > /var/log/proclog/ps-$(date +%F_%H%M%S)Пишем конфиг в формате yaml для webhook в файл
hooks.json:- id: proclog-webhook execute-command: "/var/webhooks/top-proc.sh" command-working-directory: "/var/webhooks/"Запускаем сервер с этим вебхуком:
# /usr/bin/webhook -hooks /var/webhooks/hooks.json -verboseПо умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
/var/webhooks/top-proc.sh, который создаёт логи в директории /var/log/proclog. Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#cicd #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍122👎3
🔝С праздниками закрутился и упустил, что октябрь кончился, а я забыл собрать популярные публикации прошедшего месяца. Хоть и с опозданием, но исправляю. Это хоть и не очень популярный формат, но я веду его для каталогизации и структурирования информации, чтобы новым читателям было проще посмотреть, что интересного тут было ранее. С этим в Telegram туго. Мне потом по этим отчётам годовую статистику проще формировать.
Все самые популярные публикации по месяцам можно почитать по соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://xn--r1a.website/boost/srv_admin.
📌 Больше всего пересылок:
◽️Настройка basic_auth с исключениями в Nginx/Angie (466)
◽️Платформы для построения тестовых инфраструктур (404)
◽️Xenoeye для анализа сетевой активности (402)
◽️Сервисы для централизованного сбора логов (366)
📌 Больше всего комментариев:
◽️Обзор клиентов для удалённых подключений (234)
◽️Глюки RouterOS 7 в Mikrotik (232)
◽️Настройка basic_auth с исключениями в Nginx/Angie (200)
📌 Больше всего реакций:
◽️Подборка авторских сайтов IT тематики (233)
◽️Настройка basic_auth с исключениями в Nginx/Angie (228)
◽️Обучающий канал Alek OS (204)
◽️Swap в виде файла (198)
📌 Больше всего просмотров:
◽️Система Sentry - ужас для поддержки (11000)
◽️Пасхалка с коровой в apt-get (10400)
◽️Платформы для построения тестовых инфраструктур (10200)
◽️Сервис для проверки репутации IP (10000)
#топ
Все самые популярные публикации по месяцам можно почитать по соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://xn--r1a.website/boost/srv_admin.
📌 Больше всего пересылок:
◽️Настройка basic_auth с исключениями в Nginx/Angie (466)
◽️Платформы для построения тестовых инфраструктур (404)
◽️Xenoeye для анализа сетевой активности (402)
◽️Сервисы для централизованного сбора логов (366)
📌 Больше всего комментариев:
◽️Обзор клиентов для удалённых подключений (234)
◽️Глюки RouterOS 7 в Mikrotik (232)
◽️Настройка basic_auth с исключениями в Nginx/Angie (200)
📌 Больше всего реакций:
◽️Подборка авторских сайтов IT тематики (233)
◽️Настройка basic_auth с исключениями в Nginx/Angie (228)
◽️Обучающий канал Alek OS (204)
◽️Swap в виде файла (198)
📌 Больше всего просмотров:
◽️Система Sentry - ужас для поддержки (11000)
◽️Пасхалка с коровой в apt-get (10400)
◽️Платформы для построения тестовых инфраструктур (10200)
◽️Сервис для проверки репутации IP (10000)
#топ
Telegram
ServerAdmin.ru
🎄🔝 Под конец года имеет смысл подвести некоторые итоги. В повседневной жизни я не привык это делать. Обычно только доходы/расходы анализирую. А вот в разрезе канала было интересно посмотреть итоги.
Я подготовил ТОП публикаций за прошедший год. Это было…
Я подготовил ТОП публикаций за прошедший год. Это было…
👍52👎3
Вчера в статье про обновление Debian 12 до Debian 13 Trixie появился полезный комментарий. Автор указал, что в результате обновления удаляется файл
В Debian 13 вообще по умолчанию убрали
Существует устоявшаяся практика по изменению стандартных конфигурационных файлов. Обычно для внесения своих правок используется специальная директория с названием сервиса и
Если вы хотите внести изменения в sysctl, то просто добавьте отдельный файл в
Например, если хотите добавить форвард пакетов между сетевыми интерфейсами, создайте отдельный файл
После этого примените настройку:
Я всё это, конечно же, знаю, но иногда сознательно так не делаю для своего удобства. Мне нравится, когда вся конфигурация в одном файле. Кому-то это кажется наоборот неудобным. Это моё личное предпочтение, за которое я часто получал критику, если делал все изменения в стандартном конфигурационном файле.
Например, я предпочитаю, когда конфигурация Postfix или Dovecot в одном общем файле, а не раскиданная по нескольким. А в Nginx или Logstash по разным. Там есть логическое разделение по смыслам. В случае Nginx всё очевидно - разные виртуальны хосты, разные файлы конфигураций. В Logstash тоже разные процедуры с данными в разных файлах.
В общем случае вносить изменения стоит в корректирующие файлы конфигурации, а не основные. А как вам удобнее, решайте сами. Просто знайте, что иногда ваш файл может быть перезаписан. Изменения обычно не теряются, так как старый файл сохраняется рядом с другим расширением. Ещё популярные примеры из этой области:
◽️
◽️
◽️
◽️
◽️
◽️
Ну и так далее. Это типичная картина для файлов конфигураций служб в Linux. Скорее будет исключение, если служба будет использовать другой подход к организации конфигурационных файлов.
А вы как предпочитаете хранить конфигурации? Как правильно или как удобно?
#linux
/etc/sysctl.conf, а старый переименовывается на /etc/sysctl.conf.dpkg-bak. Соответственно, все внесённые настройки не применяются. Этого стоит ожидать и понимать, что такое может произойти, хотя на моей памяти ни разу такого не видел с sysctl.conf, потому что я обычно вношу изменения именно в него. В Debian 13 вообще по умолчанию убрали
/etc/sysctl.conf, так как за эти настройки отвечает служба systemd-sysctl, которая хранит свои настройки в /usr/lib/sysctl.d/.Существует устоявшаяся практика по изменению стандартных конфигурационных файлов. Обычно для внесения своих правок используется специальная директория с названием сервиса и
.d на конце. Для примера с sysctl это всегда была директория /etc/sysctl.d, а сейчас /usr/lib/sysctl.d/. Хотя старая вроде бы тоже подгружается в момент загрузки системы.Если вы хотите внести изменения в sysctl, то просто добавьте отдельный файл в
/etc/sysctl.d и внесите свои правки туда. Имя файла при этом чаще всего может быть любым, главное следить за расширением .conf. Обычно на это проверка стоит и к основной конфигурации подключаются только файлы определённого расширения.Например, если хотите добавить форвард пакетов между сетевыми интерфейсами, создайте отдельный файл
/etc/sysctl.d/forward.conf и добавьте туда:net.ipv4.ip_forward = 1После этого примените настройку:
# sysctl -p /etc/sysctl.d/forward.confnet.ipv4.ip_forward = 1Я всё это, конечно же, знаю, но иногда сознательно так не делаю для своего удобства. Мне нравится, когда вся конфигурация в одном файле. Кому-то это кажется наоборот неудобным. Это моё личное предпочтение, за которое я часто получал критику, если делал все изменения в стандартном конфигурационном файле.
Например, я предпочитаю, когда конфигурация Postfix или Dovecot в одном общем файле, а не раскиданная по нескольким. А в Nginx или Logstash по разным. Там есть логическое разделение по смыслам. В случае Nginx всё очевидно - разные виртуальны хосты, разные файлы конфигураций. В Logstash тоже разные процедуры с данными в разных файлах.
В общем случае вносить изменения стоит в корректирующие файлы конфигурации, а не основные. А как вам удобнее, решайте сами. Просто знайте, что иногда ваш файл может быть перезаписан. Изменения обычно не теряются, так как старый файл сохраняется рядом с другим расширением. Ещё популярные примеры из этой области:
◽️
/etc/zabbix/zabbix_agentd.d◽️
/etc/fail2ban/fail2ban.d◽️
/etc/dovecot/conf.d◽️
/etc/sudoers.d◽️
/etc/mysql/mariadb.conf.d◽️
/etc/logstash/conf.dНу и так далее. Это типичная картина для файлов конфигураций служб в Linux. Скорее будет исключение, если служба будет использовать другой подход к организации конфигурационных файлов.
А вы как предпочитаете хранить конфигурации? Как правильно или как удобно?
#linux
👍109👎2
⇨ Динамические группы проксируемых серверов в Angie
Примеры динамической балансировки нагрузки на бэкенды с помощью Angie. Используется метод c помощью DNS записей типа SRV и меток Docker контейнеров, как в Traefik.
⇨ Клиентское кэширование в Angie
Практический пример настройки кэша статических элементов сайта с помощью настройки соответствующих заголовков.
⇨ Terraform - EPHEMERAL - ОЧЕНЬ НУЖНАЯ ВЕЩЬ!
Обзор одной из возможностей современного Terraform, с помощью которой можно управлять чувствительными данными, например, созданными паролями, исключая их сохранение в файле состояния .tfstate.
⇨ Шифрование в протоколе TLS | Компьютерные сети 2025 - 40
Очередной урок обновлённого популярного курса по сетям. Если кто ещё не знаком с ним и интересуется темой, рекомендую. Хорошее качество материала, подача.
⇨ Zabbix 8.0: Новая глава в мониторинге. Автор: Алексей Владышев / Zabbix Summit 2025
Выступление основателя Zabbix на тему нововведений 8-й версии. Ближе к релизу я более детально всё это изучу и напишу, а пока это для тех, кому любопытна данная тема. Самое интересное - анонсировано мобильное приложение 🔥.
⇨ Traefik в Proxmox LXC | Reverse Proxy + Автоматический SSL (Let's Encrypt) Part 1 и Part 2
Подборные ролики на тему настройки обратного прокси на базе Traefik. Настройка включает в себя приобретение доменного имени и далее настройка Traefik, статическая, динамическая, TLS и всякие нюансы, подробно и наглядно.
⇨ 7 действительно полезных вещей для дома на 3D-принтере
Ролик из другой тематики, которой я интересуюсь - стройка. Но тут тема немного пересекается с IT, так как 3D принтеры пока удел отдельных любителей, чаще всего связанных с IT. Хоть ролик и рекламный, но не вижу ничего зазорного в нём, так как подробно всё рассказано и показано. Я у этого автора увидел Ergostol и купил себе аж три разной ширины от 2 до 2,2 м. Очень удобные столы, рекомендую.
⇨ Лучшие самостоятельные инструменты искусственного интеллекта, которые вы можете запустить у себя
Обзор бесплатных программ, связанных с ИИ. Какие-то я уже знал (Ollama, OpenWebUi, n8n), а про некоторые услышал впервые.
⇨ Block stupid Ads and manage DNS // Pi-hole Tutorial
Подробный обзор бесплатного инструмента для блокировки рекламы и трекеров с помощью блокировки соответствующих DNS запросов. Я сам не раз разворачивал Pi-Hole и каждый раз отказывался от него. Мне не нравится подход блокировки DNS, потому что он негибкий. Предпочитаю управлять этим через расширения в браузерах.
⇨ Бесплатная панель мониторинга Proxmox, которую вы ждали
Очередной обзор неплохой бесплатной панели для мониторинга и управления Proxmox VE - Pulse. Я писал про неё и использую у себя.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Динамические группы проксируемых серверов в Angie
При работе с балансировкой нагрузки изменение состава серверов можно выполнять через редактирование конфига. Но в Angie есть и более гибкие варианты, которые используют DNS или даже метки docker для управления апстримами.
Этот канал посвящён теме поддержки…
Этот канал посвящён теме поддержки…
1👍56👎2
Недавно вышло очередное обновление INFRAX. Я ранее писал про неё заметку и делал статью на сайте. Это система управления ИТ-инфраструктурой, которая объединяет в себе систему мониторинга, удалённого подключения к серверам и техподдержку с тикетами.
В новом обновлении появилась возможность управлять системами виртуализации Hyper‑V, Proxmox VE, VMware vSphere и контейнерами Docker. Причём сделано всё максимально удобно и унифицированно в рамках единой системы с её правами доступа, логированием действий, записью сессий.
Если ранее уже настраивали доступ к серверам и устанавливали агенты мониторинга, то настраивать отдельно ничего не нужно. Агент сам найдёт гипервизоры и отобразит их в панели управления. Вы сможете управлять виртуальными машинами, изменять их параметры, подключаться к консоли, делать снепшоты и выполнять некоторые другие действия.
Всё подробно, в картинках описал в статье на сайте:
⇨ Управление виртуализацией Hyper‑V, Proxmox VE, VMware vSphere и Docker в INFRAX
Отдельно отмечу, что цикл статей про INFRAX у меня заказан разработчиками. Скорее всего будут материалы по другим возможностям. Все статьи пишу сам, у меня их никто не редактирует. Систему я внедрил на одном небольшом филиале, где она успешно трудится, обновляется, я пробую все нововведения.
Из последних обновлений, помимо добавления виртуализации, появились некоторые полезные исправления и дополнения:
▪️Появилась возможность приобрести бессрочную лицензию на заданное количество хостов, без необходимости её каким-то образом регулярно продлевать и обновлять. Напомню, что бесплатная лицензия community версии на 100 хостов и пользователей тоже бессрочная и вечная. Продлевать её не нужно.
▪️Подключение к узлам через браузер по RDP стало чётко позиционировать мышь. Раньше иногда она немного мимо кликала. Был рассинхрон между локальной и удалённой мышкой. Плюс автомасштабирование экрана плохо работало при изменении размера окна браузера. Тоже починили.
▪️Можно менять стандартный порт службы для удалённых подключений. До этого были жёстко прибиты порты 3389 или 22. Теперь можно настраивать и добавлять несколько разных типов подключения. Например, для Proxmox это будет и SSH и HTTP. Раньше можно было настроить что-то одно.
Было ещё много мелких исправлений ошибок и недоработок. Думаю те, кто ставили после первой моей статьи, заметили это. Продукт активно развивается, дорабатываются, ошибки исправляются. Есть ещё, которые лично я наблюдаю. Например, в Топ-10 по IOPS диска вижу разделы
Система в целом приятная и простая в настройке. Управление виртуализацией расширило её возможности. Если рассматривать функциональность отдельных инструментов для управления, типа родного интерфейса Proxmox или оснастки Hyper-V, или Portainer для Docker, то конечно в них работать удобнее.
На другой чаше весов единая система, объединяющая в себе разнородные сервисы и функциональность с общим контролем доступа и логированием, записью всех действий. Мне кажется, это однозначное и решающее преимущество, которое позволяет построить целостную систему управления с разграничением доступа. Особенно это актуально для услуг аутсорсинга. INFRAX тут способен закрыть очень широкий пласт задач.
Например, вы можете прописать регламент обновления какой-то системы с обязательным созданием снепшота виртуальной машины перед обновлением и удалением после. С помощью INFRAX вы можете как проследить за созданием и удалением снепшота, так и посмотреть действия специалиста в консоли. Что он там непосредственно делал, сколько времени у него это заняло.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#мониторинг #remote #infrax #отечественное
В новом обновлении появилась возможность управлять системами виртуализации Hyper‑V, Proxmox VE, VMware vSphere и контейнерами Docker. Причём сделано всё максимально удобно и унифицированно в рамках единой системы с её правами доступа, логированием действий, записью сессий.
Если ранее уже настраивали доступ к серверам и устанавливали агенты мониторинга, то настраивать отдельно ничего не нужно. Агент сам найдёт гипервизоры и отобразит их в панели управления. Вы сможете управлять виртуальными машинами, изменять их параметры, подключаться к консоли, делать снепшоты и выполнять некоторые другие действия.
Всё подробно, в картинках описал в статье на сайте:
⇨ Управление виртуализацией Hyper‑V, Proxmox VE, VMware vSphere и Docker в INFRAX
Отдельно отмечу, что цикл статей про INFRAX у меня заказан разработчиками. Скорее всего будут материалы по другим возможностям. Все статьи пишу сам, у меня их никто не редактирует. Систему я внедрил на одном небольшом филиале, где она успешно трудится, обновляется, я пробую все нововведения.
Из последних обновлений, помимо добавления виртуализации, появились некоторые полезные исправления и дополнения:
▪️Появилась возможность приобрести бессрочную лицензию на заданное количество хостов, без необходимости её каким-то образом регулярно продлевать и обновлять. Напомню, что бесплатная лицензия community версии на 100 хостов и пользователей тоже бессрочная и вечная. Продлевать её не нужно.
▪️Подключение к узлам через браузер по RDP стало чётко позиционировать мышь. Раньше иногда она немного мимо кликала. Был рассинхрон между локальной и удалённой мышкой. Плюс автомасштабирование экрана плохо работало при изменении размера окна браузера. Тоже починили.
▪️Можно менять стандартный порт службы для удалённых подключений. До этого были жёстко прибиты порты 3389 или 22. Теперь можно настраивать и добавлять несколько разных типов подключения. Например, для Proxmox это будет и SSH и HTTP. Раньше можно было настроить что-то одно.
Было ещё много мелких исправлений ошибок и недоработок. Думаю те, кто ставили после первой моей статьи, заметили это. Продукт активно развивается, дорабатываются, ошибки исправляются. Есть ещё, которые лично я наблюдаю. Например, в Топ-10 по IOPS диска вижу разделы
/boot. Явно проблема с идентификацией и очерёдностью дисков. Реально нагружены другие разделы.Система в целом приятная и простая в настройке. Управление виртуализацией расширило её возможности. Если рассматривать функциональность отдельных инструментов для управления, типа родного интерфейса Proxmox или оснастки Hyper-V, или Portainer для Docker, то конечно в них работать удобнее.
На другой чаше весов единая система, объединяющая в себе разнородные сервисы и функциональность с общим контролем доступа и логированием, записью всех действий. Мне кажется, это однозначное и решающее преимущество, которое позволяет построить целостную систему управления с разграничением доступа. Особенно это актуально для услуг аутсорсинга. INFRAX тут способен закрыть очень широкий пласт задач.
Например, вы можете прописать регламент обновления какой-то системы с обязательным созданием снепшота виртуальной машины перед обновлением и удалением после. С помощью INFRAX вы можете как проследить за созданием и удалением снепшота, так и посмотреть действия специалиста в консоли. Что он там непосредственно делал, сколько времени у него это заняло.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#мониторинг #remote #infrax #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍118👎3
Заметил, как на одном небольшом веб сервере постоянно занят весь swap, хотя использование оперативной памяти там сбалансировано и явного недостатка не возникает. Решил повнимательнее посмотреть, что там происходит и почему складывается такая ситуация. Интуитивно кажется, что swap не должен использоваться, тем более на весь объём, если оперативной памяти достаточно, но это не совсем так.
В данном случае речь пойдёт про типовой веб сервер всё в одном: MariaDB + Angie + PHP-fpm и некоторые сопутствующие сервисы для обеспечения безопасности, мониторинга и сбора логов.
Первым делом смотрю, кто занимает swap. В заметке по ссылке всё описано, не буду подробно останавливаться на этом. Кратко можно посмотреть прямо в консоли:
Первая строка - главный потребитель swap. В моём случае процесс mariadbd. Смотрим состояние памяти:
В системе 4GB оперативной памяти и 1GB swap. При этом доступно более 1GB оперативной памяти. По логике хотя бы её часть ещё могла бы использоваться вместо свопа.
За то, как активно система использует swap, отвечает параметр ядра vm.swappiness. Смотрим текущее значение:
По умолчанию разработчики Linux его ставят в значении 60. Оно обеспечивает баланс между swap и page cache. Напомню, для тех, кто не знает или забыл, что свободная оперативная память в Linux не простаивает, а используется под статический кэш, называемый page cache. Туда попадают данные, к которым чаще всего обращаются процессы, запущенные в системе. Таким образом снижается нагрузка на диски и уменьшается время доступа к этим данным.
Самой частой и очевидной рекомендацией по снижению использования свопа является уменьшение параметра vm.swappiness, например, до 10-ти. В этом случае данные в swap будут уходить только при очень серьёзном дефиците доступной оперативной памяти.
Казалось бы, уменьшай vm.swappiness, что тут думать. Но не всё так просто. Уменьшение использования swap уменьшит и размер доступной памяти под page cache. А в случае смешанной нагрузки на сервер, особенно со статикой от сайтов, не факт, что так будет лучше. Итоговая производительность всех сервисов может наоборот снизиться. Измерить результат в конкретных метриках очень сложно.
При таких вводных становится понятно, что если есть возможность и целесообразность, то разнородные сервисы лучше разделять по разным виртуалкам. Если у вас на сервере только СУБД и памяти хватает, то можно особо не заморачиваться и реально ставить vm.swappiness = 10. По моим представлениям это практически всегда пойдёт только в плюс производительности. Если СУБД чётко настроить под конкретные параметры виртуальной машины, она не будет выходить за свои лимиты настроенных ресурсов.
А вот если у вас разнородные сервисы, нагрузка смешанная, много чтений мелких файлов с диска, есть всплески нагрузки, то уже однозначно не ответить, как лучше поступить. Я лично не стал трогать vm.swappiness, оставил значение по умолчанию в 60. Не знаю точно, что СУБД сгружает в swap. По логике это должно быть что-то не очень важное и требовательное, раз СУБД решила не забирать память под кэши, а сгрузила их в swap. Ну и плюс, проходить внезапные пики потребления памяти будет проще, когда есть запас.
Если тоже задавались этим вопросом, то что в итоге для себя решили с использованием swap?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#perfomance #webserver
В данном случае речь пойдёт про типовой веб сервер всё в одном: MariaDB + Angie + PHP-fpm и некоторые сопутствующие сервисы для обеспечения безопасности, мониторинга и сбора логов.
Первым делом смотрю, кто занимает swap. В заметке по ссылке всё описано, не буду подробно останавливаться на этом. Кратко можно посмотреть прямо в консоли:
# for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3} END { print ""}' $file; done | sort -k 2 -n -r | lessПервая строка - главный потребитель swap. В моём случае процесс mariadbd. Смотрим состояние памяти:
# free -m
total used free shared buff/cache available
Mem: 3915 2731 185 89 1373 1183
Swap: 976 906 69В системе 4GB оперативной памяти и 1GB swap. При этом доступно более 1GB оперативной памяти. По логике хотя бы её часть ещё могла бы использоваться вместо свопа.
За то, как активно система использует swap, отвечает параметр ядра vm.swappiness. Смотрим текущее значение:
# sysctl vm.swappinessvm.swappiness = 60По умолчанию разработчики Linux его ставят в значении 60. Оно обеспечивает баланс между swap и page cache. Напомню, для тех, кто не знает или забыл, что свободная оперативная память в Linux не простаивает, а используется под статический кэш, называемый page cache. Туда попадают данные, к которым чаще всего обращаются процессы, запущенные в системе. Таким образом снижается нагрузка на диски и уменьшается время доступа к этим данным.
Самой частой и очевидной рекомендацией по снижению использования свопа является уменьшение параметра vm.swappiness, например, до 10-ти. В этом случае данные в swap будут уходить только при очень серьёзном дефиците доступной оперативной памяти.
Казалось бы, уменьшай vm.swappiness, что тут думать. Но не всё так просто. Уменьшение использования swap уменьшит и размер доступной памяти под page cache. А в случае смешанной нагрузки на сервер, особенно со статикой от сайтов, не факт, что так будет лучше. Итоговая производительность всех сервисов может наоборот снизиться. Измерить результат в конкретных метриках очень сложно.
При таких вводных становится понятно, что если есть возможность и целесообразность, то разнородные сервисы лучше разделять по разным виртуалкам. Если у вас на сервере только СУБД и памяти хватает, то можно особо не заморачиваться и реально ставить vm.swappiness = 10. По моим представлениям это практически всегда пойдёт только в плюс производительности. Если СУБД чётко настроить под конкретные параметры виртуальной машины, она не будет выходить за свои лимиты настроенных ресурсов.
А вот если у вас разнородные сервисы, нагрузка смешанная, много чтений мелких файлов с диска, есть всплески нагрузки, то уже однозначно не ответить, как лучше поступить. Я лично не стал трогать vm.swappiness, оставил значение по умолчанию в 60. Не знаю точно, что СУБД сгружает в swap. По логике это должно быть что-то не очень важное и требовательное, раз СУБД решила не забирать память под кэши, а сгрузила их в swap. Ну и плюс, проходить внезапные пики потребления памяти будет проще, когда есть запас.
Если тоже задавались этим вопросом, то что в итоге для себя решили с использованием swap?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#perfomance #webserver
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍133👎4
Я очень давно знаю Zabbix. Впервые увидел его версию 1.8. Сам изучал, настраивал и внедрял версию 2.0. С тех пор я его активно использую уже более 13-ти лет. Для меня это образец качественного и продуманного программного обеспечения, которое на протяжении более 20-ти лет стабильно становится всё лучше и лучше. Несмотря на свой почтенный возраст, активно развивается, следует современным тенденциям и технологиям. Вот уже и облачный сервис появился. Представляю, сколько труда было потрачено, чтобы перенести в SaaS монолит с такой историей разработки.
Всё это заслуга и труд его создателя-основателя, а потом и руководителя Алексея Владышева, который в 1998 самостоятельно начал разработку, будучи кем-то вроде сисадмина или сотрудника техподдержки в банке. Он рискнул и начал развивать продукт полностью в открытом формате open source. Это сейчас уже привычная модель развития, а в то время ещё не было успешных примеров такой модели, кроме разве что RedHat. И с той поры ничего принципиально не поменялось. Zabbix по-прежнему полностью открыт и бесплатен, нет деления на версию community с ограниченными возможностями и платной с полными, как это чаще всего бывает. Вы можете взять полнофункциональный код продукта и использовать у себя. Считаю это огромным управленческим достижением Алексея, как руководителя и разработчика.
Всегда с интересом смотрю все его выступления. Он бывал на конференциях в Москве. К сожалению, последнее время на русском языке их не встречал, хотя в целом Zabbix от него не отказался. Периодически проводятся вебинары, а в августе был онлайн митап на русском языке. С Алексеем когда-то давно был интересный подкаст, который я с удовольствием слушал. Чего-то более нового мне не попадалось. Послушайте, если вам интересна история Zabbix и его основателя.
Сейчас анонсирован новый онлайн митап совместно с компанией Gals Software, рекламу курсов которой по Zabbix вы периодически видите на моём канале. Увидел новость у них на канале. Эту публикацию у меня никто не заказывал, пишу от себя. На этом митапе выступит Алексей Владышев на русском языке и расскажет о нововведениях 8-й версии. Я записался и обязательно послушаю.
Пишу эту заметку в том числе, чтобы выразить своё уважение и признательность разработчикам Zabbix за отличный продукт, которым я совершенно бесплатно много лет пользуюсь. Знаю, что мой сайт в те времена, когда я активно писал заметки про Zabbix читали, делали обратные ссылки на мои материалы на официальном сайте, реализовывали какие-то костыли, собранные в том числе с подобных сайтов энтузиастов, в основные шаблоны. Может быть и это сообщение дойдёт до адресатов.
🗓 Онлайн встреча будет 3 декабря, в часовом поясе Алматы GMT+5. После регистрации я получил уведомление, что по Москве это будет 02:00 PM. Я тут боюсь ошибиться, так как уже не раз пропускал разные мероприятия из-за того, что путал часовые пояса и приходил не в то время. Получается, что это будет 04:00 PM (16:00) по часовому поясу Алматы или в 14:00 по Москве.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#zabbix
Всё это заслуга и труд его создателя-основателя, а потом и руководителя Алексея Владышева, который в 1998 самостоятельно начал разработку, будучи кем-то вроде сисадмина или сотрудника техподдержки в банке. Он рискнул и начал развивать продукт полностью в открытом формате open source. Это сейчас уже привычная модель развития, а в то время ещё не было успешных примеров такой модели, кроме разве что RedHat. И с той поры ничего принципиально не поменялось. Zabbix по-прежнему полностью открыт и бесплатен, нет деления на версию community с ограниченными возможностями и платной с полными, как это чаще всего бывает. Вы можете взять полнофункциональный код продукта и использовать у себя. Считаю это огромным управленческим достижением Алексея, как руководителя и разработчика.
Всегда с интересом смотрю все его выступления. Он бывал на конференциях в Москве. К сожалению, последнее время на русском языке их не встречал, хотя в целом Zabbix от него не отказался. Периодически проводятся вебинары, а в августе был онлайн митап на русском языке. С Алексеем когда-то давно был интересный подкаст, который я с удовольствием слушал. Чего-то более нового мне не попадалось. Послушайте, если вам интересна история Zabbix и его основателя.
Сейчас анонсирован новый онлайн митап совместно с компанией Gals Software, рекламу курсов которой по Zabbix вы периодически видите на моём канале. Увидел новость у них на канале. Эту публикацию у меня никто не заказывал, пишу от себя. На этом митапе выступит Алексей Владышев на русском языке и расскажет о нововведениях 8-й версии. Я записался и обязательно послушаю.
Пишу эту заметку в том числе, чтобы выразить своё уважение и признательность разработчикам Zabbix за отличный продукт, которым я совершенно бесплатно много лет пользуюсь. Знаю, что мой сайт в те времена, когда я активно писал заметки про Zabbix читали, делали обратные ссылки на мои материалы на официальном сайте, реализовывали какие-то костыли, собранные в том числе с подобных сайтов энтузиастов, в основные шаблоны. Может быть и это сообщение дойдёт до адресатов.
———
ServerAdmin:
#zabbix
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍165👎8
Рег.облако возвращает 100% за Kubernetes
Подключайте кластеры K8s от Рег.Облака до 30 декабря и получите обратно 100% потраченных средств за первый месяц. Полученные бонусы можно тратить на любые другие облачные услуги.
Подробности — вот здесь.
Подключайте кластеры K8s от Рег.Облака до 30 декабря и получите обратно 100% потраченных средств за первый месяц. Полученные бонусы можно тратить на любые другие облачные услуги.
Подробности — вот здесь.
👎17👍5
Перебирал старые скриншоты под новую тематику и нашёл несколько подходящих. Это один из них.
Казалось бы избитая тема. Ну кто догадается класть бэкапы на тот же сервер? Для кого-то это может показаться удивительным, но не для меня.
Из-за публичности мне регулярно пишут разные люди о своих проблемах. Например, открыл возможность писать сообщения напрямую через функциональность этого канала и туда в основном пишут люди о своих проблемах. Если ответ или подсказку сразу не знаю, то обычно не отвечаю, так как нет времени вникать и разбираться в чужой проблеме.
На картинке реальный диалог, который у меня состоялся несколько лет назад. Наверняка и сейчас найдутся люди, которые считают raid1 или снэпшот сравнимым по надёжности с бэкапом или те, кто хранят их локально. Кто-то может даже наберётся смелости и напишет об этом в комментариях😁 а потом исправит эту ошибку.
#ужасы_ит
Казалось бы избитая тема. Ну кто догадается класть бэкапы на тот же сервер? Для кого-то это может показаться удивительным, но не для меня.
Из-за публичности мне регулярно пишут разные люди о своих проблемах. Например, открыл возможность писать сообщения напрямую через функциональность этого канала и туда в основном пишут люди о своих проблемах. Если ответ или подсказку сразу не знаю, то обычно не отвечаю, так как нет времени вникать и разбираться в чужой проблеме.
На картинке реальный диалог, который у меня состоялся несколько лет назад. Наверняка и сейчас найдутся люди, которые считают raid1 или снэпшот сравнимым по надёжности с бэкапом или те, кто хранят их локально. Кто-то может даже наберётся смелости и напишет об этом в комментариях
#ужасы_ит
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍57👎2
Хочу отдельно привлечь ваше внимание к циклу видео с youtube канала RealManual, которые там недавно появились. Не стал их добавлять в общую подборку, потому что их там много и все я не смотрел. Видео этого автора часто бывают у меня на канале, как и он сам иногда появляется в комментариях.
Василий выложил серию роликов про Proxmox из своего платного курса. Там не только непосредственно гипервизор, но и обвязка вокруг него: PBS, NFS и Ceph для хранилищ, Linstore, Terraform и т.д. Качество материала на хорошем уровне: наглядно, простыми словами, всегда с примерами. Всё делается на наших глазах. Несмотря на то, что всё снималось в разное время и уже с устаревшими версиями, вся база не изменилась. Появились какие-то новые возможности, типа SDN, но все старые материалы остались актуальны. Например, я проксомовский SDN не использую.
Отдельно отмечу одно видео под названием Proxmox VE: храним и бекапим - Бонусы: Бекапы (факапы) и ресторы. Я его посмотрел и увидел новую для себя информацию. В Proxmox есть один важный нюанс с бэкапом и восстановлением LXC контейнера, который может привести к безвозвратной потери данных.
Если вы исключили из бэкапов какой-то подключенный к контейнеру диск, забэкапили контейнер, а потом восстановили из бэкапа, этот исключённый диск будет автоматически удалён без каких-либо вопросов. Просто вжик и ничего нет. Поведение неочевидно и пока не столкнёшься, вряд ли будете ожидать такого. Причём я часто так делаю с виртуалками. Создаю быстрые бэкапы только с системным диском, чтобы можно было оперативно откатить только систему, а не терабайты подключенных к ней данных.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#видео #обучение #proxmox
Василий выложил серию роликов про Proxmox из своего платного курса. Там не только непосредственно гипервизор, но и обвязка вокруг него: PBS, NFS и Ceph для хранилищ, Linstore, Terraform и т.д. Качество материала на хорошем уровне: наглядно, простыми словами, всегда с примерами. Всё делается на наших глазах. Несмотря на то, что всё снималось в разное время и уже с устаревшими версиями, вся база не изменилась. Появились какие-то новые возможности, типа SDN, но все старые материалы остались актуальны. Например, я проксомовский SDN не использую.
Отдельно отмечу одно видео под названием Proxmox VE: храним и бекапим - Бонусы: Бекапы (факапы) и ресторы. Я его посмотрел и увидел новую для себя информацию. В Proxmox есть один важный нюанс с бэкапом и восстановлением LXC контейнера, который может привести к безвозвратной потери данных.
Если вы исключили из бэкапов какой-то подключенный к контейнеру диск, забэкапили контейнер, а потом восстановили из бэкапа, этот исключённый диск будет автоматически удалён без каких-либо вопросов. Просто вжик и ничего нет. Поведение неочевидно и пока не столкнёшься, вряд ли будете ожидать такого. Причём я часто так делаю с виртуалками. Создаю быстрые бэкапы только с системным диском, чтобы можно было оперативно откатить только систему, а не терабайты подключенных к ней данных.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#видео #обучение #proxmox
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍129👎6