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

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

Поэтому я предлагаю перевод статьи о том, как работает правило 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, я считал, что он мне прослужит лет десять. Но в этом году концепция поменялась, потому затеял замену.

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

За последние пару лет российский рынок пережил несколько крупных инцидентов: пожары в дата-центрах, отказ систем электропитания, сбои в облачных платформах и разрушительные кибератаки. Каждое из них сопровождалось потерями данных и простоями, которые для бизнеса оборачивались серьёзными убытками.

Инфраструктурные сбои всегда были частью реальности, но теперь стали частыми. Масштабы разные, но вывод один: полагаться только на бэкап — всё равно что держать огнетушитель и верить, что им удастся потушить пожар целого здания. И если бэкап — это огнетушитель, то DR (disaster recovery) — это план эвакуации. Бэкап может «сбить пламя в одной комнате», но если «горит весь этаж» — без плана выбраться из здания шансов мало. Сегодня, когда практически любой бизнес завязан на IT, наличие рабочего плана аварийного восстановления перестало быть «опцией для корпораций». Это обязательный элемент выживания. Вопрос только в том, готова ли ваша инфраструктура к сбою?

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

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