🐧 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

💾 TrueNAS 27 RC.1: нативный S3 поверх ZFS, RAIDZ для Special vdev и новая схема версионирования

Коллеги, важная новость для тех, кто держит СХД на TrueNAS или выбирает платформу под надежное хранилище и репозитории резервных копий.

📌 ФАКТЫ
Статус релиза: 6 октября представлен билд 27 RC.1. Финальный стабильный релиз 27.0 намечен на начало декабря.

Фундамент системы: ядро Linux 6.18 LTS в связке с OpenZFS 2.4.

Нативный S3-сервер (Early Access): бакеты маппятся напрямую на ZFS-датасеты. Из коробки поддерживаются multipart-загрузка, тегирование, ACL, версионирование и аппаратная неизменяемость (Object Lock / Immutability). Работает полностью изолированно, без выхода в интернет. Продакшен-статус запланирован на 2027 год.

Fusion Pools 2.0: под класс Special vdev (хранение метаданных и мелких блоков) теперь можно использовать топологию RAIDZ, а не только классический Mirror. Кроме того, при отсутствии выделенного ZIL/SLOG этот пул может брать на себя роль журнала транзакций.

Подсистема TrueSearch: движок индексации имён и содержимого файлов с нативной поддержкой поиска Spotlight (macOS) поверх SMB-шар. Важно: датасеты с нативным шифрованием ZFS индексации не подлежат.

Ребрендинг версий: переход на годовые мажорные номера (27, 28 и т.д.) вместо привычной схемы вида 25.04 / 25.10.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

Ключевой тектонический сдвиг — полноценный S3 с поддержкой Immutability прямо из коробки.

Это готовый локальный таргет под неизменяемые бэкапы для Veeam Backup & Replication и Proxmox Backup Server без необходимости городить рядом костыли, сторонние контейнеры или отдельный кластер MinIO.

Однако статус Early Access обязывает: обкатывать технологию в лабах можно уже сейчас, но в боевой прод выводить строго после релиза 27.0 и первых корректирующих сервисных сборок (U1/U2).

🛠 ДИАГНОСТИКА: ПРОВЕРЯЕМ ПУЛЫ И ФЛАГИ ДО АПГРЕЙДА
Bash

# 1. Проверяем здоровье текущих пулов на ошибки и ребилд
zpool status -x

# 2. Проверяем доступность и статус критических фич OpenZFS
zpool get feature@raidz_expansion,feature@block_cloning <имя_пула>

# 3. Ревизия параметров датасетов (размер блока, сжатие, аллокация места)
zfs list -o name,used,avail,compression,recordsize

#storage #truenas #zfs #s3 #backup #linux #sysadmin #admin_future

🛠 DMDE: малоизвестная, но очень сильная утилита для восстановления данных

Коллеги, инструмент в копилку инженера. Большинство дежурно вспоминают R-Studio, TestDisk или PhotoRec, но DMDE (DM Disk Editor and Data Recovery) выручает там, где тяжелые комбайны спотыкаются или зависают на сыплющихся секторах.

📌 ФАКТЫ
Авторский проект: автор — независимый разработчик Дмитрий Сидоров, софт непрерывно развивается с 2006 года. Актуальная стабильная ветка — 4.4.4 (в тестировании 4.5.0).

Кроссплатформенность: работает нативно под Windows, Linux, macOS и DOS. Портативная версия без установки легко закидывается на аварийный live-диск (WinPE / Live Linux) для работы с хостом без загрузки основной ОС.

Поддержка файловых систем: NTFS, ReFS (включая серверные пулы), FAT12/16/32, exFAT, ext2/ext3/ext4, Btrfs, HFS+/HFSX, APFS.

Ключевой функционал:

Экспресс-восстановление случайно удалённых разделов через правку MBR/GPT «на лету»;

Виртуальная сборка программных и аппаратных RAID 0, 1, 4, 5, 6 (включая кастомные задержки и смещения страйпов);

Посекторное клонирование дисков с умным обходом сбойных LBA-блоков и реверсивным чтением;

Полноценный низкоуровневый дисковый hex-редактор с шаблонами структур файловых систем.

Гуманный Free-режим: бесплатная редакция позволяет восстанавливать до 4 000 файлов из текущей выбранной директории за один проход без ограничения по общему объёму и количеству повторных запусков.

⚠️ ОСТОРОЖНО: МАЛВАРЬ В ПОИСКЕ
В репозиториях GitHub и поисковой выдаче сейчас активно крутятся фальшивые сборки с заголовками в духе «DMDE Professional 2026 Full Crack / Keygen». Это чистый дроппер стилеров и инжекторов в процессы. Скачивать утилиту нужно строго с официального зеркала dmde.com.

💡 ПРАВИЛЬНЫЙ АЛГОРИТМ СПАСЕНИЯ ДАННЫХ

Стоп-запись: аварийный накопитель немедленно перемонтируется в

read-only

либо физически выводится из системы. Никаких проверок

chkdsk

или

fsck

на живом диске!

Посекторный образ: сначала снимается полный RAW-образ (встроенным модулем копирования DMDE либо утилитой

GNU ddrescue

).

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

Изолированный таргет: спасённые данные выгружаются на третий, заведомо исправный накопитель.

Bash

# Эталонное снятие посекторного слепка сыплющегося диска через ddrescue:

# 1. Быстрый проход: читаем всё целое, пропуская проблемные зоны и ведя лог-карту
ddrescue -n -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

