#срк — Public Fediverse posts

Третья копия — это хорошо. А где четвёртая, с блэкджеком и AD?

Привет, Хабр! На связи команда инфраструктурного центра «Инфосистемы Джет». Давайте договоримся сразу — мы любим, применяем и верим в правило «3-2-1», оно работает. Как базовая гигиена. Но важно то, что после «но». Правило «3-2-1» подробно отвечает на вопрос, как хранить резервные копии. Но почти ничего не говорит о том, что делать, если целью атаки становятся сами резервные копии. Поэтому теперь мы считаем, что ему не хватает четвертого элемента — мы называем его «Бункер».

https://habr.com/ru/companies/jetinfosystems/articles/1060854/

#срк #закрытый_контур #восстановление_данных #хранилище #хранение_данных #321 #доверенная_среда #неизменяемые_копии #цод_и_хранение_данных #32210

Резервное копирование MS SQL в «Бересте»: как мы используем VDI

Вокруг резервного копирования 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, дедуп-слой или собственный медиасервер.

https://habr.com/ru/articles/1023254/

#резервное_копирование #срк #восстановление_данных #dvi #sql_server

Когда бэкап — последний «выживший»: почему обычные резервные копии не спасают

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

https://habr.com/ru/companies/jetinfosystems/articles/1019512/

#срк #резервирование #бэкап #шифровальщик #харденинг #хранилище #изоляция #кибербезопасность #киберпротект #бункер

Неудобные вопросы про бэкап PostgreSQL: где заканчивается СУБД и начинается оркестрация

Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры. Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты? Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой. Кат

https://habr.com/ru/companies/hstx/articles/1015500/

#postgresql #резервное_копирование #бэкап #pitr #wal #dba #pg_probackup #срк #оркестрация #восстановление_данных

Как быстро понять, что в системе резервного копирования что-то пошло не так?

В системах резервного копирования наблюдаемость давно перестала быть вспомогательной функцией – сегодня это неотъемлемая часть эксплуатационной архитектуры. Стабильность СРК определяется не только успешным выполнением задач, но и возможностью быстро отслеживать ключевые метрики, своевременно обнаруживать отклонения и реагировать на инциденты. В этой статье на примере ПО «Береста» мы разберём, как устроен компонент «Монитор состояния» и какую роль он играет в обеспечении отказоустойчивости инфраструктуры резервного копирования. Архитектура и место монитора в системе «Береста» реализует централизованную модель управления. Мастер-сервер выступает основным управляющим узлом, который хранит актуальную конфигурацию, координирует выполнение заданий резервного копирования и восстановления, а также обеспечивает взаимодействие со всеми внешними компонентами. На рис. 1 показано логическое взаимодействие компонентов системы.

https://habr.com/ru/articles/1009128/

#срк #резервное_копирование #восстановление_данных #монитор_состояния #береста_рк

Как реализована поддержка DDBoost в «Бересте» при работе с Data Domain

В инфраструктурах среднего и крупного масштаба Data Domain давно используется как стандартное целевое хранилище для резервного копирования. Поэтому при развитии «Бересты» для нас было важно реализовать корректную и полноценную поддержку работы с этой платформой через DDBoost. Разберёмся, как это устроено. Что такое Data Domain и почему он используется для бэкапа Dell EMC Data Domain — это специализированная платформа для резервного копирования и архивного хранения данных. По сути, это целевое хранилище для бэкапа: на него сохраняются данные из файловых систем, виртуальных сред и баз данных. Ключевая особенность Data Domain — дедупликация на уровне блоков. Система хранит не полные копии данных, а только уникальные фрагменты. Повторяющиеся блоки не записываются повторно. Это даёт два очевидных эффекта: · существенно сокращается объём хранения; · снижается нагрузка на сеть при регулярных инкрементальных копированиях. Дополнительно используется компрессия и оптимизация структуры хранения под задачи резервного копирования и восстановления данных. Почему NFS — не самый эффективный вариант Data Domain может использоваться как обычная файловая система по NFS. Но при таком подходе вся логика дедупликации остаётся на стороне хранилища. Это означает: · по сети передаются полные объёмы данных; · дедупликация выполняется уже после приёма; · растёт нагрузка на сеть и увеличивается окно резервного копирования. Для крупных инфраструктур такой подход быстро становится узким местом.

https://habr.com/ru/articles/1004116/

#срк #резервное_копирование #data_domain

Тонкая настройка 2FA: как закрыть доступ к бэкапам, но не замучить админов

