Аудит от независимых экспертов

поможет выявить проблемы на вашем сайте


 

 
 
 

Ответы на основные вопросы по резервному копированию сайта

Ответы на основные вопросы по резервному копированию сайта
Работающий в Интернете сайт подвержен многочисленным рискам, каждый из которых способен привести к потере данных. Для размещения web-страниц может использоваться сервер с RAID-массивами с повышенной устойчивостью против сбоев за счет создания зеркальных копий, но и такая современная установка иногда ломается.

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

Что следует копировать, как это делать и с какой периодичностью?
Для того чтобы ответить на этот вопрос, нужно определить, к какому типу относится сайт. Если он статичный, состоящий из html-страниц, на которых непосредственно хранится информация, то достаточно обычного копирования при помощи FTP-соединения. Данные могут быть и в файлах, для подключения которых используется функция include, или другой способ. А сами страницы могут содержать небольшие скрипты или ssi-вставки – в данном случае это не имеет принципиального значения. Обновлением информации на подобных сайтах занимается обычно администратор.

При сохранении данных копируется либо весь сайт, либо некоторые его файлы, обычно те, которые были добавлены или подвергались изменениям за время, прошедшее от последней подобной процедуры. Нередко бывает, что сайт достаточно большой, несколько мегабайт и выше. В этом случае, чтобы копирование не занимало слишком много времени и не поглощало трафик, он предварительно архивируется на сервере при помощи одной из программ: ZIP, RAR, ARJ и т.д. После чего на отдельный компьютер достаточно скопировать архивный файл.

Может возникнуть ситуация, которая потребует синхронизировать данные при их сохранении. Это происходит, когда FTP-доступом пользуются несколько клиентов, каждый из которых может вносить обновления в независимом режиме. В этом случае администратору достаточно на время копирования запретить пользователям добавлять или изменять информацию. А после завершения сохранения данных снова открыть доступ.

У другой группы сайтов, которые можно назвать динамическими, информация существует отдельно от программного обеспечения. Последнее, например CMS или движок, подвергается изменениям настолько редко, что требует сохранения резервной копии после любой правки. В то же время обновление данных на сайтах такого типа происходит довольно часто. Резервное копирование информации (на сленге программистов – бэкап) выполняется с частотой, которая находится в прямой зависимости от быстроты ее обновления, а также от того, насколько важны данные, предназначенные для сохранения. Тем не менее, даже в том случае, когда обновление происходит достаточно активно, чаще одного раза в сутки бэкап не делается. Для остальных же сайтов, которые не могут похвалиться частой сменой данных, копирование проводится после их очередного обновления.

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

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

Во втором (информация в базе данных) лучше всего создать дамп БД, представляющий собой специальный файл, в котором информация БД хранится в формате SQL-запросов. Это касается всех объектов базы: обычных данных, индексов, хранимых процедур, структуры таблиц, триггеров и т.д. Удобство этого способа объясняется тем, что каждая БД имеет в своем составе утилиту для создания такого дампа.

Как обеспечить целостность сохраняемой информации?
Главной задачей при сохранении данных является обеспечение их целостности и непротиворечивости. Важность проблемы можно проиллюстрировать на следующем примере. Обычно в процессе обновления корректировке подвергается не один файл (или таблица БД), а несколько. Если во время процесса резервного копирования на сайт добавляется новая статья, то может случиться так, что одна часть файлов, подлежащих изменению, будет сохранена в резервной копии до появления статьи на сайте, а другая – после. При этом в копии окажется ссылка на статью, тогда как сама статья в нее не попадет. Это приведет к тому, что при восстановлении данных из копии, страница со статьей окажется несуществующей, а ссылка на нее – не работающей. Приведенная для примера нестыковка сравнительно безобидная, потому что если подобное происходит в биллинговой системе, последствия оказываются намного хуже.

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

Утилиты Oracle позволяют делать резервную копию без ограничения работы пользователей, желающих ввести новую информацию. При этом в созданном дампе обеспечивается непротиворечивость информации. Правда, условием их нормальной работы является корректная реализация закрытия транзакций в приложениях клиентов.