# 2. Добор битых секторов: до 3 попыток вычитки проблемных кластеров по карте
ddrescue -r3 -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

#tools #datarecovery #dmde #storage #backup #sysadmin #admin_future

🧠 Skills: EXT4 объявила data=journal устаревшим. Удаление — в 2028 году. Проверьте свои маунты

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

📌 ФАКТЫ
Статус Deprecated: начиная с ядра Linux 7.3 режим монтирования data=journal в файловой системе EXT4 официально помечен как устаревший.

Таймлайн удаления: полное выпиливание кода запланировано на начало 2028 года (аккурат после стабилизации LTS-ветки 2027 года).

Что это за режим: в журнал транзакций пишутся не только метаданные файловой системы, но и само тело файлов (данные). Это давало максимальную защиту от повреждений ценой катастрофической просадки пропускной способности (двойная запись). Режим наглухо отключает Delayed Allocation и Direct I/O.

По умолчанию EXT4 работает в режиме data=ordered (журналируются только метаданные) — его эти изменения никак не затрагивают.

🛠 БЫСТРЫЙ ЧЕК СВОИХ СИСТЕМ
Bash

# 1. Смотрим, смонтировано ли что-то прямо сейчас в режиме data=journal
findmnt -t ext4 -o TARGET,SOURCE,OPTIONS | grep "data=journal"

# 2. Проверяем статическую конфигурацию в fstab
grep -n 'data=journal' /etc/fstab

# 3. Проверяем, не зашит ли режим в суперблок раздела как опция по умолчанию
for d in $(findmnt -t ext4 -no SOURCE | sort -u); do
  echo "Устройство $d:"
  tune2fs -l "$d" 2>/dev/null | grep -i 'default mount options'
done

⚠️ Если в выводе суперблока есть параметр

journal_data

— режим активируется ядром по умолчанию при каждом монтировании, даже если в

/etc/fstab

он явно не указан!

💡 В ЧЁМ СУТЬ

Опцию

data=journal

исторически любили включать «для железобетонной надёжности» под базы данных, транзакционные логи или серверы 1С:Предприятия.

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

fsync()

и регулярные проверенные бэкапы, а не костыли на уровне драйвера ФС.

Запас времени на миграцию ещё есть, но найти и перевести такие разделы в стандартный

data=ordered

лучше уже сейчас.

#skills #linux #ext4 #kernel #filesystem #storage #sysadmin #admin_future

🐧 Linux 7.3 вышел — вероятная LTS-версия. Что в нём полезного для серверов

Коллеги, 18 октября Линус Торвальдс представил релиз ядра Linux 7.3. По традиции осенних релизов ожидается, что именно эта ветка получит статус долгосрочной поддержки (LTS).

📌 КЛЮЧЕВЫЕ ИЗМЕНЕНИЯ ДЛЯ СЕРВЕРОВ
Хранилища и ФС:

Оптимизирована параллельная прямая запись (direct I/O) и системный вызов fallocate() в ext4.

Ускорены мелкоблочные direct-чтения в ext4 и XFS: в синтетических тестах Bytedance на пуле быстрых NVMe Gen5 зафиксирован рост с 1,92 до 2,19 млн IOPS.

Время выполнения fsync в Btrfs сокращено до 5 раз в сценариях с частой фиксацией метаданных.

Планировщик CPU: переработан механизм распределения процессорного времени внутри cgroup для предотвращения «залипания» интерактивных и высокоприоритетных задач под тяжелым фоновым троттлингом. Новый сбалансированный режим concur включен по умолчанию (доступен откат к legacy-поведению).

Сетевой стек: поддержка Big TCP расширена на оверлейные туннели VXLAN и GENEVE — критично для высоконагруженных SDN-фабрик и оверлейных сетей Kubernetes/OpenStack (снижение оверхеда на обработку пакетов при 100G+ линках).

Виртуализация: гипервизор KVM научился эффективно детектировать и маркировать «холодную» (неиспользуемую) память гостевых ВМ для прозрачного освобождения хостовых страниц.

Файловый доступ: модуль ядра ksmbd получил нативную поддержку расширений для резервного копирования Apple Time Machine по SMB.

Низкоуровневый ввод-вывод: флаг RWF_DONTCACHE адаптирован для прямых операций с блочными устройствами; добавлены буферные пулы и поддержка zero-copy для FUSE через интерфейс io_uring.

Устаревание: режим монтирования data=journal в ext4 официально помечен как deprecated (полное удаление запланировано на 2028 год).

🛠 СРОКИ ПОЯВЛЕНИЯ В ДИСТРИБУТИВАХ
Ubuntu 26.10: релизный апдейт ядра прилетит через стандартные репозитории в ближайшие недели (стартовала с -rc6).

Ubuntu 26.04 LTS: через стек HWE (Hardware Enablement) в начале 2027 года.

Debian и Proxmox VE: по графику включения в тестовые и стабильные ветки (ветка Proxmox 9).

Bash

# Проверка текущего запущенного ядра на хосте
uname -r

💡 В ЧЁМ СУТЬ

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

На хостах с высокой плотностью контейнеров (LXC, Docker, K8s) обратите особое внимание на поведение нового cgroup-планировщика под пиковой нагрузкой — распределение CPU-квот может стать заметно более агрессивным к фоновым воркерам.

#linux #kernel #lts #storage #performance #sysadmin #admin_future