Резервное копирование *

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

В SpaceVM система резервного копирования (СРК) изначально проектировалась не как отдельный внешний инструмент, а как часть платформы. Это важно: все сценарии — от быстрого отката до восстановления на другом узле — встроены в общий цикл работы с виртуальными машинами и не требуют отдельной инфраструктуры.

Разберём, как работает СРК в SpaceVM на практике: от моментальных снимков до полноценных резервных копий и массовых сценариев восстановления — то есть всех стандартных задач.

С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.

В ИТ любят слово «отказоустойчивость». Оно звучит инженерно и успокаивающе. Кластеры, зеркала, репликации — всё это создаёт ощущение контролируемости. Но последние десять лет показали неприятную вещь: большинство катастроф происходят не потому, что что-то сломалось, а потому что инфраструктуру целенаправленно уничтожили. Бла-бла-бла.

Последний рубеж: почему ленточная библиотека — это самый надёжный «холодный кошелёк» для данных

В 2025 году мировые потери от киберпреступности, по оценкам отраслевых аналитиков, превысили один триллион долларов США — «это ж сколько стран можно было прокормить?!». В подавляющем большинстве случаев речь идёт об атаках программ‑вымогателей. И в каждом таком инциденте рано или поздно возникает один и тот же вопрос: существует ли копия данных, до которой злоумышленник не сможет добраться?

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

Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!

Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?

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

По сути, это масштабируемый сервис многопользовательского хранилища с API для сохранения и извлечения объектов, обеспечивающий крайне высокую доступность¹ и надёжность² по относительно низкой цене³.

Масштабы

• 400+ триллионов⁴ объектов

• 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.

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

Что такое двухфакторная аутентификация

Двухфакторная аутентификация (2FA) — это способ проверки подлинности пользователя, при котором для входа в систему требуется не только пароль, но и дополнительное подтверждение. Таким образом, личность пользователя подтверждается сразу по двум независимым факторам.

Необходимость 2FA возникла из-за уязвимости паролей. Их могут подобрать, перехватить с помощью фишинга или получить из утёкших баз данных. Даже сложный пароль не гарантирует безопасности при компрометации.

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

Из чего состоят два фактора аутентификации

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

Первый тип — фактор знания. Это информация, которую знает только пользователь, например пароль, PIN-код или ответ на секретный вопрос.

Второй тип — фактор владения. Он подтверждает, что у пользователя есть физический или цифровой объект: смартфон с приложением-аутентификатором, SIM-карта для получения SMS, аппаратный токен или USB-ключ безопасности.

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

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

Системы хранения данных и резервного копирования часто выпускают разные вендоры, поэтому основная задача специалистов — обеспечить бесперебойную работу и выжать максимум скорости из тандема. Чем быстрее данные резервируются и восстанавливаются, тем лучше для бизнеса. В статье расскажем, как лучше всего настроить связку «Бересты» с системой хранения данных TATLIN.BACKUP под конкретные сценарии. Тесты скорости передачи данных с разными настройками ждут вас под катом. 

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

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

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

В 2025 году атаки на резервные копии стали одной из самых опасных киберугроз — они лишают бизнес последней возможности восстановиться после инцидента.

По данным Sophos, в 94% случаев вирусы-шифровальщики целенаправленно атакуют бэкапы. Исследование Wipro показывает, что более 30% таких атак приводят к простою бизнеса на 11–30 дней.

Сегодня на реальном примере покажем, как защититься от подобных угроз. К нам обратилась компания с сообщением о взломе. Несмотря на настроенную двухфакторную аутентификацию, злоумышленники c помощью социальной инженерии получили одноразовый код и обошли защиту ИТ-инфраструктуры.

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

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

Один из подходов, позволяющих защитить резервные копии даже при попытке взлома основной инфраструктуры — резервное копирование с воздушным зазором, или air gap backup. Это метод хранения данных, при котором копии размещаются на носителях или системах, изолированных от сети и недоступных для прямого удаленного доступа.

И здесь идея air gap проста: нельзя повредить или украсть то, к чему невозможно подключиться. Несмотря на то, что технологию придумали еще наши деды, она остается актуальной – особенно в условиях роста числа атак. В этой статье разберем, зачем нужен airgap, какие варианты его эксплуатации существуют и каких случаях он действительно оправдан.