🐧 Bash: Умная очистка логов без риска убить систему

Частая ошибка админа — удалять логи командой rm. Если сервис продолжает писать в файл, место на диске не освободится (файл останется "призраком"), пока сервис не рестартанут. 👻 Правильный путь — обнуление через перенаправление.

Скрипт-однострочник для безопасной очистки:

#!/bin/bash
# Находим все логи больше 500Мб в /var/log и обнуляем их содержимое
find /var/log -type f -name "*.log" -size +500M -exec sh -c '> "{}"' \;

echo "✅ Тяжелые логи обнулены, дескрипторы сохранены!"

Почему это OK:

1. > "{}" — очищает содержимое файла, но оставляет сам файл на месте.
2. Сервис (nginx, mysql) не теряет связь с файлом и продолжает писать в него без рестарта.
3. Система мгновенно видит свободное место. 📦

#linux #bash #sysadmin #automation #storage #server_cleanup 🛠️

⚡ PowerShell: Ищем «тяжелые» файлы быстрее, чем проводник

Когда на диске Windows Server внезапно заканчивается место, стандартный поиск Windows — это мучение. 🐌 Через PowerShell можно выудить список самых больших файлов за считанные секунды и сразу отсортировать их.

Полезный скрипт для поиска ТОП-10 тяжеловесов:

# Ищем файлы больше 500Мб в папке C:\Shares
$path = "C:\Shares"
Get-ChildItem -Path $path -Recurse -File -ErrorAction SilentlyContinue | 
    Sort-Object Length -Descending | 
    Select-Object Name, @{Name="Size(GB)";Expression={$_.Length / 1GB}}, Directory | 
    Select-Object -First 10 | 
    Format-Table -AutoSize

Write-Host "📊 Сканирование завершено. Время чистить диски!" -ForegroundColor Cyan

Фишка: Параметр -ErrorAction SilentlyContinue позволяет скрипту не спотыкаться на системных папках, куда у админа нет доступа, и продолжать поиск. Вывод в гигабайтах сразу дает понять масштаб бедствия. 📈

#windows #powershell #sysadmin #storage #cleanup #automation 🧹

💿 Windows Storage: Как вычислить «паршивую овцу» в дисковом массиве?

Бывает, что сервер или кластер (S2D) начинает безбожно тупить, но все статусы светятся зеленым «Healthy». В 90% случаев проблема в одном диске, который еще не сдох, но уже «тормозит» весь массив огромными задержками (latency). 🐌

Стандартный мониторинг это часто пропускает, поэтому лезем под капот к счетчикам надежности (Reliability Counters).

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

Get-PhysicalDisk | ForEach-Object {
    $disk = $_
    $stats = $disk | Get-StorageReliabilityCounter
    
    # Пытаемся выцепить имя узла (актуально для кластеров)
    $NodeName = "Unknown"
    if ($disk.FriendlyName -like "*.*") {
        $NodeName = $disk.FriendlyName.Split(".")[1]
    }

    [PSCustomObject]@{
        Node            = $NodeName
        Model           = $disk.Model
        MediaType       = $disk.MediaType
        SerialNumber    = $disk.SerialNumber
        
        # Конвертация: 100 наносекунд -> миллисекунды
        ReadLatMax_ms   = [math]::Round($stats.ReadLatencyMax / 10000, 2)
        WriteLatMax_ms  = [math]::Round($stats.WriteLatencyMax / 10000, 2)
        
        ReadErrors      = $stats.ReadErrorsTotal
        WriteErrors     = $stats.WriteErrorsTotal
    }
} | Sort-Object WriteErrors, WriteLatMax_ms -Descending | Format-Table -AutoSize

📊 Как читать результат (нормативы):

1. Read/WriteLatMax_ms: Это пиковая задержка в миллисекундах.
* SSD: Норма до 20ms. Пики > 50ms — повод напрячься. ⚡
* HDD: Норма до 200ms. Пики > 1000ms (1 сек) — диск «умирает» или перегружен. 🐢

