Здесь больше нет рекламы. Но могла бы быть, могла.

Автор Тема: О том, КАК должно делаться резервное копирование. Общие принципы.  (Прочитано 3354 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Ночной Сторож

  • Старожил
  • ****
  • Пол: Мужской
  • Мыльницам не позирую!
    • Просмотр профиля
Существует ТРИ (а не два, как думают некоторые) основных действия в информационной системе, связанных с процедурой резервного копирования:

а1. Собственно резервное копирование.
а2. ПРИНЯТИЕ РЕШЕНИЯ о восстановлении системы ИЛИ ЕЁ ЧАСТИ из резервной копии.
а3. Собственно восстановление информации.

Существует ТРИ принципиальных свойства информационной системы, требующей резервного копирования:

б1. Насколько часто требуется обновлять резервную копию?

б2. Какая доля информации может обновляться?

б3. Насколько быстро требуется восстановить работоспособность системы при ситуации "поднимаем из полного бекапа"?

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

Третий - определяет, ЯВЛЯЮТСЯ ли необходимыми специальные технические решения (зеркалирование на аппаратном уровне, кластеризация системы), или нет.

б3.
Если ПРИЕМЛЕМОЕ время восстановления системы из полного бекапа БОЛЬШЕ примерно удвоенного времени копирования всего объёма информации из этого самого полного бекапа, то специальные технические решения НЕ ТРЕБУЮТСЯ.

б2.
Если доля обновляемой информации достигает 30% - БЕССМЫСЛЕННО делать какие-либо "дифференциальные" и "инкрементальные" бекапы. Имеет смысл "копировать сразу всё в полный бекап". Ибо это УПРОЩАЕТ как процедуру резервного копирования, ТАК И процедуру принятия решения, ТАК И процедуру восстановления.

б1.
Правильно спректированная система имеет МИНИМУМ ДВОЙНОЙ запас по СРЕДНЕЙ ЗА ПЕРИОД "от бекапа до бекапа" пропускной способности ВСЕХ устройств передачи данных по отношению к "штатному режиму работы при максимальной нагрузке".

Это означает, что при круглосуточной работе системы и параллельном непрерывном резервном копировании на процедуру бекапа должны быть ЗАЛОЖЕНЫ УТРОЕННЫЕ:
- скорость работы основной дисковой подсистемы
- скорость передачи по сети хотя бы на часть машин сети

Это означает, что при восьмичасовом рабочем дне процедура бекапа МОЖЕТ использовать НЕРАБОЧЕЕ время фирмы, без закладывания дополнительной скорости в аппаратуру.

Если эти условия НЕ выполняются - процедура резервного копирования НЕ выполняет возложенную на неё задачу ИЛИ, выполняя, снижает производительность системы (тормозит сеть, к примеру).

Некоторые принципы, которые ДОЛЖНЫ соблюдаться в процедурах резервного копирования:

в1. Бекап НЕ ДОЛЖЕН БЫТЬ доступен пользователям сети, как на запись, так и на чтение.

в2. Восстановление информации ДОЛЖНО осуществляться путём ВРЕМЕННОГО создания условий для чтения бекапа админу, который в соответствии с пожеланиями пользователя восстанавливает ему часть информации или, в соответствии с принятым решением а2, восстанавливает ВСЁ.

в3. Бекап должен осуществляться на оборудование, находящееся в другом помещении, нежели основное, в идеале - в никак административно и технически не зависящее от основного помещение. Наиболее правильно совершать бекап на сервера, находящиеся в других странах, для безопасности при этом достаточно двойной упаковки WinRar'ом с двумя разными паролями.
уведена аська. 55319926 - невалиден.
новый номер - 383091334

Оффлайн Hel

  • Старожил
  • ****
  • Волкодав Валинорский
    • Просмотр профиля
Толково, по существу, но применительно к моему вопросу - выстрел из Царь-пушко по воробью.
Феаноринги не думают, потому что в мирное время это вызывает смех, а в военное - панику.

Оффлайн Ночной Сторож

  • Старожил
  • ****
  • Пол: Мужской
  • Мыльницам не позирую!
    • Просмотр профиля
Толково, по существу, но применительно к моему вопросу - выстрел из Царь-пушко по воробью.

Я всего лишь пытаюсь донести до Вас (модераторы в Вашей теме не позволили это сделать)
понимание НЕРАЗРЕШИМОСТИ поставленной Вами задачи в указанных Вами условиях.

Вы же упорно хотите, чтобы Вам показали чудо.
Чуда не будет.
Пусть будет хотя бы понимание того, ПОЧЕМУ его не будет.
уведена аська. 55319926 - невалиден.
новый номер - 383091334

Оффлайн Hel

  • Старожил
  • ****
  • Волкодав Валинорский
    • Просмотр профиля
Хихикс.
Сергей, сходите в начало моего треда и поищите там слова "резервное копирование системы"
Чем отличается операционная система от массива файлов, лежащих в одной, пусть и очень здоровой, папке этой самой системы, Вы надеюсь знаете?
Попробуйте решить получившееся уравнение предела с новыми параметрами.
Феаноринги не думают, потому что в мирное время это вызывает смех, а в военное - панику.

Оффлайн Ночной Сторож

  • Старожил
  • ****
  • Пол: Мужской
  • Мыльницам не позирую!
    • Просмотр профиля
Хихикс.
Сергей, сходите в начало моего треда и поищите там слова "резервное копирование системы"
Чем отличается операционная система от массива файлов, лежащих в одной, пусть и очень здоровой, папке этой самой системы, Вы надеюсь знаете?
Попробуйте решить получившееся уравнение предела с новыми параметрами.


Не притворяйтесь более глупым, чем являетесь.
Сходите в начало данного треда и поищите в моём сообщении слово "Операционная". :)

В моей формулировке "Система" - это ЛЮБОЙ набор файлов, рассматриваемый как некое единое целое сисадмином и начальством, и который интересен с точки зрения работоспособности фирмы или сервера. Или группы фирм. В частном случае это МОЖЕТ БЫТЬ операционная система БЕЗ пользовательских файлов, но ценность именно её резервного копирования близка к нулю. :)

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

Порнуха, лежащая на юзверьских компах, НЕ входит в это единое целое технически. И это прекрасно.
Порнуха, положенная юзверем в каталог, резервное копирование которого осуществляется - входит в это "единое целое" технически. И это нехорошо..
уведена аська. 55319926 - невалиден.
новый номер - 383091334