Форум Тринити

Открытый технический форум по серверам и системам хранения данных, кластерным решениям, SAN, NAS.
Microsemi infortrend storage
Текущее время: 16 авг 2018, 12:28

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: 19 июн 2012, 12:40 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
kim_aa писал(а):
1) Backup Exec 2010|2010 R2|2010 R3 Hardware (HCL)
http://www.symantec.com/business/suppor ... 10_hcl.pdf

Смотрите "VSS Provider for Offhost backup" cтр. 39
Требование к версии Firmware не ниже "TS200R021"

2) К сожалению HP не балует документами на данную тему
Привожу пример для Dell. Отличия будут минимальны (если будут)
http://en.community.dell.com/cfs-file.a ... BE2010.pdf


Огромное спасибо за документы!
Все запустилось и заработало на тестовом томе. Осталось понять надо ли включать дедубликацию, компрессию и т.п. для SQL.
Теперь осталось только как-то пересобрать хранилище, так как на всех рабочих VDISK 100% отданы под VOLUME и нет места на рабочих VDISK под снэпшоты :(
Но это уже организационные мероприятия, они проще.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 июн 2012, 13:34 
Не в сети
Сотрудник Тринити
Сотрудник Тринити
Аватара пользователя

Зарегистрирован: 24 ноя 2011, 16:30
Сообщения: 120
Откуда: Санкт-Петербург
1) Спасибо хорошо, но интерестно получить реальные значения полученных выйгрышей.
Типа такого:
Модель хранилища=
Модель вторичного хранилища =
Модель сервера=
Приложение =
СУБД =
Размеры баз =
При стандартном Backup:
Размер резервной копии Full=
Размер резервной копии Inc=
Время затрачиваемое при стандартном Backup:
Full=
Inc=

При Offhost Backup:
Размер резервной копии Full=
Размер резервной копии Inc=

Время затрачиваемое при Offhost Backup:
Full=
Inc=

2) По поводу сжатия и дедупликации нужно понимать следующее:
а) В вашем случае эти операции нужно включать на стороне сервера BackupEXEC (BE)
б) Обе эти операции увеличат нагрузку на сервер BE, особенно дедупликация
в) Так как вы делаете полную копию часто, то дедупликация для вас будет очень эффективна (как минимум 7:1)
г) Эффективность сжатия может определить только эксперимент (Стандартный выйгрыш + 30%). Сжатие не оказывает влияние на дедупликацию и наоборот.
д) Сжатие практически не удлиняет операции backup/restore
е) Дедупликация обычно как минимум удваивает длительность операций backup/restore, правда в случае offhost backup это никак не влияет на сервер-клиент, т.е. удлиняются стадии обработки Вторичное Хранилище <-> Сервер резервного копирования
ж) Отказоустойчивость:
- Сжатие не ухудшает параметры отказоустойчивости резервных копий;
- Дедупликация ухудшает параметры отказоустойчивости резервных копий, т.к. появляется единая точка отказа - база дедупликации.
По этому рекомендуется делать недедуплицируемую копию хотя бы раз в месяц.
Или завести ленту, куда сбрасывать копии выходных (т.к. картридж LTO-4 сейчас стоит ~1000 руб, то долговременно хранить выгодно на ленте)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 июн 2012, 14:10 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
kim_aa писал(а):
1) Спасибо хорошо, но интерестно получить реальные значения полученных выйгрышей.
Типа такого:
Модель хранилища=
Модель вторичного хранилища =
Модель сервера=
Приложение =
СУБД =
Размеры баз =
При стандартном Backup:
Размер резервной копии Full=
Размер резервной копии Inc=
Время затрачиваемое при стандартном Backup:
Full=
Inc=

При Offhost Backup:
Размер резервной копии Full=
Размер резервной копии Inc=

Время затрачиваемое при Offhost Backup:
Full=
Inc=