2. Read/WriteErrors: В идеальном мире здесь должен быть 0. Любое число больше нуля — это ошибки чтения/записи. Пора проверять кабели, бэкплейн или готовить замену диску. 🛠

💡 Когда запускать?

* Когда SQL или 1С начинают «фризить» без видимых причин. 📉
* При регламентном объезде серверов раз в месяц.
* Если диск периодически отваливается из RAID-массива.

Этот скрипт — твой рентген для дисковой подсистемы. Сохраняй в шпаргалки! 📝

#windows #powershell #storage #sysadmin #troubleshooting #s2d #hardware 🛡

🐧 Linux: Ошибка "Read-only file system"? Спасаем данные без ребута 🛠️

Страшный сон админа: файловая система внезапно ушла в read-only из-за ошибок в логах или сбоя питания.
Сервисы встали, база упала. Прежде чем бежать за новым диском, можно попробовать «пересобрать» её на лету.

Шаг 1: Проверяем, что случилось

dmesg | grep -i "error|jbd2"

тут будет причина (обычно битые блоки или сбой журнала).

Шаг 2: Магия перемонтирования Если диск физически жив, можно принудительно вернуть ему режим записи:

mount -o remount,rw /

Шаг 3: Исправление «на ходу» (для ext4) fsck -n /dev/sda1 — только проверка (без правок). Если ошибок много, используем debugfs для вытаскивания критичных конфигов, пока диск окончательно не «отвалился».

Совет: Если такое случилось на виртуалке, проверь задержки (latency) на СХД — часто диск уходит в RO, если гипервизор не ответил вовремя. 📡

#linux #filesystem #troubleshooting #sysadmin #ext4 #storage

🐧 Linux: Магия tune2fs — освобождаем 50 ГБ места из воздуха 🪄

Ситуация: диск забит на 100%, удалять нечего, а сервис нужно поднять прямо сейчас.
Мало кто помнит, что файловая система ext4 по умолчанию резервирует 5% объема диска "для нужд суперпользователя" (чтобы root мог зайти и починить систему, если диск забит).

На диске в 1 ТБ это целых 50 ГБ, которые просто недоступны пользователям и приложениям.
Для раздела с данными (не системного) это расточительство.

Как вернуть это место без удаления файлов:
Уменьшаем резерв до 1% (или даже 0% для файлопомоек):

sudo tune2fs -m 1 /dev/sdX1

Результат: df -h мгновенно покажет свободное место. Сервисы снова работают, алерт закрыт.

Важно: Не делай 0% на корневом разделе (/), там резерв нужен для стабильности системы. ⚠️

#linux #storage #ext4 #sysadmin #diskspace #lifehack #tune2fs

📦 S3 vs FTP: Почему пора перестать гонять файлы по старинке

Многие по привычке воспринимают S3 (Object Storage) как просто «бесконечную флешку в интернете». Но если копнуть глубже, разница между ним и обычным файловым сервером (FTP/SFTP/NFS) огромна.

1. Иерархия против Плоской структуры

FTP (File Storage): Это дерево. Папки, подпапки, файлы. Если у тебя миллион файлов в одной директории, команда ls или попытка открыть её через клиент заставит сервер «призадуматься» на пару минут.
S3 (Object Storage): Здесь нет папок. Вообще. Есть только Bucket (корзина) и Key (ключ/путь). То, что ты видишь как /uploads/2026/march/photo.jpg — это просто длинное имя одного объекта. Это позволяет S3 находить любой файл среди миллиардов других за фиксированное время.

2. Протоколы и Доступ

FTP: Это отдельный протокол, порты 21 (или 22 для SFTP), проблемы с пассивным режимом и фаерволами.
S3: Это HTTP/HTTPS. Твой файл — это URL. Доступ к нему осуществляется через стандартные REST API запросы (GET, PUT, DELETE). Это делает S3 идеальным для веба: браузеры и мобильные приложения общаются с ним «на одном языке».

3. Масштабируемость и Отказоустойчивость

