Резервное копирование сайта

Источник: статья "Резервное копирование сайта" на сайте www.wwwmaster.ru

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

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

Что и как копировать

Ответ на этот вопрос зависит от организации сайта. Все сайты можно условно разделить на следующие типы.

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

Резервное копирование статичных сайтов осуществляется простым копированием через FTP-соединение либо всего сайта (всего дерева каталогов), либо отдельных (измененных/добавленных с момента предыдущего копирования) файлов. Если суммарный объем страниц сайта большой (от нескольких мегабайт), то для сокращения времени и трафика при полном копировании имеет смысл предварительно, на сервере, заархивировать сайт с помощью какого-либо из распространенных архиваторов (ZIP, ARJ, RAR...) и копировать на локальный компьютер только файл архива, размер которого в несколько раз меньше.

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

2. Сайты, в которых программное обеспечение отделено от данных. Будем называть их динамическими сайтами (хотя в данном контексте этот термин не слишком точный). Как правило, в таких сайтах программное обеспечение (движок, CMS) меняется крайне редко, и его резервную копию надо делать после любых изменений. Данные же на таких сайтах меняются часто. Периодичность резервного копирования данных (на программистском жаргоне - бэкапов) зависит от скорости их обновления и от их важности. Как правило, даже на самых активно обновляемых сайтах не имеет особого смысла делать бэкапы чаще чем раз в сутки; для редко (не каждый день) обновляемых сайтов можно посоветовать проводить резервное копирование данных после каждого обновления.

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

2а: сайты, хранящие данные в файлах. Файлы данных таких сайтов располагаются, как правило, в одном из подкаталогов того же каталога, где находится движок сайта;

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

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

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

Обеспечение целостности данных

При создании резервной копии данных надо обеспечить целостность и непротиворечивость данных. Что это значит? Как правило, при добавлении / изменении данных корректировки вносятся сразу в несколько файлов (или таблиц базы данных). А сейчас представим, что, скажем, добавление статьи на сайт совпало по времени с процедурой резервного копирования. Вполне может получиться так, что один из файлов, изменяемых при добавлении статьи, запишется в резервную копию ДО, а другой - ПОСЛЕ того, как статья появилась на сайте. В результате может получиться так, что, к примеру, ссылка на статью (сохраненная в файле 2) в резервной копии будет присутствовать, а сама статья (которая лежит в файле 1) - нет. При восстановлении из такой копии у вас окажется битая ссылка, ведущая на несуществующую страницу. И это пример еще из числа самых безобидных... А если подобная нестыковка произойдет в биллинговой системе?

Как обеспечить, чтобы резервная копия содержала непротиворечивые данные? Подход тут единый: надо обеспечить, чтобы информация была зафиксирована на момент начала процедуры копирования и в ее ходе не менялась, по крайней мере "с точки зрения" программы, производящей бэкап. А вот реализация этого подхода очень сильно зависят от используемых базы данных и движка сайта. Не углубляясь в подробности, приведу лишь несколько примеров.

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

В MySQL есть утилита mysqldump, которая также автоматически обеспечивает корректность дампа, но только для транзакционных таблиц (InnoDB). Если же ваша MySQL-база построена на таблицах типа MyISAM (а большинство веб-приложений используют именно их), то перед запуском процедуры копирования (либо непосредственно при запуске mysqldump с помощью соответствующих ключей, --lock-all-tables или --lock-tables) надо сделать явную блокировку таблиц, то есть запретить пользователям что-либо в них записывать.

Хуже всего дело обстоит в случае, если сайт хранит данные не в БД, а в обычных файлах. Тут, пожалуй, возможно только одно корректное решение: движок сайта должен позволять администратору "нажатием кнопки" приостанавливать работу скриптов, записывающих данные в файлы. И уже после их остановки производить копирование.

Когда копировать

Про периодичность резервного копирования уже говорилось выше, тут - краткое резюме:

• статичные сайты, движки сайтов, данные редко обновляемых сайтов - после каждого обновления;
• данные часто обновляемых сайтов - 1 раз в сутки; можно и чаще, но это оправдано лишь в особых случаях;

Для копирования лучше выбирать время, когда ваш сайт менее всего загружен, когда на нем минимальное число пользователей. На большинстве сайтов такое наблюдается глубокой ночью, в районе 3-4 часов (московского времени, если говорить про Рунет). Не забывайте, что процесс копирования весьма ресурсоемкий и во многих случаях требующий блокировки работы пользователей.

Где хранить резервные копии

Главное и универсальное правило - резервные копии должны быть надежно защищены. Хорошенько подумайте: если что-то случится с сервером, что будет с резервными копиями данных? Самый худший вариант, который только можно придумать - это хранить резервные копии на том же компьютере и на том же жестком диске, на котором находится ваш сайт или его база данных (а такое хоть и не часто, но позволяют себе даже некоторые системные администраторы). Даже самому неискушенному пользователю понятно, что в этом случае при поломке компьютера / диска будет потеряна и основная информация, и резервная копия...

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

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

Итак: хранить резервные копии надо на сменном носителе (CD, флэшка) или на жестком диске компьютера, не связанного с сервером по локальной сети (а лучше и там, и там). Находиться эти носители (компьютер) должны в другом здании, а не в том же, в котором находится сервер, и в надежно защищенном месте (сейф / замки / решетки на окнах / сигнализация / охрана...).

Сколько времени хранить копии...

...и сколько их нужно делать? В большинстве случаев бывает достаточно хранить 2 копии: последнюю и предпоследнюю, но для подстраховки лучше все же сохранять от 3 до 7 последних копий. Каждую копию желательно иметь в 2 экземплярах, на разных носителях, например на жестком диске и на CD, и хранить их в разных помещениях. Стоимость места на носителях сейчас несравнимо ниже, чем затраты на восстановление данных при их потере...

Проверяйте копии

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

Кто должен копировать

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

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

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

Источник: статья "Резервное копирование сайта" на сайте www.wwwmaster.ru