#срк — Public Fediverse posts

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

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

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

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

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

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

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

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

Третья копия — это хорошо. А где четвёртая, с блэкджеком и 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

Резервное копирование 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

Резервное копирование 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/

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

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

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

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

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

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

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

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 #срк #оркестрация #восстановление_данных

Неудобные вопросы про бэкап 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 #срк #оркестрация #восстановление_данных

Неудобные вопросы про бэкап 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/

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

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

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

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

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

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

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

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

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

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

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

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 #метрокластер #отказоустойчивость #массив #срк

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

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

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