🗑 Bash: Правильная ротация бэкапов

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

Задача:
Оставить бэкапы за последние 7 дней.
Всё, что старше — удалить.
Скрипт (cleanup.sh):

#!/bin/bash

BACKUP_DIR="/var/backups/db"
DAYS_TO_KEEP=7

# Проверяем, что директория существует (защита от дурака)
if [ -d "$BACKUP_DIR" ]; then
    echo "🧹 Очистка старых бэкапов в $BACKUP_DIR..."
    
    # Находим файлы старше N дней и удаляем
    # -mtime +$DAYS_TO_KEEP -> старше дней
    # -name "*.gz" -> только архивы (чтобы не удалить лишнее!)
    # -delete -> удаляет без вопросов
    
    find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +$DAYS_TO_KEEP -print -delete
    
    echo "✅ Готово."
else
    echo "❌ Ошибка: Директория $BACKUP_DIR не найдена."
    exit 1
fi

🔥 Pro-Tip: Перед тем как ставить флаг -delete в cron, запустите команду без него (просто с -print), чтобы убедиться, что find нашел именно то, что вы хотите удалить. rm в Linux не прощает ошибок.

#linux #bash #backup #scripting #automation #чеклисты

🛡 Правило 3-2-1 устарело. Встречайте 3-2-1-1-0

Нас всех учили правилу бэкапов 3-2-1:
* 3 копии данных.
* 2 разных носителя.
* 1 копия офлайн (вне офиса).

В 2025 году, в эру программ-вымогателей (Ransomware), этого мало. Шифровальщики научились находить сетевые бэкапы и шифровать их тоже.

Новый стандарт — 3-2-1-1-0:
* 3 копии данных.
* 2 разных типа носителей.
* 1 копия вне офиса (Cloud/Remote).
* 1 копия Immutable (Неизменяемая) или Air-Gapped (Физически отключенная).

Immutable: Это флаг в S3 (AWS/MinIO) или Veeam Hardened Repository. Даже если хакер получит root-права, он не сможет удалить или зашифровать этот бэкап в течение заданного времени (например, 30 дней).

* 0 ошибок при проверке восстановления (SureBackup). Бэкап, который вы не тестово не развернули — это не бэкап, а надежда.

Проверьте свои репозитории. Если у вас нет Immutable-копии — вы беззащитны перед шифровальщиком.

#backup #security #ransomware #veeam #architecture #bestpractice

💾 PowerShell: Бэкап драйверов одной командой

Ситуация: Нужно переустановить Windows на ноутбуке директора или специфическом промышленном ПК. Страх: "А вдруг после переустановки не встанет драйвер на этот редкий RAID-контроллер или Wi-Fi, и я не найду его в интернете?"

Сделайте резервную копию всех установленных драйверов до сноса системы. Сторонний софт не нужен.

Команда (от Админа):

# Создаем папку и выгружаем туда всё
MD C:\MyDrivers
Export-WindowsDriver -Online -Destination C:\MyDrivers

Результат: Windows аккуратно разложит все драйверы ( .inf , .sys , .dll ) по папочкам. Сохраните папку на флешку.

Как восстановить: При установке новой Windows укажите эту папку, или потом в Диспетчере устройств: "Обновить драйвер -> Искать на этом компьютере".

#windows #powershell #drivers #backup #maintenance #lifehack

💾 Правило 3-2-1

В пятницу вечером самое время спросить себя: "Если завтра сгорит серверная, а облако заблокируют — я восстановлю данные?".

Существует только один стандарт надежности бэкапов. Правило 3-2-1.

Разбор:

1. 3 копии данных: Одна боевая (оригинал) + Две резервных.

* Почему: Вероятность смерти одного диска — 1/100. Трех сразу — 1/1 000 000.

2. 2 разных носителя: Не храните все копии на одном RAID-массиве или одном типе дисков.

* Пример: HDD сервера + Ленточная библиотека (или NAS другого бренда).

3. 1 копия оффсайт: Одна копия должна лежать физически в другом здании (или облаке).

* Почему: Пожар, потоп или кража в офисе уничтожат и сервер, и локальный бэкап.

Если у вас нет пункта №3 — считайте, у вас нет бэкапов.

#backup #security #theory #321rule #bestpractice #disasterrecovery #adminlife

