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

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

В этой статье на примере ПО «Береста» мы разберём, как устроен компонент «Монитор состояния» и какую роль он играет в обеспечении отказоустойчивости инфраструктуры резервного копирования.

Архитектура и место монитора в системе

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

На рис. 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, какие варианты его эксплуатации существуют и каких случаях он действительно оправдан.

Когда‑то мне виделась отличная идея использовать YouTube как надёжное облачное хранилище для своих видеоархивов. Зачем тратить место на локальных дисках, если можно выгружать туда смонтированные ролики или склеенные клипы — всё удобно, всегда доступно с любого устройства в любой момент, без необходимости хранить копии локально. Доступ через браузер или приложение, бесконечное онлайн-хранилище, и видео якобы остаётся в первозданном виде. Но со временем выяснилось, что не всё так просто и безоблачно, как казалось на первый взгляд. Давайте разберёмся, что пошло не так.

Привет, Хабр! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. Сегодня хочу поделиться с вами результатами нашего первого знакомства с системой резервного копирования «Береста». Этот продукт отличается высокой скоростью работы, поддержкой многопоточности и иерархической схемой хранения. Производитель позиционирует «Бересту» как систему, способную решать сложные задачи в области резервного копирования и восстановления данных. Мы не могли пройти мимо и не протестировать такое решение. На что в действительности способна «Береста» — читайте под катом.

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

Потеря данных, одно из самых неприятных происшествий. В статье я дам инструкцию, как сохранять дампы PostgreSQL на независимый сервер.

Мы разберём как подключиться к СУБД PostgreSQL, снять дамп с помощью pg_dump, сохранить его в стороннее облако, отправить статус в сообщении в Telegram с информацией о последнем бэкапе и сделать все это без лишних трат.

Французская компания Linagora продвигает облачный сервис Twake Workplace как опенсорсную и безопасную альтернативу Google Workspace и прочим корпоративным платным облакам. В комплект с чатом и почтой входит Twake Drive — защищённое файлохранилище.

В Twake Workplace код открыт, используются защищённые протоколы JMAP и Matrix, шифрование по умолчанию. В публичном облаке бесплатно дают 5 ГБ на файлы. Но самое главное, что Twake Drive можно установить на собственном сервере, с неограниченным дисковым пространством.

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

В этой статье рассмотрим, в чём разница между резервными копиями, снапшотами и клонированием на примере реального VPS.

Привет, Хабр! Сегодня познакомимся с Кибер Бэкапом 18 — новой версией нашей системы резервного копирования. Релиз у нас получился «увесистый» — мы обеспечили дальнейший рост производительности и масштабируемости системы, защиту новых и развитие возможностей защиты уже поддерживаемых источников данных, реализовали открытый API управления планами защиты, выполнили доработки в части интерфейса и управления системой, а также выпустили ознакомительную MVP‑версию Кибер Медиасервера.

Когда несколько лет назад (в 21 году) я собирал новый домашний сервер вместо Microserver Gen8, я считал, что он мне прослужит лет десять. Но в этом году концепция поменялась, потому затеял замену.