FTP: Ты ограничен объемом диска на сервере. Кончилось место? Покупай новый диск, расширяй раздел, делай LVM. Упал сервер — файлы недоступны.
S3: Он практически бездонен. Тебе не нужно думать о месте. Более того, облачные провайдеры (AWS, Selectel, Yandex Cloud) реплицируют твои данные между разными дата-центрами. Вероятность потери данных в S3 стремится к нулю.

4. Метаданные

FTP: У файла есть размер и дата изменения. Всё.
S3: Ты можешь прицепить к объекту любые метаданные: Content-Type, Author, Project-ID или даже свои кастомные теги. По этим тегам потом можно настраивать политики автоматического удаления или перемещения в «холодное» (дешевое) хранилище.

🛠 Инструмент админа: rclone
Если тебе нужно перекинуть данные с древнего FTP в современное S3-хранилище, не мучайся со скриптами. Используй rclone — это «швейцарский нож» для облаков.
Команда для синхронизации:

# Настраиваем конфиг через rclone config, а затем:
rclone sync my_ftp:/var/www/uploads my_s3_bucket:backup-2026 -P

Когда НЕ нужен S3?
Если твоей программе нужно постоянно открывать файл, менять в нем одну строчку и сохранять (например, база данных SQLite или редактирование кода «на лету») — S3 не подойдет. Он работает по принципу «перезапиши объект целиком».

#storage #s3 #ftp #cloud #devops #sysadmin #rclone #admin_future

🎓 Собеседование сисадмина. Выпуск №4: Виртуализация и Хранение данных

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

❓ Вопрос 1: «Почему опасно держать снапшот (Snapshot) виртуальной машины дольше пары дней?»
❌ Ответ новичка: «Снапшот занимает много места на диске, и можно просто забыть, что он есть».
✅ Ответ инженера:

1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.

❓ Вопрос 2: «В чем разница между Thin (Тонкими) и Thick (Толстыми) дисками? Что вы выберете для высоконагруженной БД?»
❌ Ответ новичка: «Тонкие диски экономят место, а толстые — нет. Для базы выберу толстые, потому что они надежнее».
✅ Ответ инженера:

Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.

❓ Вопрос 3: «Что такое Split-brain в кластере высокой доступности (HA) и как его предотвратить?»
❌ Ответ новичка: «Это когда два сервера работают одновременно. Предотвратить можно, настроив хороший мониторинг».
✅ Ответ инженера:

Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.

💡 Золотое правило собеса: Помни, что Снапшот — это не бэкап. Это временная точка отката перед рискованной операцией. Если на вопрос «как вы делаете бэкапы» ты ответишь «делаю снапшоты раз в неделю» — собеседование для тебя закончится мгновенно.

Сохраняйте, коллеги! Это те знания, которые превращают «админа-кнопкотыка» в системного архитектора.

#собеседование_AF #virtualization #storage #snapshot #highavailability #proxmox #vmware #admin_future

🐧 Linux: Здоровье ваших NVMe — заглядываем в «мозги» диска через nvme-cli 🏎️

В 2026 году обычные SATA SSD в серверах — это уже почти легаси. Все сидят на NVMe, но многие по привычке проверяют их через smartctl. Однако для глубокой диагностики накопителей на шине PCIe есть родной и более мощный инструмент — nvme-cli.

Техническая суть:
Утилита позволяет не только смотреть SMART, но и управлять очередями, форматировать блоки под разный размер (LBA) и проверять реальный износ ячеек памяти (NAND Endurance).

Команды для проверки:

# Установка (если еще нет)
sudo apt install nvme-cli

# Вывести список всех NVMe дисков и их базовую инфу
sudo nvme list

# Показать детальный лог здоровья (критические предупреждения, температуру, износ)
sudo nvme smart-log /dev/nvme0n1

Зачем это нужно: В поле percentage_used вы увидите реальный износ в процентах. Если там >80% — пора планировать замену, не дожидаясь внезапного Read-Only режима.

#linux #nvme #storage #performance #troubleshooting #sysadmin #admin_future