🛡️ Skill: Стратегия бэкапов «3-2-1-1-0» — стандарт 2026 года 📦

Обычного правила «3-2-1» больше недостаточно из-за активности вирусов-шифровальщиков. В 2026 году профи используют расширенную схему, чтобы спать спокойно.

Разбор формулы:
* 3 копии данных (оригинал + 2 бэкапа).
* 2 разных носителя (например, диск и облако).
* 1 копия вне офиса (Offsite).
* 1 копия Immutable (неизменяемая) или Offline (Air-gapped). Это защита от шифровальщиков: даже если админский аккаунт взломан, удалить этот бэкап нельзя.
* 0 ошибок. Регулярная автоматическая проверка восстановления (Restore Test).

Инструмент недели: Посмотри в сторону Veeam Hardened Repository (на базе Linux XFS) или Restic с флагом append-only. Это база твоей выживаемости как специалиста.

#backup #security #disaster_recovery #sysadmin #bestpractices #restic #veeam 🛡️

🪟 Windows: Robocopy — копируем файлы как бессмертные 📂

Копируешь 500 ГБ через проводник (Ctrl+C -> Ctrl+V)?
Ошибка сети — и начинай сначала.
Проводник — для пользователей.
Админы используют Robocopy.

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

Команда:

robocopy "C:\Source" "\\Server\Backup" /E /Z /MT:32 /R:5 /W:5

Разбор флагов (чтобы ты понимал суть):

/E — копировать все подпапки (даже пустые).
/Z — Режим возобновления. Если сеть упала, он продолжит с того же места, а не сначала.
/MT:32 — Скорость. Копировать в 32 потока одновременно (как торрент).
/R:5 /W:5 — Если файл занят, пробовать 5 раз с паузой 5 секунд (а не висеть вечно).

Итог: Самый надежный способ перенести данные между серверами.

#windows #backup #robocopy #cmd #sysadmin #migration #files

📦 Бэкапы: «Бэкап Шредингера» и как проверить Veeam через PowerShell 🐈

Главное правило пятницы 13-го: если ты не тестировал восстановление из бэкапа, значит, у тебя нет бэкапа.
Но проверять всё руками — никаких выходных не хватит.

Если ты используешь Veeam Backup & Replication, ты можешь быстро вытащить статус всех последних сессий прямо из консоли, чтобы убедиться, что этой ночью всё прошло без ошибок.

Скрипт быстрого аудита:
Запусти это в PowerShell на сервере Veeam, чтобы получить красные флаги, если они есть:

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue
Get-VBRBackupSession | Where-Object { $_.CreationTime -ge (Get-Date).AddDays(-1) } | 
    Select-Object JobName, Result, CreationTime, EndTime | 
    Sort-Object Result | 
    Format-Table -AutoSize

Что это дает: Ты за одну секунду видишь таблицу всех джобов за последние 24 часа.
Если в колонке Result везде Success — смело закрывай ноут и иди пить кофе. ☕

#veeam #backup #disaster_recovery #powershell #automation #sysadmin #admin_future

📦 Бэкапы: Проверяем связку Veeam + Synology S3 перед выходными 🗄

Уйти на выходные, не проверив бэкапы — это преступление против своей нервной системы. Особенно если у тебя настроено модное резервное копирование серверов через Veeam в S3-хранилище (например, на удаленный NAS Synology с включенной неизменяемостью Object Lock).

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

Сниппет для быстрой проверки (запускаем на сервере Veeam):

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue

# Вытаскиваем все джобы за последние 24 часа и подсвечиваем ошибки
Get-VBRBackupSession | 
    Where-Object { $_.CreationTime -ge (Get-Date).AddDays(-1) } | 
    Select-Object JobName, Result, @{Name="Duration";Expression={$_.EndTime - $_.CreationTime}}, State | 
    Sort-Object Result -Descending | 
    Format-Table -AutoSize

Куда смотреть:

Если в колонке Result видишь Failed с ошибкой доступа к S3 — срочно проверяй сертификаты на Synology или права сервисного аккаунта бакета.
Если везде Success — бэкап Шредингера жив, инфраструктура в безопасности.

#veeam #synology #s3 #backup #disasterrecovery #powershell #sysadmin #admin_future

🛡 Signal 8.0: 64 символа, которые стоят между твоими чатами и ФБР 🔐