На то же самое способна и утилита mysqldump в составе MySQL. Однако с ее помощью целостность информации дампа можно обеспечить лишь для случая построения MySQL-базы на транзакционных таблицах (InnoDB). Но, поскольку web-приложения работают в основном на таблицах типа MyISAM, то администратору приходится перед началом копирования запрещать пользователям вносить изменения в БД.

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

Какое время суток наиболее подходящее для копирования?
О периодичности проведения бэкапа уже было сказано. Для статичных сайтов и редко обновляемых динамических это делается после внесения изменений, а для тех, которые обновляются часто – ежедневно. Два и более раза в сутки копия делается только в исключительных случаях. 

Оптимальное время для выполнения подобной процедуры – от 3.00 до 4.00. В эти часы на web-страницах меньше всего пользователей, сайты не слишком загружены. Это важно, учитывая то, что изготовление резервной копии требует привлечения больших ресурсов и часто сопровождается запретом на изменение информации.

Правила хранения резервных копий
При хранении резервных копий нужно позаботиться об их надежной защите. Следует отбросить все варианты, при которых существует высокая вероятность повреждения носителей. 

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

Не следует хранить копии в одном помещении с сервером. При пожаре или другом непредвиденном происшествии они также будут потеряны вместе с сайтом.

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

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

Количество копий и продолжительность их хранения
Нужно исходить из того, что стоимость носителей для хранения копий значительно ниже по сравнению с расходами на восстановление утерянных данных. Так что экономия в данном случае не приветствуется. Если же вести речь о конкретном количестве, то следует хранить как минимум последнюю и предпоследнюю копии. При этом каждую – в двух экземплярах, на разных носителях и в различных помещениях. Довольно часто для большей надежности хранят от трех до семи последних резервных копий. Исходя из этих рекомендаций, определяются и сроки хранения.

Нужно ли проверять корректность работы копий?
Для первой копии – обязательно. Это позволит убедиться в корректной работе не только полученной копии, но и самого процесса копирования. А поскольку в мире нет ничего вечного, то такую проверку нужно проводить еженедельно, или хотя бы ежемесячно, во избежание сбоев в процессе создания копии с течением времени. Строго говоря, проверять следует каждую сделанную копию по той простой причине, что обнаружение в дампе битых ссылок после падения сайта приводит к очень печальным последствиям. 

Для выполнения проверки на локальном хосте создается копия сайта, на которой и проводится пробное восстановление сохраненной информации. Процедура достаточно трудоемкая, каждый раз ее почти никто не делает, так что фраза об обязательности проверки при каждом копировании является скорее пожеланием, чем нормой.

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

При использовании хостинга это делает владелец сервера (хостер). В большинстве случаев услуга предусматривает копирование один раз в сутки (обычно ночью) даже при самых дешевых тарифах.

Однако перед началом сотрудничества данный момент следует все-таки уточнить, поскольку поступают так не все хостеры. А заодно выяснить, каким образом выполняется процедура, поинтересоваться о месте хранения копий, договориться о периодическом их получении для того, чтобы хранить их еще и у себя. Лучше всего в любом случае делать копии самому – дополнительная защита никогда не бывает лишней.

Если же хостер резервным копированием информации не занимается, то с его сервером лучше не связываться.
 
 
Голосов: 1
Баллы рейтинга: 5

Гэми пишет:
15.10.2010 14:53
Хорошая и полезная информация для сайтовладельцев.
CON пишет:
26.07.2011 13:25
Да интересная.
Владимир Шупляков пишет:
06.05.2011 22:25
Стоит добавить, что лучше не полагаться полностью на хостера, а периодически самостоятельно делать резервные копиии сайта и его базы данных. У американских сисадминов 70-х была расхожая шутка, что самая лучшая резервная копия сервера та лента, что лежит в другом здании в несгораемом сейфе.
CON пишет:
26.07.2011 13:26
Это правда. Но зачем тогда хостинг
Феликс пишет:
23.05.2011 12:41
Количество копий и продолжительность их хранения
Нужно ли проверять корректность работы копий?
Нужно столько копий, сколько раз проводилось изменение (до ипосле).
При нововведении иногда проще переделать более раннию версию, чем последнию.
Программисту виднее, он принимает решение.
CON пишет:
26.07.2011 13:28
Однако не все программисты знают об этом
CON пишет:
26.07.2011 13:29
На вордпрессе есть такая функция

 
 
 
 
 
 
Смотрите также