Восстановление данных *

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

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

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

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

На рис. 1 показано логическое взаимодействие компонентов системы.

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

В инфраструктурах среднего и крупного масштаба Data Domain давно используется как стандартное целевое хранилище для резервного копирования. Поэтому при развитии «Бересты» для нас было важно реализовать корректную и полноценную поддержку работы с этой платформой через DDBoost.

Разберёмся, как это устроено.

Что такое Data Domain и почему он используется для бэкапа

Dell EMC Data Domain — это специализированная платформа для резервного копирования и архивного хранения данных. По сути, это целевое хранилище для бэкапа: на него сохраняются данные из файловых систем, виртуальных сред и баз данных.

Ключевая особенность Data Domain — дедупликация на уровне блоков. Система хранит не полные копии данных, а только уникальные фрагменты. Повторяющиеся блоки не записываются повторно.

Это даёт два очевидных эффекта:

·      существенно сокращается объём хранения;

·      снижается нагрузка на сеть при регулярных инкрементальных копированиях.

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

Почему NFS — не самый эффективный вариант

Data Domain может использоваться как обычная файловая система по NFS. Но при таком подходе вся логика дедупликации остаётся на стороне хранилища.

Это означает:

·      по сети передаются полные объёмы данных;

·      дедупликация выполняется уже после приёма;

·      растёт нагрузка на сеть и увеличивается окно резервного копирования.

Для крупных инфраструктур такой подход быстро становится узким местом.

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

Поэтому я предлагаю перевод статьи о том, как работает правило 3-2-1, почему оно перестало быть универсальным, какие уязвимости оставляет в современных средах и как эволюционировало, чтобы соответствовать современным требованиям к защите данных.

Правило резервного копирования 3-2-1 на протяжении многих лет считалось золотым стандартом защиты данных. Его привлекательность заключалась в простоте: хранить три копии данных, размещать их на двух разных типах носителей и держать одну копию вне основной площадки.
В течение многих лет такой подход обеспечивал практичную и надёжную защиту в эпоху, когда резервное копирование в основном было локальным, а угрозы — значительно менее сложными.

Но это было когда-то.

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

Представим ситуацию. У нас на руках есть устройство на базе SoC (чипсет) от Qualcomm в аварийном режиме – emergency download, edl, USB\VID_05C6&PID_9008. Для доступа к памяти устройства, чтобы провести его восстановление, требуется программер. В сети их много и большинство называется просто «prog_firehose_ddr.elf» без указания модели устройства, для которого их разрабатывали. Можно пробовать загружать по одному и проверять подходит или нет, но это очень долго. Куда быстрее и проще проанализировать список из нескольких программеров и проверить на соответствие только несколько, наиболее подходящих из них.

TL;DR: Вы покупаете дорогие security-решения, но при инциденте всё равно паника и хаос? Проблема не в инструментах, а в том, что делаете не на своём уровне зрелости. Разбираем 6 уровней развития ИБ — от «всё на общих паролях» до «безопасность как конкурентное преимущество».

Типичная история: компания тратит на ИБ миллионы, покупает модные SIEM/DLP/EDR, нанимает специалистов, проводит аудиты. А потом прилетает шифровальщик — и выясняется, что бэкапы лежат на том же сервере, доступы раздавали «как у Васи, чтобы не бегать», а план реагирования существует только на бумаге.

Проблема одна: делаете не на своём уровне зрелости.

Зрелость ИБ — это не про стандарты ISO и не про сертификаты SOC2. Это способность не развалиться от типовых проблем и при этом не убить бизнес параноидальным контролем. Это баланс между «нас точно взломают» и «давайте проверять каждый клик сотрудника».

Что внутри статьи:

5 уровней зрелости — от уровня 0 («пароли в общем чате», этот уровень вообще не считаем за уровень) до уровня 5 («ИБ как фактор выигрыша тендеров»)

Портреты компаний на каждом уровне — узнаете себя в первом абзаце

Типичные факапы и почему они происходят именно на вашей стадии

Инструменты и процессы — какие имеют смысл на каждом этапе

Никаких переводов западных фреймворков. Только то, что работает в наших реалиях.

Главный месседж: нормально быть на уровне 2-3, если вы там стабильны и честны с собой. Гораздо хуже притворяться зрелыми на бумаге и гореть на практике. Модель зрелости — это не экзамен на оценку.

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

Привет Хабр!

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

Новая версия Easy Disk Checker - многофункциональной программы для работы с жёсткими дисками, SSD и флешками на «физическом» с точки зрения OS Windows уровне, независимо от файловой системы или её отсутствия. Проверка секторов, анализ SMART а том числе Seagate FARM, определение фейковых флешек, чтение и запись образов, клонирование, восстановление разметки и многое другое.

Привет, Хабр! На связи снова Иван Глинкин, руководитель группы аппаратных исследований из команды Бастиона. 

«Флешка с кодовым замком», «флешка с аппаратным шифрованием», «зашифрованный USB-накопитель», наконец, эталонное название — «криптографический модуль» (Cryptographic Module). У криптофлешки aka encrypted USB много имен, но суть от этого не меняется.

Задача такого устройства — защитить чувствительную информацию от несанкционированного доступа на программно-аппаратном уровне: при помощи шифрования, механизмов антивскрытия и прочих «семи печатей». Однако так ли надежны эти защищенные USB-накопители, как принято считать, или это всё от лукавого? 

Мы решили не доверять маркетинговым заявлениям и провели собственное исследование: попытались взломать несколько таких устройств методами аппаратного реверс-инжиниринга. Попробовали извлечь данные, определить применяемые типы шифрования, вскрыть криптофлешки и прочитать чипы памяти.