Вышел долгожданный релиз Signal 8.0 для всех платформ. Главная фича — Signal Secure Backups. Теперь бэкапы со сквозным шифрованием (E2EE) официально вышли из беты и доступны всем.

Как это работает (технический хардкор):
Signal создает зашифрованный контейнер твоих чатов, который автоматически синхронизируется с облаком. Но есть нюанс: ключ расшифровки состоит из 64 символов.

* Ключ генерируется локально.
* Он никогда не передается на серверы Signal.
* Zero Knowledge: Если ты потеряешь этот код, даже разработчики мессенджера не смогут восстановить твои данные. Это не «восстановление пароля через почту», это математика.

Условия хранения:

* Free: Тексты и медиа за последние 45 дней.
* Paid ($1.99/мес): Хранилище до 100 ГБ и вся история без ограничений по времени.

Ограничения (важно для анонимности):

* Исчезающие сообщения (со сроком <24 часа) и одноразовые медиа в бэкап не попадают. Приватность превыше удобства.

Админский чеклист по внедрению:

1. Обнови приложение до версии 8.0.
2. Иди в Settings -> Backups.
3. Внимание: Сгенерируй 64-значный ключ и сохрани его НЕ в заметках телефона. Распечатай, запиши в KeePassXC или выбей на металлической табличке.
4. Если ключ утерян — бэкап превращается в тыкву (набор случайных байтов).

Вердикт Admin Future:
Для нас, админов, это золотой стандарт. Мы любим бэкапы, но ненавидим утечки. Signal 8.0 дает и то, и другое. Это отличный повод перевести критические обсуждения архитектуры и паролей из ТГ в более защищенную среду.

#security #signal #privacy #backup #encryption #e2ee #messengers #admin_future

💾 Бэкап парка Windows-виртуалок без боли: Правило 3-2-1 в действии 🗄

Допустим, у тебя крутится пара десятков Windows-виртуалок — контроллеры домена, 1С, файловые помойки. Как организовать их резервное копирование так, чтобы спать спокойно и не разориться на enterprise-хранилищах?

Идеальная и проверенная в бою связка: Veeam Backup & Replication + Synology NAS + S3.

Как это работает на практике:

1. Veeam собирает инкременты с виртуалок (через VSS, чтобы базы не побились).
2. Складывает всё это добро на локальный Synology NAS по протоколу SMB3 или iSCSI.
3. Сам Synology (или Veeam через Scale-out Backup Repository) ночью тихонько льет копии в недорогое облачное S3-хранилище.

Главный админский нюанс: Чтобы шифровальщик не снес бэкапы вместе с продом, на Synology обязательно настраиваем отдельную шару с квотами и скрываем её из сетевого окружения, а на самом NAS включаем Btrfs-снапшоты с неизменяемостью (Immutable snapshots).

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

#veeam #synology #windows #backup #disasterrecovery #sysadmin #admin_future

🎓 Собеседование сисадмина. Выпуск #6: Базы данных (Reliability & Scalability)

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

❓ Вопрос 1: «Что такое репликация и в чем разница между Synchronous (Синхронной) и Asynchronous (Асинхронной) репликацией?»

❌ Ответ новичка: «Репликация — это когда данные копируются на другой сервер. Синхронная — это быстро, асинхронная — медленнее».
✅ Ответ инженера:

Репликация — это механизм синхронизации данных между Master (Writer) и Replica (Reader).
* Асинхронная: Мастер записывает данные и тут же подтверждает успех клиенту, не дожидаясь реплики.
* *Плюс:* Максимальная скорость.
* *Минус:* Риск потери данных при падении Мастера (те миллисекунды данных, что не успели улететь на реплику).

* Синхронная: Мастер ждет, пока реплика подтвердит получение данных, и только потом отвечает клиенту.
* *Плюс:* Гарантия сохранности данных.
* *Минус:* Если реплика «залагает» или упадет сеть — встанет и запись на Мастере.

❓ Вопрос 2: «Что такое индексы в БД, и почему нельзя просто навесить их на каждую колонку таблицы "на всякий случай"?»

❌ Ответ новичка: «Индексы нужны для ускорения поиска. Если их много, то всё будет летать».
✅ Ответ инженера:

