Сайты в кладовке

Фленов Михаил aka Horrific

Спецвыпуск: Хакер, номер #062, стр. 062-070-1

(www.vr-online.ru)

Повесть о резервировании web-сайта

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

Опасность для сайта

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

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

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

Резерв из шелла

Если есть возможность и права на выполнение команд, можно создать дамп базы с помощью утилиты MySQLDump, которая входит в поставку сервера. Эта команда выполняется в следующем виде:

mysqldump параметры имя_базы > файл.sql

В результате в файле файл.sql помещен дамп базы в виде SQL-запросов. Чтобы восстановить структуру базы и данные, достаточно выполнить запросы из файла — и вот уже БД на родине.

В качестве параметров необходимо как минимум указать ключ –p. В ответ MySQLDump запросит пароль пользователя, с которым нужно подключиться. По умолчанию используется имя пользователя root, и если он не пустой (я надеюсь на это, иначе даже дамп не поможет от хакеров), то без ключа –p утилита MySQLDump не сможет подключиться к базе и сделать ее дамп.

Итак, чтобы создать дамп базы данных mysite, необходимо выполнить следующую команду:

mysqldump -p mysite > dump.sql

В ответ перед нами появляется запрос на ввод пароля. Если пароль указан верно, то в файле dump.sql возникает полный дамп базы данных mysite. Как я уже писал, для восстановления теперь достаточно только выполнить все команды из данного файла, и структура базы вместе с данными тут же вернутся на свое первоначальное место.