none
SQL Server: corruption/disaster recovery - примеры реализации RRS feed

  • Общие обсуждения

  • SQL DBCC группа проводит исследование и, в связи с этим собирает примеры того, как различные компании реализуют Disaster Recovery планы и стратегии.
    Если вы уверены, что обладаете интересным решением в этой области и вам интересно рассказать о том, как ваша компания или вы эту задачу решили - давайте общаться
    2 марта 2007 г. 14:50

Все ответы

  • Есть в одном учреждении здравоохранения такой вот Disaster Recovery план.

    Исходные данные:

    Объём БД - до 1 Гб

    Конфигурация сервера - обычная клиентская машина, один процессор, один винчестер

    Количество клиентов - до 7-ми :)

    Приемлемая потеря данных - 2 дня (официально заверенная) :)))

    Recovery Model - Simple

    SQL2000

    Отсутствие какого-либа системного администратора в поликлинике, не имеют доступа в Интернет.

    Вывод - 1 раз в день под конец работы операторов full backup (ночью нельзя, т.к. сервер заботливо выключается!), к-рый с помощью xp_cmdshell и rar архивируется на той же клиентской машине (минимальная степень сжатия, продолжительность около 3-х минут) и скромные 100 Мб архива рассылаются ещё по 2-м машинам в сети. Падение одновременно 3-х винчестеров маловероятно. Поднять сервер на другой клиентской машине и настроить logshipping для них непозволительная роскошь. В случае падения винта - подъём последнего full-а из архива приезжающим мальчиком.

    Наврядли это можно назвать интересным решением, но пример из жизни

    5 марта 2007 г. 12:03
  • Плюсы - копирование на другие машины.

    Минусы - нет отслеживания неудачи в выполнении таска, хотя бы net send, раз интернета нет;

    неплохо бы добавить пароль на архив;

    падение трёх винтов действительно малореально, а вот битая копия на всех трёх машинах может получится легко. И тогда будет три копии, годных только для мусорной корзины. Предлагаю хотя бы раз в месяц кидать копию на dvd в архиве rar 3.* с паролем и отвозить в несгораемый сейф :)

    5 марта 2007 г. 14:14
  • Ну так я не стал так подробно расписывать:)

    Минусы - нет отслеживания неудачи в выполнении таска, хотя бы net send, раз интернета нет - нетсенды рассылаются всем операторам в случае падения джоба.

    неплохо бы добавить пароль на архив - WITH PASSWORD используем, куда же без него

    битая копия на всех трёх машинах может получится легко - архивы меньше 100 Мб весят (делаются каждый рабочий день - ок. 24 раз в месяц), поэтому хранятся в течении полугода (14 Гб). Удаляются вручную. Приблизительно раз в 2 месяца режутся на cd (dvd небюджетно для них:)

    5 марта 2007 г. 16:15
  • Господа, огромное спасибо то, что отреагировали.

    Мне понадобятся детали для дальнейшего общения с Progam Manager'ом, поэтому было бы неплохо, если б вы мне могли написать пару строк в почту ( адрес тут должен быть доступен).

    Еще  есть желаение поговорить со Штатами напрямую?

    5 марта 2007 г. 19:08
  • Мои две копейки (навеяно малобюджетным аварийным планом)

    Модель резервирования - полная - полночь. В файл, который в шифруемой EFS папке.

    В промежутках, ежечасное копирование журнала (в тот же файл).

    Естественно, резервируем сертефикаты...

    Поскольку шифрация EFS переносится на ленту, делаем копию на ленту средствами NTBACKUP. Описание задания и контроллирующего время работы NTBACKUP джоба (если зависнет - нужно его кильнуть) тут: http://msmvps.com/blogs/gladchenko/archive/2005/04/15/42299.aspx (вместо ленты там можно и по UNC копировать).

    Ленту можно перетаскивать (не особо беспокоясь за то, что украдут) в другие здания или класть в сейф. Степень защиты пригодна для данных, которые сравнительно быстро устаревают и становятся не интересными для потенциальных воришек

    На практике, ленту меняли дежурные инженеры датацентра в установленное время. Если забывали - на ленту полюбому записывалась новая копия...

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

    Для восстановления на другом сервере, для соответствующей уётки устанавливаем сертификат шифрации, после чего используем стандартный NTBACKUP.

     Режимы проверки устройства с резервной копией лучше включать...

    5 марта 2007 г. 19:30
  • To Alexei Khalyako - вы Даниле Полевщикову или корифею SQL.ru Александру Гладченко?
    Адрес Ваш, к сожалению, не доступен для просмотра. Мой Benetton[at]list.ru

    Могу привести план восстановления на 2005-м в большой поликлинике одной из столиц Юга России:) Но там тоже мало интересного - Mirroring, Full Backup + Differential.

     

    6 марта 2007 г. 10:05