Индекс — это отдельная структура (обычно B-Tree), которая позволяет не сканировать всю таблицу целиком.
* Проблема: Каждый индекс занимает место на диске. Но главное — любой индекс замедляет запись (INSERT/UPDATE). При каждом изменении данных базе приходится обновлять и все связанные с этой колонкой индексы.
* Вывод: Индексы нужно создавать только на те колонки, по которым реально идет частая фильтрация (WHERE) или сортировка (ORDER BY).

❓ Вопрос 3: «Как вы будете делать бэкап базы объемом в 1 ТБ, чтобы не "положить" сервис во время процесса?»

❌ Ответ новичка: «Сделаю mysqldump или pg_dump ночью, когда никто не пользуется».
✅ Ответ инженера:

Логический бэкап (dump) на терабайтной базе — это плохая идея. Он будет делаться вечно и создаст огромную нагрузку.
* Правильный путь: 1. Снапшоты на уровне ФС/LVM: Замораживаем ФС на секунду, делаем снапшот, размораживаем и спокойно копируем данные.
2. Физический бэкап: Инструменты вроде `pg_backrest` для PostgreSQL или `Percona XtraBackup` для MySQL. Они копируют сами файлы данных «на лету», не блокируя чтение и запись.
3. Бэкап с реплики: Самый надежный способ. Снимаем бэкап с репликационного сервера, чтобы вообще не нагружать основной Master-сервер.

💡 Золотое правило собеса: Если тебя спрашивают про базы, всегда упоминай мониторинг. Фраза «Я обязательно настрою алерты на Replication Lag (задержка репликации) и Disk Space» — это музыка для ушей любого тимлида.

Сохраняйте пост, чтобы не «поплыть», когда база скажет «ой»!

#собеседование_AF #database #mysql #postgresql #replication #backup #sysadmin #devops #admin_future

🐧 Linux: Синхронное плавание данных через rsync

Привет, коллеги! Четверг, 19 марта 2026 года. В мире, где объемы данных растут быстрее, чем зарплаты, копировать файлы по одному — это преступление против здравого смысла. Если ты до сих пор используешь scp для тяжелых директорий или, упаси бог, перекидываешь их через общие папки, ты просто любишь смотреть на ползущую полосу загрузки.

Используй rsync. Это классика, которая в 2026-м остается самым надежным инструментом админа.

Почему это мастхэв:

1. Дельта-копирование: rsync передает только измененные части файлов. Если ты обновил один лог в архиве на 10 ГБ, он не будет перекачивать весь файл.
2. Сохранение прав: Все атрибуты, владельцы и симлинки переезжают на новый сервер в первозданном виде.
3. Докачка: Если связь оборвалась на 99%, rsync продолжит с того же места, а не начнет с нуля.

Практика:

# Синхронизация папки с удаленным сервером
# -a (archive), -v (verbose), -z (сжатие), -P (прогресс и докачка)
rsync -avzP /var/www/site/ admin@remote-server:/var/www/site/

# Удаление файлов на приемнике, если они исчезли на источнике (зеркалирование)
rsync -avzP --delete /backup/local/ backup-server:/storage/remote/

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

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

#linux #rsync #backup #migration #sysadmin #admin_future

🧠 Skills: Бэкап Шредингера — почему ваши резервные копии ничего не стоят

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

Суровая истина системного администрирования гласит: бэкап, который никогда не восстанавливали — это не бэкап. Это просто дорогой файл, занимающий место на диске.

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

Как лечить:

Внедряйте правило Disaster Recovery Day (День аварийного восстановления). Раз в квартал выделяйте чистый тестовый сервер. Отключайтесь от основной сети и пытайтесь поднять копию критического сервиса, используя исключительно вашу документацию и ночные бэкапы.

Опыт инженера измеряется не умением написать bash-скрипт для архивации, а гарантированным временем (RTO), за которое он способен поднять компанию из пепла. Тестируйте восстановление, пока это можно сделать без паники и седых волос.

#skills #backup #disasterrecovery #management #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

🧠 Skills: Veeam Agent CVE-2026-32996 — эксплуатируется или нет? Разбираем, где факт, а где заголовок.

Коллеги, на этой неделе новость «Veeam эксплуатируется в дикой природе» разошлась по лентам. Хороший повод проверить, на чём она держится.