🐧 Linux: Диета для ARM. Btrfs и прозрачное сжатие под давлением санкций

Привет, коллеги! В 2026 году, когда объемы логов растут быстрее, чем бюджеты на новые NVMe-накопители, а ARM-серверы стали стандартом в наших ДЦ, умение экономить каждый гигабайт — это не жадность, а профессиональное выживание. Если вы до сих пор используете ext4 на системных разделах, вы просто добровольно сжигаете ресурс ячеек памяти и деньги компании.

Техническая суть:
Мы переходим на Btrfs с использованием алгоритма ZSTD. В отличие от старого доброго Gzip, ZSTD нативно поддерживается ядром и умеет в «умное» сжатие: если данные не сжимаются (например, уже зашифрованные бинарники), драйвер просто перестает тратить циклы CPU.

Под капотом: Используем механизм Copy-on-Write (CoW). При записи блок данных сначала сжимается в памяти, а затем атомарно пишется на диск. Это не только экономит до 40-60% места на типичных текстовых логах и конфигах, но и продлевает жизнь SSD, так как физических операций записи становится меньше.

Практика:

Перемонтируем раздел с прозрачным сжатием и проверяем реальную выгоду:

# 1. Добавляем опции сжатия в fstab (уровень 3 — золотая середина для ARM)
# UUID=...  /var/log  btrfs  defaults,compress-force=zstd:3,noatime  0  0

# 2. Если раздел уже смонтирован, применяем на лету к существующим данным
btrfs filesystem defragment -r -czstd /var/log

# 3. Смотрим реальное потребление (df тут бессилен)
# Утилита compsize показывает магию чисел
compsize /var/log

# Вывод будет примерно такой:
# Processed 12405 files, 204856 blocks.
# Raw size: 12.4G
# Compressed size: 4.1G (33.06%)

Зачем это нужно:

Экономия дискового пространства в 3 раза без потери производительности (а на медленных дисках — даже с приростом, так как узкое место — шина данных, а не CPU). Плюс, мгновенные снапшоты позволяют откатить неудачное обновление системы за секунды.

#linux #btrfs #arm #optimization #storage #admin_future

Собеседование в 2026-м — это проверка не на знание команд, а на архитектурную паранойю. Вы должны уметь строить системы, которые выживут, даже если половина вашей инфраструктуры захвачена. Бэкап, который можно удалить — это не бэкап, а иллюзия. Сеть без Zero Trust — это проходной двор.

Золотое правило: Всегда говорите про Audit Log. Фраза «Я настрою экспорт логов доступа к бэкапам в неизменяемое внешнее хранилище» — это автоматический пропуск на следующий этап.

#собеседование_AF #security #storage #minio #quic #zerotrust #sysadmin #admin_future

🐧 Linux: duf — Дисковая статистика здорового человека

Обычный `df -h` в 2026 году на сервере с кучей Docker-контейнеров и смонтированных ARM-разделов превращается в нечитаемую простыню. Пока ты ищешь нужный раздел в этом мусоре, место на диске успевает закончиться окончательно.

Ставь duf (Disk Usage/Free Utility). Она группирует разделы, понимает терминальные темы и рисует понятные прогресс-бары.

Почему это удобно:
✅ Авто-группировка: Отделяет реальные диски от виртуальных (tmpfs, девайсы контейнеров).
✅ Цветовая индикация: Если раздел забит на 90%, ты увидишь это красным цветом сразу, без вчитывания в цифры.
✅ JSON-вывод: Идеально для скриптов, если нужно быстро выкинуть статус дисков в мониторинг.

Установка и запуск:

sudo apt install duf
duf

Если нужно посмотреть только «настоящие» железные диски, чтобы не отвлекаться на мусор: duf --only local.

#linux #tools #duf #storage #cleanup

🎓Собеседование сисадмина. Выпуск #11: Распределенные хранилища (SDS, Ceph, Longhorn)

