Страница 1 из 2

Поделитесь опытом организации резервного копирования

СообщениеДобавлено: 27 июл 2002, 16:15
Alexandr Shamanov
Сейчас я копирую свою NW51 на HP DAT24e с помощью sbcon.
В случае аварийной ситуации(полетел винт) мне придется получается заново инсталлировать сервер с СD а потом уже восстанавливаться с ленты.

Не очень удобно. а главное долго!

У моего стриммера есть функция ODBR, но у меня не работает: то ли аппаратура не поддерживает, а скорее всего стандартные средства нетвари (sbcon) не дают мне грузиться с ленты.

Поделитесь опытом те, кто исп. ODBR или может быть есть что-то иное что позволит мне ускорить восстановление после краха системы
Естественно зеркалирование или RAID тут не рассматриваются, меня интересует работа с лентой!
Спасибо всем.

СообщениеДобавлено: 29 июл 2002, 11:19
Музалёв Николай
Александр, вы затронули тему , которая "вот такой высоты вот такой ширины" - в 2ва слова тут не получится. В качестве теории: вы должны решить для себя и своих пользователей "цену" информации и исходя из этого опроеделить те затраты - $$ и времени на коприование-которые вы согласны нести. Это раз. Далее Вы должны элементарно структурировать информацию по важности. Покмере по томам. То , что важно-бакапят чаще, это очевидно.
Тему будем продолжать, но в качестве уже практического подхода -посмотрите тему о копировании Дерева "подручными средствами" .

СообщениеДобавлено: 29 июл 2002, 17:00
Alexandr Shamanov
Спасибо за ответ Николай.
Я описал свою теперяшнюю ситуацию - бакапирование происходит стандартными средствами Novell, а в случае краха системы, получается так что нужно сначала инсталлировать сервер с нуля, а затем переписывать ту же систему но уже со стриммера.

А услышать хотел услышать кто, как у себя решает задачу даже не бакапирования, а восстановления в кратчайшие сроки (и за минимальные вложения)

А что касается частоты копирования: Лично я раз в месяц делаю полный бакап, и еженочно дифференциальный.

СообщениеДобавлено: 29 июл 2002, 20:02
Музалёв Николай
Не знаю. насколько вам покажется интересной моя сказка про грей буля, но вот слушайте.
Для аврийного восстановления умные люди советуют примерно следующее:
1-разложить по "полочкам" и задокументировать все носители дистрибутивов. Если есть какое писало-сделать копии. Держать на носителях и тоже элементарно документировать все обновления, патчи, добавочные модули и тд. Особое внимание обратить на те случаи, когда в одной версии исп. модули из другой-такое иногда.
2-со временем накапливаются свои\чужие NCF-файлы. Их обязательно следует или распечатывать в инж.журнал или тоже архивировать. Актуально, если подбирались хитрые запускающие для какого либо устройства-тот же стриммер, например.
3-если есть чем, то следует снять ВСЕ!! SET-параметры. По зрелому изысканию их гораздо больше, чем мы привыкли видеть по команде.
Кстати, ARCSERV дает практически проный перечень SET-параметров.
4-копирование Дерева. Часто это бывает важнее фсистемы. Копирование обязательно перед КАЖДЫМ экспереиментом или запуском чего либо, что модифицирует схему.
5-вы будете смеяться, но следует иметь ПЛАН восстановления. Не поленитесь. Дай Бог он никогда не пригодиться. но уж если слетит серьезно-то как найдете. Сам думал, что это пустое, КАК Я ОШИБАЛСЯ!!!
Как видите - первая половина-приктически только ОРГАНИЗАЦИОННЫЕ меры. Не следует ими пренебрегать.
=============================
Теперь что касается программных средств. Их достаточно много. Для средних предприятий и гетерогенных сетей с НВ, НТ, ЮНХ рекомендуют BACUP Exe или ARCSERv. Укого денег не клюют -LEGATO. Или же наоборот, что попроще и подешевле - тот же ПОРТОКЛ, например. Можно делать копии на МЛ, у кого диски немеряные-копию на Н-диск или на МО.
Моя печальная практика была такой:
-Систему восстанавливали с дистрибутива
-Тоже со всеми патчами и с добавкой своих наработок. Время минимальное
-Дерево восстановили с ФАЙЛОВОЙ копии и "подровняли" вручную(не было бы счастья...убрали всяческую накипь за 5 лет)
-Опекунские назначения на файлы восстановили с пом. собственной программы.
-Потом прогнали DSREPAIR и утерли пот.
На все-провсе ушло примерно 8 часов (5 часов восстановление с МЛ)
Что касается инкркментного и дифференциального методов, то ИМНО-это изврат для мазохистов: когда такой стресс, ручки дрожат, ножки не держат, дым идет нне только оттудова, но и из других... ("он начал суетиться, как однорукий человек в крапивной лихорадке, когда он клеит обои" (С)ОГенри)
В общем, некогда разбираться с копиями и версиями. Я сторонник полных копий.
Ну вот так. Если что заинтересовало-телеграфируйте.