ФАКТЫ:
CVE-2026-32996, Veeam Agent for Microsoft Windows, LPE до SYSTEM, CVSS v4 7.3
Механизм: когда админ открывает агент с повышенными правами, служба VeeamEndpointBackupSvc выдаёт идентификатор сессии. Этот идентификатор пишется открытым текстом в лог, который читают все пользователи машины. Любой, кто его прочитал, может предъявить его службе и выполнять команды как SYSTEM.
Уязвимы: сборки 13.0.2.1102 и ниже
Исправлено: 13.0.3.1220+ (актуальная standalone-версия — 13.1.1.700)
Публичный PoC: с 14 сентября

ЧТО НЕ ФАКТ:
Arctic Wolf сообщил об активной эксплуатации, а затем убрал бюллетень. В бюллетене самого Veeam упоминаний эксплуатации нет, в CISA KEV на момент написания уязвимости тоже нет.
Подтверждённой эксплуатации нет. Но публичный PoC для локальной LPE — это вопрос недель, а не месяцев.

УСЛОВИЯ АТАКИ:
• локальный доступ к машине
• админ хотя бы раз открыл агент с повышенными правами, и сессия активна
Самые рискованные машины — терминальные серверы и общие рабочие станции, где много пользователей и сидит агент.

# Версия агента на машине
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
? DisplayName -like '*Veeam Agent*' | Select DisplayName, DisplayVersion

# По списку серверов
$srv = Get-Content .\servers.txt
Invoke-Command -ComputerName $srv -ScriptBlock {
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
? DisplayName -like '*Veeam Agent*' | Select DisplayName, DisplayVersion
} | Select PSComputerName, DisplayName, DisplayVersion

КАК ОБНОВЛЯТЬ:
Standalone → 13.1.1.700
Агенты под управлением VBR → сначала VBR до 13.0.2.29+, затем убедиться, что агенты реально обновились. Обновление VBR само по себе не означает обновлённых агентов.

Итог: «эксплуатируется» здесь — неподтверждённое утверждение, а публичный PoC и тривиальный механизм — факт. Для решения хватает второго: обновляем, начиная с RDS-хостов.

#skills #veeam #backup #cve #lpe #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

🚨 AhsayCBS: два zero-day, SYSTEM на сервере бэкапов без пароля. Эксплуатация началась через сутки после обнаружения

Коллеги, очередное жесткое подтверждение базового правила: сервер резервного копирования — приоритетная цель номер один для злоумышленников.

📌 ФАКТЫ (отчет Field Effect от 9 октября)
Связка уязвимостей:

CVE-2026-105133 (CVSS 5.5) — логическая ошибка аутентификации в функции проверки пароля checkSysPwd;

CVE-2026-105134 (CVSS 9.3) — критическая инъекция команд ОС (Command Injection) в компоненте Replication Receiver.

Результат цепочки: удаленное неаутентифицированное исполнение произвольного кода (RCE) с наивысшими правами NT AUTHORITY\SYSTEM.

Под ударом: все версии платформы до 10.3.4 включительно. Официальный исправленный релиз на момент публикации вендором не обозначен.

Активная эксплуатация: реальные атаки зафиксированы поздно вечером 7 октября — всего через сутки после первых сигналов. За первые 24 часа подтверждена компрометация как минимум 5 организаций.

Анатомия закрепления: злоумышленники конфигурировали поддельный приемник репликации, заливали JSP веб-шелл, разворачивали скрытый майнер XMRig под маской легитимного процесса Microsoft Edge и прописывали фальшивую службу обновления браузера для автозагрузки.

🛠 ФОРЕНЗИКА И ПОИСК СЛЕДОВ (PowerShell на хосте AhsayCBS)
PowerShell

# 1. Поиск свежих JSP-файлов и шеллов за последнюю неделю
$installDir = 'C:\Program Files\AhsayCBS'
Get-ChildItem -Path $installDir -Recurse -Filter *.jsp -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
  Select-Object FullName, LastWriteTime

# 2. Выявление процессов msedge, запущенных вне легитимной директории Microsoft
Get-CimInstance Win32_Process | 
  Where-Object { $_.Name -like 'msedge*' -and $_.ExecutablePath -notlike '*\Microsoft\Edge\*' } |
  Select-Object ProcessId, Name, ExecutablePath