Привет, коллеги! Продолжаем наш марафон по технологиям 2026 года. В прошлом выпуске мы похоронили классические гипервизоры, но остался вопрос: где хранить данные этих тысяч виртуалок и контейнеров, если мы отказались от проприетарных СХД за десятки миллионов рублей?

В мире отечественных ARM-кластеров и жесткого импортозамещения мы перешли на SDS (Software-Defined Storage). Теперь хранилище — это не дорогая коробка с логотипом вендора, а софт, который объединяет диски обычных серверов в единое пространство.

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

❓ Вопрос 1: «В чем принципиальная разница между классическим SAN/NAS и Software-Defined Storage (SDS)?»

❌ Ответ новичка: «SDS — это когда много дисков в сети. Это дешевле, чем покупать готовый сервер от вендора».

✅ Ответ инженера:

Главное — абстракция. В SDS интеллект (контроллер, кэширование, дедупликация) перенесен из специализированного железа в софт, работающий на обычных узлах.

1. Масштабируемость: В SAN мы ограничены портами контроллера. В SDS (Ceph, Longhorn) мы просто добавляем новый ARM-узел в кластер, и емкость растет линейно.
2. Отказоустойчивость: В SDS данные размазаны по узлам. Выход из строя целого сервера для нас — штатная ситуация, а не катастрофа.
3. Vendor Lock-in: В 2026-м это критично. Мы не зависим от поставок конкретных запчастей, мы используем любые доступные NVMe накопители.

❓ Вопрос 2: «Что такое Replication Factor и Erasure Coding? Когда что выбирать?»

❌ Ответ новичка: «Репликация — это копии, а Erasure Coding — это как RAID, только сложнее».

✅ Ответ инженера:

Это два способа обеспечить выживание данных.

1. Replication (обычно x3): Мы храним три полные копии каждого блока на разных узлах.
Плюс: Максимальная производительность (чтение очень быстрое) и простота восстановления.
Минус: Огромные траты места (платим за 3 ТБ, получаем 1 ТБ полезного объема). Выбираем для БД и горячих виртуалках.

2. Erasure Coding (EC): Данные разбиваются на фрагменты + контрольные суммы (как в RAID 5/6), которые раскидываются по узлам.
Плюс: Экономия места (коэффициент может быть 1.5 вместо 3).
Минус: Высокая нагрузка на CPU и сеть при записи и восстановлении. Выбираем в 2026-м для холодных данных, архивов и бэкапов.

❓ Вопрос 3: «Как вы будете бороться с проблемой Split-brain в распределенном хранилище?»

❌ Ответ новичка: «Надо настроить мониторинг и быстро чинить сеть».

✅ Ответ инженера:

Мониторинг не лечит, он констатирует смерть. Проблема Split-brain (когда две части кластера думают, что они главные) решается на уровне кворума.

1. Нечетное количество узлов: Минимум 3 (лучше 5) мониторов/контроллеров.
2. Алгоритмы консенсуса: Использование Paxos или Raft. Система не позволит записать данные, если большинство узлов не подтвердило операцию.
3. Fencing: Принудительная изоляция (отключение питания или портов) узла, который ведет себя неадекватно, чтобы он не портил данные в общем сторадже.

---

Практический пример: Проверка здоровья Ceph-кластера

В 2026-м ты не кликаешь в веб-морде, ты смотришь статус через CLI, чтобы понимать реальную нагрузку на OSD (диски):

# Проверить общий статус здоровья
ceph health detail

# Посмотреть распределение данных и нагрузку на диски
ceph osd df tree

# Если видишь статус DEGRADED — проверяем, не идет ли сейчас Recovery (восстановление)
ceph -s

Вывод: Админ, который умеет настраивать Ceph или Longhorn на ARM-серверах, в 2026 году — это элита. Ты больше не зависишь от сервисных контрактов, ты сам строишь фундамент, на котором стоит весь бизнес.

Золотое правило: Данные стоят дороже железа. Всегда проверяй Recovery Traffic Limit, чтобы восстановление одного диска не «положило» всю сеть компании.