Результаты получились интересными. Подробности — под катом.

Четыре года назад у меня Хабре была статья про цифровой недокументированный формат кардиограммы, структуру которого я попытался разгадать по максимуму. В результате мне удалось увидеть формы сигналов сторонними программными инструментами, в том числе и в аудиоредакторе. Более того, я разобрался, как вычислить недостающие 4 отведения, так как в файле было записано только 8 каналов. И в целом мне повезло с форматом представления цифровых данных: никаких там ADPCM 12 бит и близко не было.

В этом году пару месяцев назад мне пришлось столкнуться ещё с одним частным форматом кардиограммы. На этот раз речь пойдёт о мобильном кардиографе белорусской компании «Кардиан». Основная его аппаратная часть – коробка с электроникой, куда подключаются через разъём электроды для снятия кардиограммы. Дополнительная часть – устройство со смартфоном на андроиде, оснащённое термопринтером. Обе части соединяются через Bluetooth. В основной части стоит современный популярный микроконтроллер STM32, но данная статья не про обратную разработку электроники.

Обзор многофункциональной программы для работы с жёсткими дисками, SSD и флешками на «физическом» с точки зрения OS Windows уровне, независимо от файловой системы или её отсутствия. Проверка секторов, анализ SMART а том числе Seagate FARM, определение фейковых флешек, чтение и запись посекторных образов дисков (клонирование).

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

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

Хотите узнать, как легко купить чужие секреты и почему компании продолжают их выбрасывать в 2025 году? Рассказываем подробно.

Для электронной аппаратуры космических систем, и в первую очередь устройств памяти, актуальна задача защиты от воздействия ионизирующего космического излучения и других внешних факторов, искажающих хранимую и обрабатываемую информацию. Радиационные эффекты и космические частицы создают большое число накапливающихся в устройствах памяти ошибок. Использование известных методов помехоустойчивого кодирования информации дает эффект в течение ограниченного времени, пока число ошибок не становится слишком большим. В ответственных системах используется ECC-память – (error-correcting code memory, память с коррекцией ошибок) – тип компьютерной памяти, которая автоматически распознаёт и исправляет спонтанно возникшие изменения (ошибки) битов памяти – одну ошибку в одном машинном слове. При длине машинного слова 64 бита количество исправляемых ошибок < 1,5%.

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

Сегодня SSD стоят почти в любом компьютере. По себе знаю, что люди часто видят диск как просто пространство для файлов и не думают о том, как он внутри работает. А о том, как он справляется с удалениями и записями, и подавно. Тем не менее, хотелось бы знать, что помогает SSD быть быстрее и служить дольше. 

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

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

Я уволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.

Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.

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

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

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

Обычно используют определение из методик COSO (The Committee of Sponsoring Organizations) или стандартов ГОСТ серии 31 000 в виде: «Риск это следствие влияния неопределенности на достижение поставленных целей» либо более коротко, как в стандартах ГОСТ 27 000 или ГОСТ 51897: «Влияние неопределенности на достижение целей». Это определение полезно тем, что привязывает риск к бизнес‑цели и дает возможность отсечь то, что не относится к достижению целей бизнеса. Но, к сожалению, в таком определении отсутствуют четко измеряемые показатели. Поэтому обычно рядом с таким определением есть уточнение или примечание, как в том же стандарте 31000, где говорится, что понятие риска связано с размером потенциального ущерба и вероятностью его наступления. Таким образом у нас появляются два параметра, которые можно измерять.

Сегодня поговорим про восстановление повреждённых данных в СУБД семейства постгрес. Речь именно о повреждённых данных, когда сам постгрес их прочитать уже не может. Задача восстановления таких данных нетривиальная. Тут нет и быть не может универсальных рецептов, иначе они давным давно уже были бы реализованы в виде утилит. Статья написана по мотивам моего выступления на конференции PGConf.Russia в 2023 году. Только сейчас дошли руки её написать, хотя в планах подготовка статьи была изначально. Могу сказать, что в плане восстановления повреждённых данных за эти годы ничего не поменялось, вся информация актуальна.

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

Создатели PostgreSQL справились со своей задачей идеально. Они создали гибкий каркас для широкого спектра сценариев использования в бизнесе системы, которая спустя тридцать лет стала самой популярной СУБД.

В статье перечислены следующие шесть целей проекта:

1. улучшенная поддержка сложных объектов, расширяющих сценарии использования в бизнесе и разработке

2. обеспечение возможности расширения типов данных, операторов и способов доступа для пользователей

3. предоставление средств для активных баз данных (например, уведомлений и триггеров)

4. упрощение процесса восстановления после сбоев

5. использование преимуществ нового оборудования

6. применение реляционной модели Кодда

Давайте рассмотрим их с точки зрения современных возможностей Postgres.

Привет, Хабр! Я Саша, в Хайстекс отвечаю за B2B-продажи и давно работаю с облаками и бэкапом. В этой статье хочу рассказать о подходе, который, на мой взгляд, помогает закрыть одну из самых болезненных задач в этой области. 

При работе с облачными сервисами часто приходится идти на компромисс: либо хранить дешево, но восстанавливать долго, либо платить за скорость. Допустим, у одного eCommerce-сервиса внезапно упал гипервизор, с ним ушли в офлайн несколько ВМ. Все бэкапы хранились в S3-объектном хранилище. Чтобы восстановить ВМ придется разворачивать ее из архива. На все в среднем уходит около 40 минут. Все это время система заказов лежит, а бизнес считает убытки. С Double Storage мы сделали так, что время восстановления сократилось до 6-8 минут. Что это за технология, как она работает и почему с ней действительно проще – разберём под катом. Технические подробности можем разобрать в комментариях, если будет интерес.