СообщениеДобавлено: 30 июл 2002, 11:44
Алексей Соловьянов
Alexandr Shamanov писал(а):Спасибо за ответ Николай.
А что касается частоты копирования: Лично я раз в месяц делаю полный бакап, и еженочно дифференциальный.


И что, Вы уверены, что это сохранит Ваши данные? Вероятность отказа одной ленты весьма прилична. И если умрет в конце месяца месячный полный бекап, то актуальность Ваших данных будет равна предыдущему месяцу. Раз в неделю делать полный бекап - это еще можно понять. Но все равно для восстановления нужно две ленты. Соответственно, время подъема увеличивается.

СообщениеДобавлено: 30 июл 2002, 13:08
Музалёв Николай
Да , 2ве ленты- обязательно , но только на предмет отказа (замятия, осыпи или ещеч). Время восст. останется = времени работы одной мл.

СообщениеДобавлено: 30 июл 2002, 16:25
Alexandr Shamanov
Конечно чем больше копий тем лучше, однако учитывая что емкость ленты всего около 17Gb (DDS3) то полный бакап у меня растягивается не на одну ночь. А если еще и дублировать...
Кстати я (тьфу-тьфу) пока на ленточки не жалуюсь, хотя и приходилось уже прибегать и к такому виду восстановления.
Кстати именно по причине малой емкости лент и выбран способ Full + Diff, потому как на одну ленту у меня сразу несколько дифференциальных бакапов помещается. А для восстановления понадобятся последний полный и последний дифференциальный - еще по божески.

NDS тоже записываю на ленту. думаю, что если на свеже инсталлированный сервер залить его вместе с файловой системой то все будет тип топ, и DSREPAIR не понадобится.

Насчет Плана восстановления согласен полностью - в стрессовой ситуации можно наделать кучу глупостей и усугубить положение. Уж лучше по плану. Наверное устрою на днях образцово-показательное падение и восстановление тестового сервера.

А про Set параметры не совсем понял - есть же значения по умолчанию, а изменения присутствуют или в autoexec.ncf или startup.ncf . Т.е. восстановив эти файлы получим сервер с теми же параметрами что и был. Хотя autoexec и startup распечатаны и подшиты - но это на случай если сделаю какие-то изменения параметров и станет хуже.

СообщениеДобавлено: 30 июл 2002, 19:42
Музалёв Николай
ПРО SETы
Имелось ввиду, что существует значительно больше SET параметров, чем принято считать. Наш БольшойБратец, в великой мудрости своей, не показывает их все простым админам. (может кто из CNE илии Мастеров их все и знает....) Дык вот. В процессе скажем так. НЕГЛАДКОЙ установки иногда знающие их модифицируют и система нормально ставится. Как правило наш брат это нигде не записывает и благопол. забывает. А когда через Н-лет происходит свал, то сервер восст, все вроде ОК, а он не едет, тк просто забыли какуюто специф. мелочь правильно указать.
Про МЛ
А я делаю 2ве копии. разнесенные на сутки-сначала основную копию, а завтра-её дубль. Не самое, конечно, но вполне пригодно, если в 1ну ночь не укладываетесь. И с таким расхождением можно мириться.
Кстати, отсюда и совет оазделить инф. на 2ру-3ку частей. Напрмер, то,что не меняется месяцами и , скажем, рабочие наборы пользователей. Их копирую чаще, как можно.