#собеседование_AF #sds #ceph #longhorn #storage #nvme #admin_future

📂 Windows: Ищем «тяжелые» папки через PowerShell

Коллеги, ситуация: на диске C: осталось 500 Мб, сервер задыхается, а стандартный проводник Windows считает размер папок целую вечность. Нам нужно мгновенно найти виновника, который забил место логами или временными файлами.

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

Скрипт для поиска топ-5 самых тяжелых папок (копируй и запускай):

# Считаем размер папок в корне диска C: и сортируем по убыванию
Get-ChildItem -Path "C:\" -Directory | ForEach-Object {
    $Size = (Get-ChildItem -Path $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum
    [PSCustomObject]@{
        FolderName = $_.Name
        Size_GB    = [math]::round($Size / 1GB, 2)
    }
} | Sort-Object Size_GB -Descending | Select-Object -First 5 | Format-Table -AutoSize

Зачем это нужно:

Для оперативной очистки. Обычно виноваты либо логи IIS, либо папки Temp, либо чьи-то забытые бэкапы прямо на системном диске. Пять секунд работы скрипта — и ты знаешь, куда бить.

#windows #powershell #storage #cleanup #sysadmin #admin_future

🐧 Linux: Прощай, ext4? Bcachefs как новый стандарт файловых систем

Коллеги, мы десятилетиями сидели на сверхнадежной, но морально устаревшей ext4. Когда нам нужны были снапшоты и работа с несколькими дисками, мы собирали сложные конструкции из LVM, mdadm и ext4, либо уходили на тяжеловесную ZFS, которая до сих пор живет вне основного ядра Linux из-за лицензий.

К 2026 году ситуация изменилась. Файловая система Bcachefs окончательно стабилизировалась в ядре и начала вытеснять конкурентов.

Что такое Bcachefs:
Ее называют «ZFS для бедных», но на деле это современная Copy-on-Write (CoW) файловая система, которая изначально писалась с прицелом на максимальную производительность и чистоту кода.

Главные фишки для админа:

— Нативная работа с несколькими дисками: Больше не нужен RAID. Вы просто отдаете файловой системе два диска, и она сама зеркалирует данные.
— Тиринг (Caching): Можно объединить быстрый NVMe-накопитель и медленный HDD. Bcachefs сама будет держать горячие данные на SSD, а холодные архивы сбрасывать на жесткий диск.
— Встроенная компрессия и шифрование: Делается на лету силами самой файловой системы, без настройки dm-crypt или LUKS.

Как попробовать:

При форматировании раздела достаточно указать новый тип (если ваше ядро свежее):
mkfs.bcachefs /dev/sda1 /dev/sdb1

Эпоха наслоения технологий (RAID + LVM + FileSystem) уходит. Bcachefs берет все эти функции на себя, работая прямо из коробки ядра Linux. Если вы планируете разворачивать новые файловые хранилища, самое время тестировать этот инструмент.

#linux #bcachefs #storage #filesystem #sysadmin #admin_future

🐧 Linux: Bcachefs выгнали из ядра — и это хорошая новость для тех, кто понимает

Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.

Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.

Что это означает на практике — собираем пул с erasure coding:

# Устанавливаем DKMS-модуль (Ubuntu 24.04 / Debian 13)
apt install bcachefs-tools bcachefs-dkms linux-headers-$(uname -r)

# Форматируем пул из 4 дисков с erasure coding (аналог RAID 5)
# 3 диска данных + 1 диск паритета
bcachefs format \
  --label=storage \
  --erasure_code \
  --replicas=1 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Монтируем (UUID рекомендуется для надёжности)
mount -t bcachefs /dev/sdb:/dev/sdc:/dev/sdd:/dev/sde /mnt/storage

# Проверяем статус пула
bcachefs fs usage /mnt/storage

# Смотрим здоровье устройств
bcachefs show-super /dev/sdb

