Парадокс резервного копирования образца 2026 года: чем дисциплинированнее вы следуете классическому правилу 3-2-1, тем удобнее ваши бэкапы лежат для шифровальщика — все три копии аккуратно подключены к сети, ровно там, где он их и ищет. Перевод разбора 3-2-1-1-0 — обновлённой версии правила, которое закрывает именно эту дыру.
Несколько дней назад, 29 апреля 2026 года, вышел Proxmox Backup Server 4.2. Формально это промежуточный релиз: обновили базовую систему до Debian 13.4 Trixie, поставили Linux 7.0 как новый стабильный вариант ядра, добавили ZFS 2.4.1, поправили ошибки и доработали интерфейс. Но по смыслу релиз заметнее, чем кажется: S3-совместимые объектные хранилища стали официально поддерживаемыми, синхронизация между серверами научилась работать параллельно, появились шифрование и расшифровка на стороне сервера для задач синхронизации, а группы резервных копий и пространства имён теперь можно перемещать внутри хранилища.
То есть Proxmox Backup Server постепенно уходит от образа «удобной бэкапницы рядом с Proxmox VE». Он становится отдельным сервером резервного копирования: с дедупликацией, политиками хранения, проверкой целостности, удалённой синхронизацией, S3-хранилищами, лентами и внятной эксплуатационной моделью. Нет, не универсальной заменой всем системам резервного копирования на свете, но очень естественным инструментом для тех, у кого инфраструктура уже построена вокруг Proxmox.
У ransomware-операторов теперь есть план: сначала они охотятся за бэкапами, потом — за продакшеном. Перевод технического разбора правила 3-2-1 — что в нём всё ещё работает, что нет и зачем над ним надстроили «1-0».
Прывітаначкі, похоже с одной стороны сегодня программистов нужно меньше чем раньше, с другой стороны — благодаря LLM действительно можно делать задачи на порядок быстрее. Предполагаю, что в ручную этого бота я бы делал месяц, через Codex gpt-5.5 xhigh — часа три.
В Evernote у меня записано много идей. Хорошо бы то, хорошо бы это. И таки некоторый прогресс в их реализации есть. И вот недавно — открываю официальное приложение Evernote на iPhone, а заметки не загружаются. У меня самый дорогой премиум аккаунт. Вот так стало понятно — надо делать.
Про другие неофициальные клиенты:
Я мантейнер Geeknote — неофициальный CLI на Питоне, он внутри моего бота.
NixNote на C++
CliNote на Go — недавно заархивирован — feel free to форкнуть и починить.
И вот теперь я сделал Телеграм бота https://gitlab.com/vitaly‑zdanevich/bot_telegram_evernote
На Питоне — хотя я предпочитаю Go — но Geeknote зависимость на нём, так что для единообразия.
В конце апреля мы выпустили очередное обновление нашей системы резервного копирования Кибер Бэкап. В этом обзоре познакомимся с новыми и обновленными функциями, включенными в релиз, а также расскажем о ключевых направлениях развития продукта.
Вы нормально знаете Ceph, пулы, RGW, где смотреть логи и почему внезапно полезли 403. Вопрос в другом: вокруг кластера живут люди, которым нужен не Ceph, а S3 как диск в облаке. Им нужно залить билд, вытащить дамп, перекинуть префикс между стендами, выдать временную ссылку, проверить, что объект реально лежит и какой у него размер. Без чтения ceph -w s3cmd rados etc, без объяснений про placement groups и без вашего участия в каждой мелочи.
CLI и скрипты вы держите для себя и для пайплайнов.
Консоль облака у вас может быть про другой контур. А типичный пользователь упирается в простую вещь: хочу окно с таблицей, перетаскиванием и понятной ошибкой, а не пятнадцать шагов «спроси админа».
Отсюда и смысл отдельного десктопного клиента под S3 API: не заменить вам эксплуатацию, а снять с вас поток однотипных ручных запросов и дать людям самообслуживание в рамках выданных ключей и политик.
Вокруг резервного копирования Microsoft SQL Server обычно обсуждают либо штатные BACKUP DATABASE ... TO DISK, либо интеграцию с большими корпоративными системами защиты данных. Между этими двумя мирами есть важный слой: VDI (Virtual Device Interface). Именно через него внешнее приложение может встроиться в процесс резервного копирования и восстановления так, чтобы SQL Server писал не в обычный .bak по своему усмотрению, а в управляемый приложением поток данных.
В этой статье разберем небольшой, но вполне рабочий проект на C++, который реализует РК и ВД для MS SQL Server через VDI в ПО «Береста».
Утилита поддерживает:
• полный, дифференциальный и логический backup;
• restore одной базы или всех найденных;
• striped backup/restore в несколько потоков;
• Windows-аутентификацию и SQL-аутентификацию;
• работу с SQL Server 2008-2022.
Почему VDI?
Если задача ограничивается локальным резервным копированием на диск, VDI не нужен: достаточно стандартных T-SQL команд. Но как только появляется внешняя система резервного копирования, картина меняется.
СРК обычно хочет сама управлять:
• жизненным циклом задания;
• маршрутом потока данных;
• параллелизмом;
• политиками хранения;
• журналированием и обработкой ошибок.
И здесь VDI становится мостом между SQL Server и внешним приложением. SQL Server продолжает выполнять привычные BACKUP и RESTORE, но вместо физического файла работает с виртуальными устройствами. А уже клиент VDI читает или записывает данные туда, куда считает нужным: в локальные файлы, сетевое хранилище, object storage, дедуп-слой или собственный медиасервер.
В среде виртуализации цена ошибки выше, чем в физической инфраструктуре: проблема редко затрагивает одну машину — чаще это сразу десятки ВМ и сервисы, на которых завязана половина инфраструктуры. Администратор удалил не тот диск, хранилище повело себя нестабильно, данные оказались повреждены. В такие моменты важен не сам факт наличия резервного копирования, а то, насколько быстро и предсказуемо можно восстановиться.
В SpaceVM система резервного копирования (СРК) изначально проектировалась не как отдельный внешний инструмент, а как часть платформы. Это важно: все сценарии — от быстрого отката до восстановления на другом узле — встроены в общий цикл работы с виртуальными машинами и не требуют отдельной инфраструктуры.
Разберём, как работает СРК в SpaceVM на практике: от моментальных снимков до полноценных резервных копий и массовых сценариев восстановления — то есть всех стандартных задач.
С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.
В ИТ любят слово «отказоустойчивость». Оно звучит инженерно и успокаивающе. Кластеры, зеркала, репликации — всё это создаёт ощущение контролируемости. Но последние десять лет показали неприятную вещь: большинство катастроф происходят не потому, что что-то сломалось, а потому что инфраструктуру целенаправленно уничтожили. Бла-бла-бла.
Последний рубеж: почему ленточная библиотека — это самый надёжный «холодный кошелёк» для данных
В 2025 году мировые потери от киберпреступности, по оценкам отраслевых аналитиков, превысили один триллион долларов США — «это ж сколько стран можно было прокормить?!». В подавляющем большинстве случаев речь идёт об атаках программ‑вымогателей. И в каждом таком инциденте рано или поздно возникает один и тот же вопрос: существует ли копия данных, до которой злоумышленник не сможет добраться?
За последние годы атаки заметно изменились. Если раньше шифровальщики ограничивались отдельными серверами или рабочими станциями, то теперь они целенаправленно идут к системе резервного копирования. Если это удается — атака уже выиграна, даже если остальная инфраструктура формально еще работает. В этот момент становится очевидно: сам факт наличия резервных копий ничего не гарантирует. Поэтому сегодня приходится защищать не только данные, но и саму систему резервного копирования.
Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!
Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?
Все знают, что такое AWS S3, но немногие осознают масштабы, в которых он работает, и те усилия, которые понадобились, чтобы этого добиться.
По сути, это масштабируемый сервис многопользовательского хранилища с API для сохранения и извлечения объектов, обеспечивающий крайне высокую доступность1 и надёжность2 по относительно низкой цене3.
Масштабы
• 400+ триллионов4 объектов
• 150 миллионов запросов в секунду
• > 1 ПБ/с пикового трафика
• Десятки миллионов дисков
А что лежит в основе всего этого?
Жёсткие диски.
Способы достижения S3 таких масштабов — это настоящее инженерное чудо. Чтобы понять и оценить систему, нужно сначала оценить её базовый строительный блок — жёсткий диск.
Жёсткие диски (HDD) — это старая, уже выходящая из моды технология, во многом вытесненная SSDs. Жёсткие диски хрупки физически, ограничены по IOPS и имеют высокие задержки.
Однако благодаря им возможно то, на что пока неспособны флэш-диски: крайне дешёвая экономика хранения.
В крупных компаниях (да и в небольших, если уже совсем откровенно) остановка работы 1С — это не просто технический сбой. Это замороженные процессы, потерянные операции и упущенная выгода. Риск остановки 1С сильно повышается, если вся инфраструктура размещается исключительно на локальных серверах, которые в любой момент могут выйти из строя или потребовать планового обслуживания. Именно с такой ситуацией столкнулся один из наших клиентов, и в этой статье мы расскажем, как создали для него полноценное резервное облако, обеспечив непрерывность работы и защиту данных.
В системах резервного копирования наблюдаемость давно перестала быть вспомогательной функцией – сегодня это неотъемлемая часть эксплуатационной архитектуры. Стабильность СРК определяется не только успешным выполнением задач, но и возможностью быстро отслеживать ключевые метрики, своевременно обнаруживать отклонения и реагировать на инциденты.
В этой статье на примере ПО «Береста» мы разберём, как устроен компонент «Монитор состояния» и какую роль он играет в обеспечении отказоустойчивости инфраструктуры резервного копирования.
Архитектура и место монитора в системе
«Береста» реализует централизованную модель управления. Мастер-сервер выступает основным управляющим узлом, который хранит актуальную конфигурацию, координирует выполнение заданий резервного копирования и восстановления, а также обеспечивает взаимодействие со всеми внешними компонентами.
На рис. 1 показано логическое взаимодействие компонентов системы.
Если посмотреть на отчёты по кибербезопасности последних лет, можно заметить одну интересную вещь.
Количество атак растёт.
Сложность атак растёт.
Стоимость атак растёт.
А вот уровень защиты компаний — не всегда.
Проблема в том, что многие организации до сих пор думают о безопасности примерно так:
В инфраструктурах среднего и крупного масштаба Data Domain давно используется как стандартное целевое хранилище для резервного копирования. Поэтому при развитии «Бересты» для нас было важно реализовать корректную и полноценную поддержку работы с этой платформой через DDBoost.
Разберёмся, как это устроено.
Что такое Data Domain и почему он используется для бэкапа
Dell EMC Data Domain — это специализированная платформа для резервного копирования и архивного хранения данных. По сути, это целевое хранилище для бэкапа: на него сохраняются данные из файловых систем, виртуальных сред и баз данных.
Ключевая особенность Data Domain — дедупликация на уровне блоков. Система хранит не полные копии данных, а только уникальные фрагменты. Повторяющиеся блоки не записываются повторно.
Это даёт два очевидных эффекта:
· существенно сокращается объём хранения;
· снижается нагрузка на сеть при регулярных инкрементальных копированиях.
Дополнительно используется компрессия и оптимизация структуры хранения под задачи резервного копирования и восстановления данных.
Почему NFS — не самый эффективный вариант
Data Domain может использоваться как обычная файловая система по NFS. Но при таком подходе вся логика дедупликации остаётся на стороне хранилища.
Это означает:
· по сети передаются полные объёмы данных;
· дедупликация выполняется уже после приёма;
· растёт нагрузка на сеть и увеличивается окно резервного копирования.
Для крупных инфраструктур такой подход быстро становится узким местом.
Привет! Я работаю с инфраструктурой резервного копирования и системами восстановления данных. За последние годы мы всё чаще сталкиваемся с одной и той же ситуацией: формально резервные копии есть, правила соблюдены, а вот уверенности в восстановлении — нет.
Поэтому я предлагаю перевод статьи о том, как работает правило 3-2-1, почему оно перестало быть универсальным, какие уязвимости оставляет в современных средах и как эволюционировало, чтобы соответствовать современным требованиям к защите данных.
Правило резервного копирования 3-2-1 на протяжении многих лет считалось золотым стандартом защиты данных. Его привлекательность заключалась в простоте: хранить три копии данных, размещать их на двух разных типах носителей и держать одну копию вне основной площадки.
В течение многих лет такой подход обеспечивал практичную и надёжную защиту в эпоху, когда резервное копирование в основном было локальным, а угрозы — значительно менее сложными.
Но это было когда-то.
Сегодняшнее разнообразие угроз кардинально изменилось. Кибератаки стали целенаправленными и многоэтапными: злоумышленники нападают не только на рабочие данные, но и на систему резервного копирования, стремясь устранить все возможные пути восстановления. Одновременно с этим ИТ-среды эволюционировали в сторону гибридных архитектур, постоянно работающих сервисов и облачно-ориентированных моделей. В результате, то, что хорошо работало в простых инфраструктурах, сегодня с трудом справляется с масштабом, скоростью и сложностью современных угроз.
TL;DR: Вы покупаете дорогие security-решения, но при инциденте всё равно паника и хаос? Проблема не в инструментах, а в том, что делаете не на своём уровне зрелости. Разбираем 6 уровней развития ИБ — от «всё на общих паролях» до «безопасность как конкурентное преимущество».
Типичная история: компания тратит на ИБ миллионы, покупает модные SIEM/DLP/EDR, нанимает специалистов, проводит аудиты. А потом прилетает шифровальщик — и выясняется, что бэкапы лежат на том же сервере, доступы раздавали «как у Васи, чтобы не бегать», а план реагирования существует только на бумаге.
Проблема одна: делаете не на своём уровне зрелости.
Зрелость ИБ — это не про стандарты ISO и не про сертификаты SOC2. Это способность не развалиться от типовых проблем и при этом не убить бизнес параноидальным контролем. Это баланс между «нас точно взломают» и «давайте проверять каждый клик сотрудника».
Что внутри статьи:
5 уровней зрелости — от уровня 0 («пароли в общем чате», этот уровень вообще не считаем за уровень) до уровня 5 («ИБ как фактор выигрыша тендеров»)
Портреты компаний на каждом уровне — узнаете себя в первом абзаце
Типичные факапы и почему они происходят именно на вашей стадии
Инструменты и процессы — какие имеют смысл на каждом этапе
Никаких переводов западных фреймворков. Только то, что работает в наших реалиях.
Главный месседж: нормально быть на уровне 2-3, если вы там стабильны и честны с собой. Гораздо хуже притворяться зрелыми на бумаге и гореть на практике. Модель зрелости — это не экзамен на оценку.
Под катом — разбор уровней с примерами, рисками и конкретными действиями. Если хоть раз ловили себя на мысли «мы вроде что-то делаем, но непонятно, достаточно ли этого» — welcome.