Что такое двухфакторная аутентификация Двухфакторная аутентификация (2FA) — это способ проверки подлинности пользователя, при котором для входа в систему требуется не только пароль, но и дополнительное подтверждение. Таким образом, личность пользователя подтверждается сразу по двум независимым факторам. Необходимость 2FA возникла из-за уязвимости паролей. Их могут подобрать, перехватить с помощью фишинга или получить из утёкших баз данных. Даже сложный пароль не гарантирует безопасности при компрометации. Использование двухфакторной аутентификации значительно снижает риск несанкционированного доступа. Даже если пароль стал известен злоумышленнику, без второго фактора вход в систему остаётся невозможным. Из чего состоят два фактора аутентификации Двухфакторная аутентификация опирается на использование двух различных категорий факторов, каждая из которых подтверждает личность пользователя по разному принципу. Классически выделяют три типа факторов. Первый тип — фактор знания. Это информация, которую знает только пользователь, например пароль, PIN-код или ответ на секретный вопрос. Второй тип — фактор владения. Он подтверждает, что у пользователя есть физический или цифровой объект: смартфон с приложением-аутентификатором, SIM-карта для получения SMS, аппаратный токен или USB-ключ безопасности. Третий тип — биометрический фактор. К нему относятся уникальные характеристики человека, такие как отпечаток пальца, распознавание лица или радужки глаза. Двухфакторная аутентификация использует комбинацию факторов из разных категорий, что делает подмену личности существенно сложнее.

https://habr.com/ru/articles/995846/

#срк #двухфакторная_аутентификация

Как добиться резервного копирования на скорости 3,6 ГБ/c: настраиваем СРК «Береста» c TATLIN.BACKUP

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

https://habr.com/ru/companies/yadro/articles/995172/

#СРК #СХД #резервное_копирование #системы_хранения_данных #Береста #TATLINBACKUP #тесты_производительности #интеграция_систем

Как с помощью RuBackup сделать резервное копирование систем виртуализации oVirt, ROSA, zVirt, РЕД Виртуализация, HOSTVM

Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах. Для этого будем использовать систему резервного копирования (СРК) RuBackup.

https://habr.com/ru/companies/astralinux/articles/916004/

#резервное_копирование #виртуализация #итинфраструктура #ovirt #срк #резервная_копия #rubackup #rosa #zvirt #ред_виртуализация

Как настроить резервирование VK Private Cloud с помощью RuBackup

При эксплуатации облаков, в частности приватных, появляется проблема резервного копирования ресурсов облака. Систему резервного копирования RuBackup можно использовать в качестве решения резервного копирования для виртуальных машин в облаках, в том числе на основе VK Private Cloud. Предположим, что в вашей локальной инфраструктуре уже проинсталирован и настроен экземпляр VK Private Cloud. Чтобы RuBackup смог работать внутри VK Private Cloud, для начала требуется создать пользователя системы виртуализации openstack, от имени которого будет работать модуль rb_module_openstack RuBackup.

https://habr.com/ru/companies/astralinux/articles/904488/

#itкомпании #rubackup #итинфраструктура #облачная_инфраструктура #vk #private_cloud #резервная_копия #срк #резервное_копирование

Maipu MPS5580G2: разгадали секреты функционала от QoS до безопасности

Привет, Хабр! Это вторая часть с результатами наших тестов китайского массива. В первом посте мы рассказали, как проходили нагрузочные испытания и проверка на отказоустойчивость. В этой части поделимся результатами функциональных тестов модели Maipu MPS5580G2. Разберем его ключевые возможности: репликацию, метрокластер, QoS, снепшоты, мониторинг и безопасность. Ведь именно для этого в тест мы взяли не один массив, а сразу два!

https://habr.com/ru/companies/jetinfosystems/articles/902808/

#maipu #метрокластер #срк #резервное_копирование #катастрофоустойчивость #отказоустойчивость #дисковый_массив #тестирование #снэпшоты #qos

Мы его нагружали, а он выдержал! Тестируем китайский дисковый массив Maipu

Привет, Хабр! Нам в руки попал китайский массив. Но не прям в руки, а удаленно. И даже не один, а сразу два. И даже не Huawei, а Maipu. Если вы еще не знаете, у этого производителя есть официальный сервисный центр в Москве, но об этом позже. В этом посте мы покажем вам результаты наших тестов, начиная с нагрузки и надежности. А позже, во второй части, расскажем о функционале.

https://habr.com/ru/companies/jetinfosystems/articles/899648/

#maipu #метрокластер #отказоустойчивость #массив #срк

Более 4 000 ГБ за 11 минут: тестируем три сценария резервного копирования с Кибер Бэкап и TATLIN.BACKUP

В формуле идеального решения для резервного копирования данных enterprise-класса много переменных. Одна из ключевых — производительность решения, включая скорость копирования, нагрузку на сеть и потребление вычислительных ресурсов хранилища и источника данных. Инженеры компаний YADRO и Киберпротект протестировали совместную работу системы резервного копирования Кибер Бэкап и системы хранения данных TATLIN.BACKUP в трех сценариях сохранения резервных копий виртуальных машин: с inline-дедупликацией, по протоколу NFS и агентом Tboost на узле хранения. Поделимся результатами тестирования совместимого решения, а заодно предметно поговорим об организации правильной архитектуры с учетом особенностей конкретной инфраструктуры.

https://habr.com/ru/companies/yadro/articles/899074/

#схд #дедупликация #тестирование #срк #резервное_копирование #виртуальные_машины #vmware

Как создать дедуплицирующую файловую систему с нуля? Опыт TATLIN.BACKUP

Как сделать высоконагруженную систему хранения данных в сжатые сроки? Чтобы она не падала через день, не теряла данные и не поглощала ресурсы, как Гулливер провизию в амбаре лилипутов. А еще нужно реализовать дедупликацию и заложить будущий функционал на этапе создания архитектуры. Неплохо бы и стоимость хранения гигабайта снизить до минимума, а скорость передачи данных наоборот, увеличить до второй космической. Меня зовут Ростислав, я эксперт по разработке ПО отдела систем обработки данных в YADRO. Расскажу о вкладе нашей команды в разработку TATLIN.BACKUP: как мы с нуля создали дедуплицирующую файловую систему, а также какие вызовы преодолели за два года разработки и 200 тысяч строк кода.

https://habr.com/ru/companies/yadro/articles/895058/

#дедупликация #rust #СХД #FUSE #nfs #smb #срк

Аварийное восстановление СРК: стратегии, план и кейс

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

https://habr.com/ru/companies/trinity/articles/856152/

#срк #система_резервного_копирования #бэкап #аварийное_восстановление #тринити #российское_по #отечественное_по #импортозамещение #российские_серверы #российский_софт

Какая-то система СРК у нас стоит, но правильно ли она работает?

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

https://habr.com/ru/companies/trinity/articles/842978/

#срк #бэкапирование #бэкап #система_резервного_копирования #тринити #отечественный_софт #отечественное_по #российский_софт #российский_рынок #сервер

Инструкция по грамотному развёртыванию бэкапов на предприятии

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

https://habr.com/ru/companies/trinity/articles/818673/

#тринити #бэкапы #бэкапирование #резервное_копирование #резервное_копирование_данных #бэкап #инструкция #срк #данные #система_резервного_копирования

Тестируем СХД ExaGrid EX18: получилось ли заменить Dell DataDomain и HPE StoreOnce?

Привет, Хабр! На связи Алексей Зотов из К2Тех, и у меня для вас свежий обзор на железо. Сегодня пришла очередь СХД для бэкапов от ExaGrid — это продукт с продвинутым функционалом дедупликации на хранилище и отдельной фишкой в виде удивительно большого кэша. Под катом вас ждут первое впечатление, результаты тестирования и выводы об этой системе.

https://habr.com/ru/companies/k2tech/articles/779162/

#система_хранения_данных #схд #система_резервного_копирования #срк #бэкап #тестирование #exagrid #vinchin #кибер_бэкап #veeam

Как не провалить аудит в новых условиях?

Время от времени компании проводят аудит. Это комплексный взгляд на ИТ-инфраструктуру и варианты ее развития. Когда чаще всего проводят аудит? — Непонятна картина реального состояния ИТ-инфраструктуры. Такая ситуация может возникнуть, например, при смене руководства или уходе/замене ключевых сотрудников. — Общее состояние ИТ-инфраструктуры с точки зрения бизнеса «какое-то не такое». Слишком большие расходы, частые инциденты, нарушение SLA. — Впереди большой проект (например, назревшая замена CRM) и вопросов пока больше, чем ответов (на что, как, поможет ли). Аудит должен ответить на главные вопросы: — Как выглядит реальная картина ИТ? — Какие есть проблемы и узкие места в инфраструктуре? К этим вопросам добавилась и тема перехода на российские решения. Многие существующие продукты невозможно заменить «один к одному». Важно определить, какой функционал используется, какой висит мертвым грузом, а от чего можно отказаться. В этом посте мы пройдемся по ключевым блокам, которые должны быть включены в аудит ИТ-инфраструктуры, и основным доступным сейчас инструментам.

https://habr.com/ru/companies/jetinfosystems/articles/778772/

#аудит #российское_по #виртуализация #схд #срк #инфраструктура