🛡 Правило 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