proNovell

Имеется сервер FS1 с NW65. Хочу сделать резервирование данных сервера. Рассматриваю 2 варианта:
1. в это же дерево ставится вторая машина FS2 с NW65, которая будет использоваться как резервный сервер. Настраивается что-то вроде RSYNC: данные со всех томов (кроме SYS) FS1 сливаются на такие же тома на FS2 примерно раз в сутки. В случае выхода из строя FS1 юзеры просто логинятся на FS2.
2. на виндосовской машине настраивается опять же что-то вроде RSYNC. На эту машину сливаются все тома, образ тома SYS катается с рабочего сервера. В случае завала FS1 образ вновь разворачивается, содержимое томов обратно заливается.

В связи с этим есть несколько вопросов:
1. Подскажите, какими продуктами лучше пользоваться для организации резервирования?
2. Есть ли продукты, которые поддерживают резервирование в режиме online (т.е. любые изменения на FS1 немедленно отражаются на FS2)
3. Если придется катать образ тома SYS, то чем лучше это делать?
4. Где можно почитать про резервирование данных на Netware? Возможно, есть где-то обзор, сравнение таковых продуктов?

Буду признателен за любые ссылки. Приоритет будет отдаваться бесплатным реализациям, т.к. контора не шибко богатая.

Гм. У вас же 6.5 версия. А там бесплатная лицензия на двухнодовый кластер.