# 3. Аудит подозрительных служб с «Edge» в названии
Get-CimInstance Win32_Service | 
  Where-Object { $_.DisplayName -match 'Edge' -or $_.Name -match 'Edge' } |
  Select-Object Name, DisplayName, PathName, StartMode

💡 В ЧЁМ СУТЬ

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

Правило изоляции едино для любого решения (Ahsay, Veeam, Proxmox Backup Server, Commvault):

Любые порты управления, API и сервисы репликации никогда не должны смотреть в публичный интернет — только выделенный Management VLAN, изолированный VPN или защищенный туннель.

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

#security #backup #zeroday #ahsay #threathunting #powershell #windows #sysadmin #admin_future

💾 AOMEI Backupper: атакующие подменяли обновления на серверах вендора на 5–10 минут. Проверяем рабочие станции

Коллеги, AOMEI часто стоит на ПК и небольших серверах как бесплатный бэкап. Этот пост для вас.

📌 ФАКТЫ (Google GTIG / Mandiant, ManageEngine)
Группа UNC7017 меняла конфигурацию обновлений на серверах AOMEI в короткие окна: 28 мая (10 минут), 16 июля (6 минут), 20 июля (5 минут). Возможно, были и другие

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

Доставлялись загрузчик CROSSROAD, бэкдор SHINYROAD, подписанный Radmin и фреймворк Adaptix C2 под видом Nitro PDF

Цели — случайные: под удар попадала любая машина, проверявшая обновления в это окно. Тот же механизм обновления у AnyViewer

🛠 ПРОВЕРКА (Windows)
PowerShell

# Задачи планировщика из отчёта
Get-ScheduledTask | Where-Object TaskName -match 'RadminComponentRuntime|NitroRuntime'

# Radmin в профилях пользователей
Get-ChildItem $env:APPDATA, $env:LOCALAPPDATA -Directory -Recurse -Filter '*radmin*' -ErrorAction SilentlyContinue

# Обращения к доменам атакующих в кэше DNS
Get-DnsClientCache | Where-Object Entry -match 'storage-data\.com'

Заблокировать на файрволе: storage-data[.]com, 8.210.84.56, 8.218.65.184, 47.239.60.117, а также исходящий SMB (445) и внешний WebDAV.

💡 В ЧЁМ СУТЬ

Исправление на стороне вендора не лечит уже заражённые машины. И ещё вывод: бесплатный софт с автообновлением на рабочих станциях — тоже цепочка поставок. Его стоит инвентаризировать наравне с корпоративными агентами.

#security #supplychain #backup #windows #threathunting #sysadmin #admin_future

💾 Veeam: критическая дыра в Backup & Replication. Бэкап, который сам нуждается в бэкапе

Коллеги, четверг. Есть три стадии принятия патчей для Veeam: «у нас всё изолировано», «ну это же не RCE» и «срочно в окно обслуживания». Переходим сразу к третьей.

📌 ФАКТЫ (Veeam KB4948, 27 октября)
CVE-2026-108142, CVSS 4.0 — 9.1: обход авторизации в CDP Coordinator Service, без учётных данных, по сети

Затронуты VBR на Windows и Veeam Software Appliance: 13.1 до 13.1.1.18 включительно и 13.0 до 13.0.2.29 включительно

Исправлено: 13.1.2 (13.1.2.57) и 13.0.3 (13.0.3.63)

В том же бюллетене: две path traversal (5.9) для роли оператора восстановления и LPE в Veeam Agent for Linux (7.3) → исправлено в версии 13.1.2.11

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

🛠 ПРОВЕРКА
PowerShell

# Версия VBR на сервере резервного копирования
(Get-Item 'C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Shell.exe').VersionInfo.ProductVersion

# Проверка наличия и статуса службы CDP Coordinator
Get-Service | Where-Object DisplayName -match 'CDP' | Select-Object Name, Status

💡 В ЧЁМ СУТЬ

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

VBR должен жить в изолированном VLAN без прямого доступа из пользовательских подсетей, вне основного домена Active Directory (workgroup / отдельный лес менеджмента), а критичные точки восстановления обязаны лежать в immutable-хранилищах (Linux Hardened Repository или S3 Object Lock). И патчиться такой узел должен в приоритетном порядке — аргумент «он же глубоко внутри сети» здесь не работает.

#veeam #backup #security #cve #sysadmin #admin_future