(no subject)
Jun. 30th, 2008 02:00 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
alexkuklinО резервном копировании
wiki поднимать лениво, поэтому - тут
статус текста - черновик
буду благодарен за конструктивную критику
Резевное копирование - это очень странный предмет. Вроде как, все согласны, что его надо делать. С другой - многие ли его делают регулярно? Что же мешает?
Проведем анализ задачи.
Резервное копирование - процесс копирования данных на резевные носители для обеспечения возможности восстановления в случае сбоя.
Для того, чтобы понять, что, как, зачем и когда нужно делать для решения задачи резевного копирования - рассмотрим каждый термин отдельно.
Во-первых, следует определить термин "данные".
В общем случае данные - это то, что хранится на устройстве постоянной памяти. Если необходимо обеспечить абсолютно полную резервную копию носителя, то нужно хранить по-блочный образ информационной области. Однако, так, как правило, не делают. На то есть три причины - большой объем избыточных данных, сложность в доступе к отдельным частям данных в архиве и необходимость останавливать работу системы для получения консистентного образа.
Тем не менее, такие решения для резервного копирования существуют и достаточно часто используются. Они особо актуальны для систем на базе ОС семейства Windows, т.к. там далеко не все необходимые для работоспособности системы данные доступны через операции чтения/записи файлов [во всяком случае, начиная с XP, невозможно перенести систему с диска на диск путем форматирования раздела и переноса файлов]. При копировании максимально сохранятся структура служебных файлов и игнорируются неиспользуемые блоки.
Однако тут мы упираемся в ряд моментов.
Во-первых, как уже был замечено, такой способ требует остановки работы системы для получения консистентного образа. Соответственно, к сохранению данных с сервера метод неприменим.
Во-вторых, резервируется множество избыточных данных.
Немного возвращаясь к нашим баранам, т.е. к понятию "данные". Таки, что такое "данные" и как их можно классифицировать?
Для начала, данные следует разделить на первичные и вторичные. Соответственно, вторичные данные можно получить из первичных при помощи некоторого доступного процесса. Например, исходный код - данные первичные, а скомпилированный софт - вторичные. Очевидно, что во многих случаях хранить вторичные данные совершенно не обязательно.
Данные можно разделить по срокам актуальности. Так, дистрибутив Windows XP Home актуален несколько лет (до выпуска очередного SP), а дистрибутив Firefox - максимум, несколько недель.
Данные можно разделить на возобновимые и уникальные. Для возобновимых имеет смысл учитывать стоимость возобновления.
Теперь о целях резервирования данных.
В случае отдельного пользователя резервирование обычно осуществляется для того, чтобы не потерять уникальные данные. Скорость восстановления и доступность резевных материалов, как правило, существенного значения не имеют.
В случае организации - при резервировании должны учитываться в том числе и сроки восстановления. В таком случае становится важно то время, за которое будет восстановлено нормальное функционирование.
(to be continued)
wiki поднимать лениво, поэтому - тут
статус текста - черновик
буду благодарен за конструктивную критику
Резевное копирование - это очень странный предмет. Вроде как, все согласны, что его надо делать. С другой - многие ли его делают регулярно? Что же мешает?
Проведем анализ задачи.
Резервное копирование - процесс копирования данных на резевные носители для обеспечения возможности восстановления в случае сбоя.
Для того, чтобы понять, что, как, зачем и когда нужно делать для решения задачи резевного копирования - рассмотрим каждый термин отдельно.
Во-первых, следует определить термин "данные".
В общем случае данные - это то, что хранится на устройстве постоянной памяти. Если необходимо обеспечить абсолютно полную резервную копию носителя, то нужно хранить по-блочный образ информационной области. Однако, так, как правило, не делают. На то есть три причины - большой объем избыточных данных, сложность в доступе к отдельным частям данных в архиве и необходимость останавливать работу системы для получения консистентного образа.
Тем не менее, такие решения для резервного копирования существуют и достаточно часто используются. Они особо актуальны для систем на базе ОС семейства Windows, т.к. там далеко не все необходимые для работоспособности системы данные доступны через операции чтения/записи файлов [во всяком случае, начиная с XP, невозможно перенести систему с диска на диск путем форматирования раздела и переноса файлов]. При копировании максимально сохранятся структура служебных файлов и игнорируются неиспользуемые блоки.
Однако тут мы упираемся в ряд моментов.
Во-первых, как уже был замечено, такой способ требует остановки работы системы для получения консистентного образа. Соответственно, к сохранению данных с сервера метод неприменим.
Во-вторых, резервируется множество избыточных данных.
Немного возвращаясь к нашим баранам, т.е. к понятию "данные". Таки, что такое "данные" и как их можно классифицировать?
Для начала, данные следует разделить на первичные и вторичные. Соответственно, вторичные данные можно получить из первичных при помощи некоторого доступного процесса. Например, исходный код - данные первичные, а скомпилированный софт - вторичные. Очевидно, что во многих случаях хранить вторичные данные совершенно не обязательно.
Данные можно разделить по срокам актуальности. Так, дистрибутив Windows XP Home актуален несколько лет (до выпуска очередного SP), а дистрибутив Firefox - максимум, несколько недель.
Данные можно разделить на возобновимые и уникальные. Для возобновимых имеет смысл учитывать стоимость возобновления.
Теперь о целях резервирования данных.
В случае отдельного пользователя резервирование обычно осуществляется для того, чтобы не потерять уникальные данные. Скорость восстановления и доступность резевных материалов, как правило, существенного значения не имеют.
В случае организации - при резервировании должны учитываться в том числе и сроки восстановления. В таком случае становится важно то время, за которое будет восстановлено нормальное функционирование.
(to be continued)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-06-29 10:21 pm (UTC)Но, на мой взгляд, если делать "теорию резервного копирования", то нужно танцевать от обратного: за какое время мы сможем воссоздать систему с каким лагом (точнее, с каким откатом в прошлое).
Дополнительный вопрос: на том же аппаратном обеспечении или на произвольном?
Дополнительный вопрос №2: на той же версии ПО или на любой (в разумных пределах).
А для того, чтобы бэкапы делались регулярно нужно делать регулярные учения, что, собственно, и отвечает на большинство вопросов. У меня вот, на июнь запланирована вообще имитация аварии на сервере баз данных с полным разрушением всей информации.
no subject
Date: 2008-06-30 06:38 am (UTC)На staging, я надеюсь? ;)
no subject
Date: 2008-06-30 01:49 pm (UTC)no subject
Date: 2008-06-30 02:00 pm (UTC)Не страшно? ;-)
no subject
Date: 2008-06-30 02:05 pm (UTC)Единственное, что меня (теоретически) смущает - это перенос наработок с резервного на основной.
А пробовать страшно. Но лучше пробовать когда знаешь, что может случиться, чем решать внезапные и очень неприятные проблемы тогда, когда их решать совершенно нет времени.
no subject
Date: 2008-06-30 10:05 am (UTC)Учения - это мысль, да. Причем не только по части резервного копирования.
Например, в формате "а теперь предположим, что тебя (тыкаем в сотрудника)
увезли в больницузамуровали демоны; а теперь попробуем решить существующие бизнес-задачи". С выписыванием по результатам соответстсвующихпи..стимулирующих воздействий сотруднику и его руководителю :)no subject
Date: 2008-07-01 10:44 am (UTC)всего конечно не охватишь, но как поднять в адекватные сроки нужный функционал по идее смог бы разобраться любой инженер.
no subject
Date: 2008-06-30 08:15 am (UTC)Как - то так.