2) По поводу сжатия и дедупликации нужно понимать следующее:
а) В вашем случае эти операции нужно включать на стороне сервера BackupEXEC (BE)
б) Обе эти операции увеличат нагрузку на сервер BE, особенно дедупликация
в) Так как вы делаете полную копию часто, то дедупликация для вас будет очень эффективна (как минимум 7:1)
г) Эффективность сжатия может определить только эксперимент (Стандартный выйгрыш + 30%). Сжатие не оказывает влияние на дедупликацию и наоборот.
д) Сжатие практически не удлиняет операции backup/restore
е) Дедупликация обычно как минимум удваивает длительность операций backup/restore, правда в случае offhost backup это никак не влияет на сервер-клиент, т.е. удлиняются стадии обработки Вторичное Хранилище <-> Сервер резервного копирования
ж) Отказоустойчивость:
- Сжатие не ухудшает параметры отказоустойчивости резервных копий;
- Дедупликация ухудшает параметры отказоустойчивости резервных копий, т.к. появляется единая точка отказа - база дедупликации.
По этому рекомендуется делать недедуплицируемую копию хотя бы раз в месяц.
Или завести ленту, куда сбрасывать копии выходных (т.к. картридж LTO-4 сейчас стоит ~1000 руб, то долговременно хранить выгодно на ленте)


Хорошо, я постараюсь Вам ответить, но это к сожалению будет минимум через 3-4 недели, когда выйдем на рабочий график бэкапов и переделаем хранилище.
Типа такого:
Модель хранилища= HP MSA P2000 G3 SAS
Модель вторичного хранилища = Adapteс 52445 + SATA RAID5 (2Tb x 16 шт ) + Intel S3420GP/Xeon х3450/8Гб RAM + Windows 2008R2 + Backup Exec 2010 R3
Модель сервера SQL= HP D380G6
Приложение = 1C 8.2
СУБД = MS SQL 2008 R2
Размеры баз = 20Гб (для тестовой базы), всего рабочих баз 2,5Тб

Сейчас я могу сказать только для тестовых данных (копия одной самой маленькой рабочей базы, размер 20Гб):
Full Backup 20Гб:
1) Несжатый, с сервера SQL, по сети 1Гб: ~15 минут
2) Сжатый сервером SQL, по сети 1Гб: ~7 минут (компрессия 6,8:1)
3) Сжатый сервером BE, по сети 1Гб: ~9 минут (компрессия 4,1:1)
4) Дедубликация, по сети 1Гб: ~9 минут (компрессия 5,9:1)
5) Offhost, несжатый, SAS 6Гбит: 01 минута 50 сек
6) Offhost, сжатый сервером BE, SAS 6Гбит: 04 минута 25 сек (компрессия 4,1:1)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 июн 2012, 14:41 
Не в сети
Advanced member

Зарегистрирован: 13 июл 2003, 10:01
Сообщения: 308
Откуда: Хабаровский край
reallord писал(а):
Это не совсем так... База не развалиться, но могут быть ситуации, когда в базе есть документы которые по бизнес-логике должны делать движения, но не делают их.
Или наоборот, могут быть документы которые делают движения, но не являются проведенными.

Ещё раз: за логическую целостность в этом случае отвечает приложение, а не субд. Ее забота записать то, что сказали и отрапортовать, что данные зафиксированны. Все.
reallord писал(а):
С другой стороны если база восстановлена из бэкапа, а он точно не содержит ВСЕХ данных, так как сделан все равно с какой-то периодичностью, то пару кривых проводок или ошибок это самое малое за что придется отвечать.

Для этого существует archivelog... тьфу full recover режим работы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 июн 2012, 14:44 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
ITER писал(а):
reallord писал(а):
Это не совсем так... База не развалиться, но могут быть ситуации, когда в базе есть документы которые по бизнес-логике должны делать движения, но не делают их.
Или наоборот, могут быть документы которые делают движения, но не являются проведенными.