В принципе, NCPSync копирует файлы с сервера на сервер не хуже RSync. Права с помощью trustee.nlm сохраняются (и восстанавливаются).
Для копирования на рабочую станцию можно использовать NNBackup. Образ загрузочного раздела и тома SYS - чем угодно (я привык к Acronis'у).
Когда решение типа кластер не возможно, тогда именно такой вариант становится предпочтительным.

Timur Kazimirov писал(а):Гм. У вас же 6.5 версия. А там бесплатная лицензия на двухнодовый кластер.

Это немного не то. Автор темы спрашивал про резервирование данных, а именно этого кластер не далает. Он делает резервирование сервера, данные же при этом должны храниться на внешнем массиве (который и заботится об их сохранности).

bgInner писал(а):1. в это же дерево ставится вторая машина FS2 с NW65, которая будет использоваться как резервный сервер. Настраивается что-то вроде RSYNC: данные со всех томов (кроме SYS) FS1 сливаются на такие же тома на FS2 примерно раз в сутки. В случае выхода из строя FS1 юзеры просто логинятся на FS2.

Не очень удачно е решение, ИМНО.
Во первых , с т.з. экономики: всё окружение второго сервера будет простаивать. Жалко.
Опять же - будет он просто пережигать электричество. Очень жалко.

И кроме того - вот так взять и "переключиться" в сети NW проблематично: вы же логинитесь сразу во всю сеть, а не к конкретному серверу.

Значит, при аварийном переходе на другую машину вам придётся как минимум правать мапы в процедуре регистрации ( если сервера в одном Дереве) или подставлять пользователям другое Дерево , если Деревьев у вас будет 2.

При это надо ещё подумать, как сделать, чтобы при работе в штатном режиме никого в это другое Дерево на занесло ненароком... иначе половина ваших прямоходящих будет работать с данными в спервого сервера, а поовина - ас данными со второго...

Потому я бы второй сервер не ставил...
Другое дело, что в рамках этой идеи более оптимально по деньгам и всему прочему использовать какое-нибудь хранилище (NAS??) соотв. объёма и надёжности.

И иметь чёткий регламент восстановления сервера при его аппаратном сбое.

1. Подскажите, какими продуктами лучше пользоваться для организации резервирования?

У каждого он свой, обычно... Для малых сетей ( пару-тройку серверо) очень хорошо подходит ANCHORA.
Мало того, что может на МЛ, так может и синхронизировать разово или по крону.

На ФАЙЛАХ лежит инструкция, описание.
Понравиться - телефонируйте.( только 14-30 отпуск)

2. Есть ли продукты, которые поддерживают резервирование в режиме online (т.е. любые изменения на FS1 немедленно отражаются на FS2)

Есть, наверное... Но очень дорого.

3. Если придется катать образ тома SYS, то чем лучше это делать?

Portlosk Storage Manager

4. Где можно почитать про резервирование данных на Netware? Возможно, есть где-то обзор, сравнение таковых продуктов?

Принципы резервирования - они и в А принципы: примите для себя схему, периодичность и тд...
ПРичём не только архивирования, но и восстановления штатного и аврийного. А чем делать - это вы можете подбирать не спеша, пробуя программы.

Сравнение же нонешних бакапных монстров вам ничего не даст.
Вы же не владеете сотнями тер информации, пулом накопителей в десятки разномастных стримеров, десятками серверов и тд.?

А они как раз стараются в этом друг друга перещеголять...

Опять же - какое у вас окно бакапа? при непрерывном произ. цикле - это будут одни деньги ( как плата за скорость) , а при тривиальном рабочем дне - другие скорости и как следствие - др. деньги.

Потому ещё раз обращу ваше внимание на упомянутую программу. При наличии унитарного стримера или пары серверов она отлично ложиться на небогатую инфраструктуру.

Музалёв Николай писал(а):
bgInner писал(а):1. в это же дерево ставится вторая машина FS2 с NW65, которая будет использоваться как резервный сервер. Настраивается что-то вроде RSYNC: данные со всех томов (кроме SYS) FS1 сливаются на такие же тома на FS2 примерно раз в сутки. В случае выхода из строя FS1 юзеры просто логинятся на FS2.

Не очень удачно е решение, ИМНО.
Во первых , с т.з. экономики: всё окружение второго сервера будет простаивать. Жалко.
Опять же - будет он просто пережигать электричество. Очень жалко.

Когда придет пора (не дай Бог) переходить на резервный сервер - кучу нервов сэкономишь. Есть опыт. То, что я описал, меня спасало и уже не раз. А мапы в логин-скрипте переделать - секунд 15, если запущены фар и nwadmin (C1, iManager). Еще 10 секунд на запуск trustee restore. А нервы - это не права и не данные, фиг восстановишь.

И кроме того - вот так взять и "переключиться" в сети NW проблематично: вы же логинитесь сразу во всю сеть, а не к конкретному серверу.
Значит, при аварийном переходе на другую машину вам придётся как минимум правать мапы в процедуре регистрации ( если сервера в одном Дереве) или подставлять пользователям другое Дерево , если Деревьев у вас будет 2.

Ёлы-палы, я мапы совсем из виду упустил. А у меня кроме общего скрипта есть еще у каждого пользователя логин-скрипт, в котором мапы прописываются. Пользователей около сотни. Засада. Не так все просто. А есть ли утилита в природе для пакетного изменения атрибутов пользователей (в частности, логин-скриптов)?

При это надо ещё подумать, как сделать, чтобы при работе в штатном режиме никого в это другое Дерево на занесло ненароком... иначе половина ваших прямоходящих будет работать с данными в спервого сервера, а поовина - ас данными со второго...

И про это я не подумал. В принципе, можно принудительно права отобрать на просмотр/чтение томов, с которыми пользователи работать (должны) будут

Другое дело, что в рамках этой идеи более оптимально по деньгам и всему прочему использовать какое-нибудь хранилище (NAS??) соотв. объёма и надёжности.

Я рассматривал эту идею, но для фирмы крайне важна, кроме сохранности данных всех пользователей, еще и непрерывная работа. Кроме того, в случае использования NAS: как будет видеться этот NAS из-под Novell? (прошу прощения за дилетантский вопрос, но я с NAS знаком только на уровне газетных статей)

Опять же - какое у вас окно бакапа? при непрерывном произ. цикле - это будут одни деньги ( как плата за скорость) , а при тривиальном рабочем дне - другие скорости и как следствие - др. деньги.

можно сказать, 16-часовой рабочий день

vasya_r писал(а):В принципе, NCPSync копирует файлы с сервера на сервер не хуже RSync. Права с помощью trustee.nlm сохраняются (и восстанавливаются).
Для копирования на рабочую станцию можно использовать NNBackup. Образ загрузочного раздела и тома SYS - чем угодно (я привык к Acronis'у).
Когда решение типа кластер не возможно, тогда именно такой вариант становится предпочтительным.

Вася, я изначально хотел использовать NCPsync, но знакомые ребята сказали, что у него есть глюк с копированием, если в одной папке есть файл и папка с одинаковым именем. Сам не проверял. Пока не проверял. попользуюсь RSYNC-ом, если не понравится - займусь NCPSYNC-ом. В данный момент уже настроил RSYNC 2.6.0 , пробую в тестовом режиме запускать.

А где можно почитать про решение типа кластер ? Забегая вперед: в качестве резервного сервера (на время восстановления основного сервера) планирую использовать не серверную платформу, а обычную рабочую станцию (ну, нет у конторы денег. Пока, по крайней мере). Кластер станет на такую несимметричную конструкцию?

С переделвыением мапов есть очень простой вариант: на тома в дереве создаются ссылки на существуюшщие тома, и по этим ссылкам уже делаются мапы. При необходимости ссылки удаляются и создаются с таким же названием на резервные тома.
P.S. А вообще помимо бэкпапа действительно делается кластер из двух нод и берется 2 массива, на которых создается программное зеркало(между массивами) для обеспечения непрервывности.

bgInner писал(а):Ёлы-палы, я мапы совсем из виду упустил. А у меня кроме общего скрипта есть еще у каждого пользователя логин-скрипт, в котором мапы прописываются. Пользователей около сотни. Засада. Не так все просто. А есть ли утилита в природе для пакетного изменения атрибутов пользователей (в частности, логин-скриптов)?

Есть их. Напр nwadmin

viewtopic.php?f=1&t=10927
Если изменяются мапы, рекомендую такую штуку как объект дерева directory map.

Владимир Горяев писал(а):
bgInner писал(а):Ёлы-палы, я мапы совсем из виду упустил. А у меня кроме общего скрипта есть еще у каждого пользователя логин-скрипт, в котором мапы прописываются. Пользователей около сотни. Засада. Не так все просто. А есть ли утилита в природе для пакетного изменения атрибутов пользователей (в частности, логин-скриптов)?
Есть их. Напр nwadmin

Владимир, насколько я знаю, nwadmin не делает пакетного изменения скриптов.

viewtopic.php?f=1&t=10927
Если изменяются мапы, рекомендую такую штуку как объект дерева directory map.

to Solomin, Владимир Горяев:
Directory Map в моем случае - то, что нужно! Спасибо за ссылку.

bgInner писал(а):Владимир, насколько я знаю, nwadmin не делает пакетного изменения скриптов.
viewtopic.php?f=1&t=10927

Владимир Горяев писал(а):
$erg писал(а):Это все понятно, но то что есть - осталось по наследству, и субАдмины в том числе.
Если бы я все делал с нуля - то сделал бы все совершенно иначе. Но хотелось бы навести порядок.(
не вижу проблем.
сделай единый профиль для всех пользователей
очисть контейнерные и пользовательские проц.рег.
в nwadmin напр, раскрой все контейнеры выдели всех пользователей, далее "объект/инф о неск польз" и в процедуру рег вбить любую команду, напр map root off.
и соотв получишь единую процедуру регистрации для всех.

Можно сделать в скрипте переменную, Которую мы будем задавать постоянно руками при помощи файликов с содержимым: SET SERV="FS1" .
Пример:
TEMP set FS = "%FILE_SERVER"
MAP ROOT S16:=Z:=FS1\SYS:PUBLIC
include z:\perehod.txt
include FS2\SYS:\PUBLIC\perehod.txt

IF "%SERV"="FS1" THEN
SET FS = "FS1"
ELSE
IF "%SERV"="FS2" THEN
SET FS = "FS2"
WRITE "Внимание вы работаете на резервном сервере FS2."
PAUSE
FIRE 3
END
END

Далее мапим диски:
MAP ROOT S16:=Z:=%<FS>\SYS:\PUBLIC
и т.п.
Получается что при выходе из строя основного сервера FS1, z:\perehod.txt будет недоступен и нам необходимо в FS2\SYS:\PUBLIC\perehod.txt изменить запись с "SET SERV="FS1" на "SET SERV="FS2", а т.к. 2 сервера у нас идентичны по структурам каталогов и правам - после перезагрузки рабочих станций пользователи заметят только "Внимание вы работаете на резервном сервере.", паузу и 3 раза пикнет спикер, а все остальное будет так как было.
Вроде бы правильно скрипт написал.

bgInner писал(а):
Другое дело, что в рамках этой идеи более оптимально по деньгам и всему прочему использовать какое-нибудь хранилище (NAS??) соотв. объёма и надёжности.

Я рассматривал эту идею, но для фирмы крайне важна, кроме сохранности данных всех пользователей, еще и непрерывная работа. Кроме того, в случае использования NAS: как будет видеться этот NAS из-под Novell? (прошу прощения за дилетантский вопрос, но я с NAS знаком только на уровне газетных статей)

Многие NAS поддерживают iSCSI.
В NW подкл к нему просто:
ion
iscsinit connect addr_storage

вдогонку про iSCSI

Павел Гарбар писал(а):На обоих серверах поднять iSCSI source и target и зазеркалить нужные разделы на другой сервер. Идея не моя, но на стенде проверял - работает.

Павел Гарбар писал(а):Зеркалятся блоки разделов, а не файлы, так что все равно открыты файлы или нет - пошла запись из буфера на диск - пишется на все диски зеркала (их может быть до 8 штук).
Зеркалятся обычно локальные диски, но с NSS можно проделать одну хитрую штуку - сделать iSCSI раздел на другом сервере и подключить его как iSCSI-диск к первому серверу. Но тут сами прикидывайте - справится ли сетевая карта. По выделенному гигабиту может прокачать. Я такое показывал и на 10 мбит/с стенде.

proNovell

Резервирование данных - чем воспользоваться?

Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

Re: Резервирование данных - чем воспользоваться?

вдогонку про iSCSI