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

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

Не уделяют должного внимания резервному копированию и сайтовладельцы.  Рассуждают они так: у хостера есть ежедневное резервирование, и если не дай Бог произойдет сбой “железа”, всю информацию можно будет без труда восстановить.  К тому же на серверах хостинг-провайдера используется RAID c зеркалированием, поэтому и восстанавливать ничего не придется.   Вирусы серверам хостера тоже не страшны: на них, как правило,  установлен Linux, под который вредоносного  ПО нет вовсе.  

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

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

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

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

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

Для начала скачаем с ГитХаба утилиту Supload, которая как раз предназначена для загрузки копий в облачное хранилище (в моем случае настройка резервного копирования осуществлялась на сервере с OC Debian):

$ wget https://raw.github.com/selectel/supload/master/supload.sh
$ mv supload.sh /usr/local/bin/supload
$ chmod +x /usr/local/bin/supload

Затем скачаем скрипт для выполнения собственно резервного копирования:

$wget https://raw.github.com/selectel/storage/master/utils/sbackup.sh
$ chmod +x sbackup.sh

Откроем этот скрипт в текстовом редакторе и изменим значения следующих параметров:

• SS_USER — указываем имя пользователя, который был создан специально для работы с хранилищем;
• SS_PWD — указываем пароль для этого пользователя;
• SS_CONTAINER —  указываем имя контейнера, где будут храниться резервные копии;
• TARGET_DIR — здесь указываем путь к файлам сайта;
• BACKUP_DIR — адрес директории для временного хранения бэкапов
• EXCLUDE_LIST — сюда указываем файлы, которые не нужно включать в резервную копию;
• DB_NAME — имя базы данных MySQL;  чтобы бэкапить все имеющиеся базы укажите к качестве значения __ALL__;
• DB_USER и DB_PWD —  здесь указываем имя пользователя и пароль для подключения к MySQL;
• EMAIL — указываем  адрес, куда будет присылаться отчет о выполнении бекапа (если это значение оставить пустым, отчета присылаться не будет);
• EMAIL_ONLY_ON_ERROR — здесь можно указать YES, чтобы получать по почте отчеты в случае возникнования ошибок или проблем
• DELETE_BACKUPS_AFTER_UPLOAD —  если указать YES, то при успешном завершении загрузки все файлы из временном папки будут удалены
• STORAGE_EXPIRE — здесь можно установить срок хранения, по истечении которого резервные копии будут удалены.

Запустим теперь скрипт и посмотрим, как он работает:

$ ./backup.sh

Задать периодичность резервного копирования можно при помощи cron.  Это делается очень просто - путем перемещения скрипта в специальную директорию:

$ mv sbackup.sh /etc/cron.daily/50_sbackup

Cron будет запускать скрипт резервного копирования раз в 24 часа.

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

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

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

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

$ mkdir backup_files
$ tar xvf backupname_2013-01-26_08h40m.tar.bz2 -C backup_files/
$ bzcat mysql_backupname_ALL_2013-01-26_08h40m.bz2 | mysql

Вот, собственно, и все.

Резервное копирование с шифрованием

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

Duplicity поддерживает очень много разных протоколов: SSH/SCP, FTP, HSI, WebDAV, Tahoe-LAFS и Amazon S3.   А вот с Open Stack Swift, на котором  работает селектеловское облачное хранилище, придется попыхтеть.

Для начала установим Duplicity.  Она включена в репозитории большинства современных дистрибутивов Linux.  

$ sudo apt-get install duplicity

На клиентской машине также должны обязательно быть установлены пакеты python-swiftclient и librsync.

Для работы с Duplicity понадобится также утилита swiftbackend.   Ее установка - отдельная песня.   Репозиторий swiftbackend хранится на launchpad.  Чтобы его клонировать, потребуется еще установить на клиентскую машину систему контроля версий bazaar:

$ sudo apt-get install bzr
$ bzr branch lp:~mhu-s/duplicity/swiftbackend

Теперь можно устанавливать Duplicity:

cd swiftbackend && sudo python dist/setup.py install

Чтобы настроить резервное копирование,  откроем текстовый редактор и напишем небольшой скриптик:

# Авторизационые данные для подключения к хранилищу
export SWIFT_USERNAME="имя пользователя"
export SWIFT_PASSWORD="пароль для входа в хранилище"
export SWIFT_AUTHURL="https://auth.selcdn.ru"

# Выполнение архивирования
duplicity /путь к папке/на клиентской машине swift://имя контейнера в хранилище

# Очистка авторизационных данных для безопасности
unset SWIFT_USERNAME
unset SWIFT_USERNAME
unset SWIFT_AUTHURL

Назовем этот файл backup.sh и сделаем его исполняемым.    После этого запустим скрипт:

$ ./backup.sh

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

Как восстановить файлы из резервной копии?  Для этого напишем еще один скрипт.  От предыдущего он отличается только одной строчкой:

duplicity swift://имя контейнера /путь/к папке/на локальной/машине

Сохраним его под именем restore.sh и сделаем исполняемым.   Затем скачаем файл резервной копии через веб-интерфейс и запустим скрипт:

$ ./restore.sh

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