Как это делается у нас

СообщениеДобавлено: 31 июл 2002, 07:57
Елена Лезгина
Целиком и полностью согласна с Николаем Музалевым по поводу орг. подготовительных мероприятий при рез. копировании. У нас тоже есть и утвержденная схема рез.копирования, и план аварийного восстановления. Это, я считаю, нормально для больших контор, когда время восстановления очень критично, и простой сервера возможен не более нескольких часов.
Мы используем ARCserve for Netware Ent. Edition и, конечно, не единичные ленты (объем данных не позволяет), а ауточейнджеры.
В ARCserve есть функция "зеркалирования" томов или каталогов, вот с ее помощью мы наиболее важные пользовательские данные "зеркалируем" на резервный сервер, в случае краха основного его диски смапим, и все основные сетевые задачи будут работать. На ленты делаем бэкап раз в неделю (храним 4 копии недельные) и раз в месяц (храним 3 мес. копии). Поверьте, приходилось их использовать, когда некий юзер вдруг вспоминает, что что-то он там поменял или удалил и хочет восстановить, как оно было 2 месяца назад.
Что касается бэкапа NDS - если у вас в дереве не один сервер, то актуальность бэкапа NDS на МЛ теряется (есть реплики), но мы все же честно его делаем раз в месяц.
Насчет быстрого восстановления всего сервера - в ARCserve есть опция Disaster Recovery Option, вот тогда вам не придется ничего инсталлировать, все восстановится с набора дискет и последнего полного бэкапа.
И напоследок - я тоже не сторонник инкрементных бэкапов - это извращение и дополнительная головная боль. Только разделение данных по важности и полный бэкап, но с разной периодичностью.

СообщениеДобавлено: 31 июл 2002, 08:52
Павел Орлов aka XerX
Хотел бы не согласиться с бесполезностью бэкапа дерева.
Да, есть реплики. Но при изменении схемы... реплики изменятся в свою очередь. А это может привести к печальным последствиям.

И добавлю для информации как все это делается у нас.
DDS3. ArcServeIT 6.6. Раз в неделю фул бэкап (причем фул он относительный - бэкапятся ТОЛЬКО юзерские данные). Ни один том сис не бэкапится. Каждый день инкриментал.
Бэкапятся ТОЛЬКО новелевские серваки (все н-тевые и юниксовые серваки НЕ бэкапятся). Все БД лежат на нетвари. А юзерам строго-настрого сказано - если хотите чтобы у вас что-то восстановилось - сохраняйте свои данные на сетевых томах. Т.О. экономится место на ленте (за ночь сделаться бэкап (инкриментал) успевает). ФУЛЛ делается в ночь пятницы на субботу. и занимает 2 ленты.
Ежемесячный бэкап. Ежегодный бэкап. (я СЕЙЧАС могу привести все к тому виду который был 4 года назад)

СообщениеДобавлено: 31 июл 2002, 10:14
Федорович Леонид
Про бекап дерева. Обязательно! Был прецедент. Выкрутились только за счет того, что один из серверов был оторван от сети и не получил изменений.
Используем ArcserveIT 2000 с DDS3 и автозагрузчиком. Мне не очень нравится, но этой системой занимаюсь не я.
По поводу Disaster Recovery. Нужно проверять на тестовых серверах аналогичной настройки. Может не восстанавливаться служебный раздел (есть на HP). У меня такое было.
По поводу документирования. Еще нужен документ, подписанный всеми начальниками, что бекапить и как часто. Иначе возможны конфликты. (типа восстановили базы а конфигурационные файлы не бекапились).

