SZ
Т.к. ситуации когда нужно ресторить много данных (десятки тб) довольно часты.
Size: a a a
2019 October 16
EE
не знаю на счёт «зачастую», я такой кейс по-моему один раз всего видел и то не под все данные, а под конкретные БД
AB
теперь спокойно с hyper v to VMware?
EE
написано, что да. у меня к соажлению нет стенда на хайпер-в, что бы можно было самому попробовать
AB
это здорово.
AZ
теперь спокойно с hyper v to VMware?
можно и hyper-v и nutanix
AB
ну, нутаникса у нас нет)
AB
а hyper-v есть
AB
ну и в целом - это круто.
SZ
не знаю на счёт «зачастую», я такой кейс по-моему один раз всего видел и то не под все данные, а под конкретные БД
Зависит от окружения, точнее от объема, и времени за которое нужно вернуть все обратно. Среды миксованные, вмваря, физика (линукс, юникс), субд с рдм и т.п. ну и клиентов по разному, где суммарно 1000, где больше, где меньше
KK
А тоже самое, но в хайпер?
SZ
в основном с физики дата по fc, или 10 g. Если есть возможность, делается отдельно сеть под бакап, то это редкость
SZ
Хотя, был как-то случай, когда парни сдедали бакап сеть после того как поток бакапа (с друого сайта) положил чекпоинты основной площадки
EE
а ты в России? 🙂
SZ
а ты в России? 🙂
Ага
EE
ладно, потом по секрету расскажешь - где такие инсталляции, я видимо на каких то юродиевых постоянно натыкаюсь 🙁
SZ
ладно, потом по секрету расскажешь - где такие инсталляции, я видимо на каких то юродиевых постоянно натыкаюсь 🙁
в пределах NDA, конечно)
EE
просто на мой взгляд тут уже логичнее брать хранилку = продуктивной и делать реплику синхронную
EE
если мы хотим защититься от подения основной системы
SZ
просто на мой взгляд тут уже логичнее брать хранилку = продуктивной и делать реплику синхронную
реплика != бакап