Зачем это нужно:
ZFS на Linux — всё ещё лицензионный компромисс. Btrfs RAID5/6 в дистрессе ест данные — и сообщество в глубоком отрицании. Bcachefs с erasure coding — это первая GPL-нативная альтернатива, которая делает это правильно. Для хранилища на Proxmox или bare-metal — смотреть обязательно.

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

#linux #bcachefs #filesystem #storage #sysadmin #admin_future

🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне

Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.

До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.

Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.

Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.

Что делать практически прямо сейчас:

# Проверяем версию ядра — нужна 7.0+
uname -r

# На Ubuntu 26.04 LTS (выходит 23 апреля) — будет из коробки
# На текущих системах — смотрим в mainline PPA для тестовых сред:
# add-apt-repository ppa:kernel-ppa/mainline && apt update

# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"

# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"

# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.

# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"

# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point

# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer

# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1  # offline check для диагностики

Зачем это нужно:
Для системных администраторов, отвечающих за XFS-тома на продакшн-серверах, это значимое улучшение quality-of-life. Однако эту возможность не следует использовать как замену полноценному процессу резервного копирования и восстановления. Self-healing — это safety net для конкретного класса сбоев, а не страховка от всего.

Итог: xfs_repair в 3 ночи с rescue USB — это был обряд посвящения для каждого линукс-администратора. В ядре 7.0 этот обряд стал значительно реже встречаться. Бэкапы всё равно делайте.

#linux #xfs #kernel7 #storage #filesystem #sysadmin #admin_future

🪟 Windows: Native NVMe в WS2025 — +80% IOPS, и это ещё не включено по умолчанию

Коллеги, фича которая доступна с октября 2025-го, но большинство администраторов её не включили — потому что она opt-in и спрятана за реестром.

Всё Windows Server до 2025 включительно общался с NVMe-дисками через SCSI-эмуляцию. Команды NVMe переводились в SCSI и обратно — лишний слой абстракции, shared locks в kernel I/O path, лишние CPU-циклы. Включение native NVMe даёт до 80% выше IOPS и до 45% ниже CPU utilization под высокой I/O нагрузкой.

Это особенно важно для Storage Spaces Direct, SQL Server и любых disk-intensive workloads.

# Проверяем установлено ли обновление KB5066835 (октябрь 2025) или новее
Get-HotFix | Where-Object {$_.InstalledOn -gt "2025-10-01"} |
  Select-Object HotFixID, InstalledOn |
  Sort-Object InstalledOn -Descending | Select-Object -First 5

# Включаем Native NVMe через реестр (требует перезагрузки):
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" `
  /v 1176759950 /t REG_DWORD /d 1 /f

# Проверяем что драйвер переключился
# После перезагрузки в Device Manager NVMe диски должны показывать
# "NVM Express Controller" вместо "Standard SATA AHCI Controller"
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive"} |
  Select-Object FriendlyName, Status

# Бенчмарк до и после — замеряем IOPS с DiskSpd:
# (скачать с https://github.com/microsoft/diskspd)
.\diskspd.exe -b4K -d30 -o32 -t8 -r -w0 -L C:\testfile.dat

# Для S2D кластеров — проверяем здоровье после включения
Get-StoragePool | Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, IOPS

Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.

Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.

#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future

🐧 Linux: Proxmox Backup Server 4.2 — S3 из preview стал production, и вот что это меняет

Коллеги, 30 апреля вышел Proxmox Backup Server 4.2 — и это один из тех релизов, где changelog стоит читать внимательно, а не по диагонали.

Три главных изменения для тех кто держит инфраструктуру на Proxmox:

S3-совместимые объектные хранилища теперь официально поддерживаются как backend для бэкапов. Появились счётчики запросов и статистика трафика прямо в сводке datastora — это помогает рано замечать неожиданные всплески трафика. Wasabi, Backblaze, MinIO, RustFS — всё это теперь не "экспериментально", а production-ready.

Push sync jobs теперь могут шифровать снапшоты на лету перед отправкой на удалённый datastore — для сценариев когда принимающий сервер находится в менее доверенной среде. Pull sync jobs симметрично умеют расшифровывать. Ключи для tape и sync теперь управляются из единой панели.

Sync jobs теперь обрабатывают несколько групп параллельно через новый параметр worker-threads. Это увеличивает throughput на высоколатентных линках и помогает обойти ограничения HTTP/2 соединений.

Под капотом: Debian 13.4 Trixie, Linux kernel 7.0 как стабильный default, ZFS 2.4.

# Обновляем существующую установку через APT:
apt update && apt dist-upgrade -y

# Проверяем версию после обновления:
pbs-manager version

# Настраиваем S3 datastore через API (или через WebUI):
# Storage -> Add -> S3-Compatible Storage
# Указываем: bucket, endpoint, access key, secret key, region

# Настраиваем параллельные потоки для sync job (в WebUI):
# Datastore -> Sync Jobs -> Edit -> Worker Threads: 4
# Рекомендуется: 2-8 в зависимости от количества групп и ширины канала

# Проверяем статистику S3 datastora:
# Storage -> [datastore name] -> Summary -> Request Counters
# Мониторим API requests/day и transfer bytes

# Включаем шифрование sync job:
# Sync Job -> Edit -> Encryption -> Enable
# Выбираем ключ (создать: Configuration -> Sync Encryption Keys)

Зачем это важно:
Стратегия 3-2-1 становится реальной без дорогих решений: быстрые локальные бэкапы на основном хранилище PBS, копии в S3 для офсайт-защиты. Теперь это не хак через rclone, а встроенная функция с мониторингом и шифрованием.

Итог: PBS 4.2 — апгрейд без поводов откладывать. Особенно если уже смотрели на S3 как on offsite target.

#linux #proxmox #backup #s3 #storage #sysadmin #admin_future

🐧 Linux: Fedora 44 вышла — и в ней есть кое-что важное для сервера

Коллеги, 28 апреля вышла Fedora Linux 44. Традиционно это не серверный дистрибутив, но Fedora — это preview того, что через полгода-год появится в RHEL, AlmaLinux и Rocky. Смотрим на неё как на хрустальный шар.

Три вещи для сисадмина:

Первое — DNF5 теперь бэкенд для PackageKit. Это означает что скрипты и инструменты, которые зависели от старого бэкенда PackageKit, потребуют обновления. Если у вас есть автоматизация через PackageKit API — проверьте совместимость заранее, до того как это придёт в RHEL 11.

Второе — Stratis 3.9.0 с онлайн-шифрованием. Теперь можно добавить или убрать шифрование существующего storage pool на лету, без пересоздания. Stratis комбинирует XFS, device-mapper для LVM и LUKS/Clevis для шифрования. Для compliance-аудита это неплохая фича.

Третье — /etc/pki/tls/cert.pem удалён по умолчанию. Это может тихо сломать приложения которые зависят от этого файла.

# Обновляемся до Fedora 44 с существующей 42/43:
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

# Проверяем что сломается — ищем зависимость от cert.pem:
grep -r "cert.pem" /etc/ /opt/ /usr/local/ 2>/dev/null | \
    grep -v ".pyc" | head -20

# Если cert.pem нужен — восстанавливаем через update-ca-trust:
update-ca-trust extract
ls -la /etc/pki/tls/cert.pem

# Проверяем что PackageKit теперь через DNF5:
pkcon backend-details
# Должен показать: dnf5

# Смотрим Stratis пулы и шифрование:
stratis pool list
stratis pool encrypt <pool-name>   # добавить шифрование онлайн
stratis pool unencrypt <pool-name> # убрать шифрование онлайн

Зачем это важно:
Fedora 44 чувствует себя не просто точечным релизом, а заявлением о направлении развития. Stratis 3.9.0 с онлайн-шифрованием спасёт чью-то шкуру на compliance-аудите.

Итог: если ведёшь лабу на Fedora — обновляйся. Если держишь RHEL/Rocky — смотри на Fedora 44 как на roadmap следующего RHEL.

#linux #fedora #storage #stratis #sysadmin #admin_future