СообщениеДобавлено: 31 июл 2002, 10:46
Музалёв Николай
ОФФТОП-интересное кино у нас, господа админы! На моей памяти это едва ли не единственныя серьезная тема, в которой господа админы не грызутся и практически солидарны дсдругом.
ОНТОП-В продолжении темы бакапа Дерева. Согласен с коллегой-реплики не спасут в результате ЛОГИЧЕСКОГО разрушения информации.
Пример от себя. Арксерв при инсталл. создает 2ва биндери объекта - сервер бакапа и очередь бакапа. В процессе установки они модерниз. до NDS объектов, а биндери, по уму, должны были удал., но не удалились. Я не поразмыслил и снес их не в том порядке (надо сервер, потом очередь). Дык вот, 1н объект удален норм., а удаление 2го зависло-идет и идет и идет... И ничем не прибить это свинство. И ничего др. делать в Дереве не дает:пишет , вот закончу удаление, дык тогда уж... Я - к БольшомуБрату. А братцы-новелы отчибучили такое, что хоть стой, хоть падай:"присоедини сервер к Сети. Мы(!!) на него зайдем сами, посмотрим, что у тебя в Дереве и тогда решим как исправить. Срок 5ть(!!!) дней....". Ну спасибо, родные-не дали пропасть...
Пришлось брать именно файловфй вариант восстановления. Было страшновато по 1му разу, но ничего-3' хирургии-и больной здоров.

Согласна :)

СообщениеДобавлено: 31 июл 2002, 12:01
Елена Лезгина
Насчет бэкапа дерева на случай его краха из-за изменений схему, внесенной каким-либо пакетом, я согласна на все 100. Вот мы и делаем его тоже на всякий случай. Я имела в виду, когда сказала про реплики, что они помогут, если просто грохнется локальная база на одном из серверов. Неточно выразилась.
А про документ, подписанный у начальства, это правильно. У нас таких даже несколько: 1)утвержденная схема резервного копирования(что, когда и по скольку копий хранить) - были прецеденты с пользователями, на что им документ покажешь, мол, сами не просили чаще. 2) план восстановления в случае сбоя (сколько времени займет и что в первую очередь). Регулярно раз в год выпускаем тех.справку про изменения схемы резервного копирования с выводами (какие объемы, на сколько лент). Это хорошо еще и потому, что начальство наглядно видит возрастающие нужды, помнит, что надо МЛ прикупить, да и чейнджер бы еще один неплохо :))

СообщениеДобавлено: 01 авг 2002, 03:49
Андрей Тр. aka RH
Уж не знаю, писать или не писать сюда .. :) почитал - аж страшно. До нормального бэкапа руки, как всегда, не доходят ( да и на другое деньги тоже нужны ). Всвязи с этим вот какой вопрос.

Где-то с год лежал на полочке стример Hornet от Seagate ( больше известный как Travan - когда идет в комплекте с софтом; емкость 10/20Гб ). Главная проблема с ним - что он IDE, а не SCSI. Попытки ( без особой надежды, впрочем ) заставить его работать под 5.1 завершились .. хм .. с отрицательным результатом.

И тут было на днях свободное время, и я его засунул в свой Acer под WinXP. Все заработало сразу и "на ура". В течение пары часов был готов бэкап моей станции с recovery дискеткой. А теперь, собсно, вопрос. Есть ли решения по бэкапированию Netware ( NDS, ФС ) на стриммер на станции ? Обратное, ясное дело, достижимо ( агента поставил и вперед ). Понятно, что сие несколько противоречит самой концепции, но .. лучше что-то, чем ничего.

СообщениеДобавлено: 01 авг 2002, 12:12
Музалёв Николай
Ответ на предмет бакапа со станции
Да, я прпобовал. После покупки нового стриммера остался старенький, TANDBERG 4220 на 2ГБ(правда, он SCSI). Дык вот, встал он на НТ тоже хорошо и после подключения к сети можно было перекачивать на него с сетевых дисков как с локальных и также с сетевых от ргруппы. Но только ФСИСТЕМУ. Скорость его и емкость к тому моменту, а также узкий кабель -10ка- не дали такому решению никаких преференций перед централизованным копированием сервера и всю музыку передали в одну обособленную ргруппу.
PS АНДРЕЮ Тр
Андрей, а что вас испугало?
почитал - аж страшно.
Мы наговорили ужасных ужасов?
PSS Мальчики, научите безрукого вставлять цитаты, аж неудобно...