Ещё раз: за логическую целостность в этом случае отвечает приложение, а не субд. Ее забота записать то, что сказали и отрапортовать, что данные зафиксированны. Все.
reallord писал(а):
С другой стороны если база восстановлена из бэкапа, а он точно не содержит ВСЕХ данных, так как сделан все равно с какой-то периодичностью, то пару кривых проводок или ошибок это самое малое за что придется отвечать.

Для этого существует archivelog... тьфу full recover режим работы.


А что значит full recover режим? Можно пару слов или ссылку?
Для меня "full recover" это только если есть mirroring sql сервера, причем синхронный...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 04:30 
Не в сети
Advanced member

Зарегистрирован: 13 июл 2003, 10:01
Сообщения: 308
Откуда: Хабаровский край
reallord писал(а):
А что значит full recover режим? Можно пару слов или ссылку?
Для меня "full recover" это только если есть mirroring sql сервера, причем синхронный...

Ну как он там в MS SQL называется: full recovery model. Смысл в том, чтобы не перетирать транзакционные логи, соотв-но потом можно восстановить базу на любой момент времени в прошлом, или до последней завершенной транзакции. Ну можно их ещё и миррорить суть от этого не меняется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 08:44 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
ITER писал(а):
reallord писал(а):
А что значит full recover режим? Можно пару слов или ссылку?
Для меня "full recover" это только если есть mirroring sql сервера, причем синхронный...

Ну как он там в MS SQL называется: full recovery model. Смысл в том, чтобы не перетирать транзакционные логи, соотв-но потом можно восстановить базу на любой момент времени в прошлом, или до последней завершенной транзакции. Ну можно их ещё и миррорить суть от этого не меняется.


Это все понятно. Мне реально бэкап нужен для случая, если выйдет из строя основной сервер с хранилищем.
Случая когда надо восстановить базу на какую-то конкретную транзакцию, ни разу в жизни не возникало.
Для разработчиков в 99% случаев достаточно ночной копии.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 09:11 
Не в сети
Advanced member

Зарегистрирован: 13 июл 2003, 10:01
Сообщения: 308
Откуда: Хабаровский край
reallord писал(а):

Это все понятно. Мне реально бэкап нужен для случая, если выйдет из строя основной сервер с хранилищем.

Так вот все реально для этого случая full recovery model и включают. Мы тут про промышленные базы говорим или про чо? Разработчики со своими песочницами пусть чо хотят то и делают, тьфу на них вообще .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 09:34 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
ITER писал(а):
reallord писал(а):

Это все понятно. Мне реально бэкап нужен для случая, если выйдет из строя основной сервер с хранилищем.

Так вот все реально для этого случая full recovery model и включают. Мы тут про промышленные базы говорим или про чо? Разработчики со своими песочницами пусть чо хотят то и делают, тьфу на них вообще .


Наверно я что-то недопонимаю...
Если навернулся основной сервер, то данные я поднимаю с бэкапа на резервный.
Данные мне нужны на сейчас, а бэкап был 30 минут назад.
Сервера нет, том с данными и логами разрушен, *.ldf отсутствует.
Чем тут поможет full recovery model?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 14:50 
Не в сети
Advanced member

Зарегистрирован: 13 июл 2003, 10:01
Сообщения: 308
Откуда: Хабаровский край
Честно говоря это уже начинает надоедать. Вы свой мирроринг применяете вместо или вместе с full recovery? Да и зачем вообще зеркалить базу разработчиков, которым пофиг на потерю полдня работы. Разговор ни о чем вообще.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 июн 2012, 15:01 
Не в сети
Junior member

Зарегистрирован: 14 июн 2012, 11:36
Сообщения: 17
Откуда: Нижний Новгород
ITER писал(а):
Честно говоря это уже начинает надоедать. Вы свой мирроринг применяете вместо или вместе с full recovery?

Если бы у меня был мироринг, тогда бы 100% стояла full recovery mode.
А у меня пока есть ТОЛЬКО бэкап несколько раз в день.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB