Алексей Черемисин, я не парюсь, но когда я обратился на русскоязычный канал по СЕРНу мне сказали, что продукт не подойдет для решения данной задачи. Если вы знаете как, прошу описать сценарий по подробнее.
2,3. Вы правы и мысли как раз идут о синхронной репликации двух-трех схд с возможностью создания чекпойнтов. К сожалению решение "ненагуглилось", поэтому надеялся посмотреть успешный опыт коллег.
4. Мне кажется репликация СУБД не подойдет, так как внутри бд во время тестов переписываются множество таблиц. Исходя из этого, мне придется постоянно лить весь источник по окончанию тестов.
Думаем рассмотреть как резервный вариант репликацию между гипервизорами, согнав все сервисы в рамках одной машины. Но скорее всего мы получим проблемы в производительности, так как кол-во чекпойнтов будет расти на проде, пока не окончатся тесты на среде.
shurshur, дело в том, что это не тестовая среда в общепринятом смысле.
Чтобы немного абстрагироваться от систем, то можно описать процесс следующим образом:
1) Каждое утро есть определенный набор данных 1-2 тб (производство), на основании которых производится длительный расчет 1-3 часа.
2) Одновременно с этим, этот же набор данных разворачивается в нескольких средах и расчет производится с другими переменными.
3) Если по итогу рабочего дня выявлено более оптимальное решение, то на след. день используются новые переменные в расчетах.
Поэтому речь как раз о том, что "тестовый набор данных" каждый раз имеет новые значения.
Сергей Сахаров, ваша "проблема" давно уже решается обычным поисковым запросом.
Мне же необходимо не сортировка из Н кол-ва видео, а просмотр определенных кусков в рамках одного видео по тегам. И кол-во тегов (меток) на одном и том же интервале может быть много:
"01:00 - 01:10 - Анна
01:00 - 01:10 - Петр
01:00 - 01:10 - Ошибки Петра и Анны"
Прошу подсказать пример, где при открытии видео в ютуб:
1) При нажатии на метку получить "склеенный кусок" видео без необходимости постоянно прокликивания.
2) Указания двух меток на один и тот же интервал времени.
За информацию про hardened repository спасибо - интересно.
Но это не отвечает на вопрос о разделении доступов между резервными копиями из нескольких площадок. Т.е. получив атаку в один источник, будут скомпрометированы все резервные копии остальных площадок (не говоря уже о доступах к другим продам).
Если же поднимать отдельный РК для каждой площадки, то как я понял ВИМ не рекомендует подключение к одной ленточной библиотеке с нескольких серверов РК, так как могут быть ошибки.
Сталкивались с похожей проблемой.
Не могли подключить удаленный хост с ХВ на котором также располагалась хранилище.
Т.е. хост как сервер подключался без проблем, а хост как хв не хотел и выдавал аналогичные ошибки.
1) Обновите все хосты (MS)
2) Создайте локальную учетную запись администратора и попробуйте под ней подключить хост ХВ
3) Скорее всего он не сможет и тогдапопробуйте повторно подключить, но уже с BUILT-in администратором.
После этих танцов ХВ добавился и виделся также как сервер с репозиторием.
Ивор Барханский, видимо вы либо неправильно поняли поставленный вопрос, либо я что то не так указал.
В любом случаи решение в комментариях с моей стороной было указано.
Ивор Барханский, ну самый простой пример, если по каким то причинам вы локально запускаете установку нового программного обеспечения на рабочей станции под текущим доменным пользователем без прав администратора.
Alexey Dmitriev, агентный бекап показывает объем данных равный измененным - 500мб. Но данный вариант является проблемным, так как агентный бекап подразумеваем восстановление через bmr (bare metal recovery), что требует значительно больше времени.
Как я понимаю, мы имеем следующую картину:
1) В рамках первой р.к. создается avhd файл в котором происходят какие то изменения
2) По окончанию р.к. идет слияние снимка в vhd и cbt отмечает данные блоки как измененные, что в принципе верно.
Вопрос тут в сторону Hyper-v, что он пишет в vhdx за это время и как можно повлиять на его размер, если фактических данных в машине не меняется.
Ниже прошлый скриншот с агентным бекапом но включенным свопом:
