Резервная копия VPS на серверах Amazon

30 March 2014 #amazon#security#backup

Программисты шутят: люди делятся на тех, кто НЕ делает бэкап и тех, кто его УЖЕ делает.

Резервную копию своего сервера можно хранить и на серверах Amazon. Про низкую стоимость сервисов S3  все уже слышали. А тут еще с 1 апреля 2014 года стоимость падает на 65%. Грех не воспользоваться.

Установка и настройка программного обеспечения

Во-первых, установим все необходимое программное обеспечение:

$ sudo apt-get install duplicity duply python-boto

Теперь создаем профиль для работы с серверами Амазона:

$ duply main create

В данном случае main это имя профиля, которые мы выбираем самостоятельно, и оно может быть любым. В профиле размещается файл конфигурации $HOME/.duply/main/conf с которым мы в дальнейшем будем работать. Программа Duplicity, с помощью которой будет осуществляться загрузка данных, поддерживает шифрование, причем как асимметричное, так и с использованием пароля. Использовать пароль это самое простое, именно этот вариант и будем использовать.

Для генерации случайного пароля можно использовать команду:

$ openssl rand -base64 20

И теперь в файле конфигурации комментируем строку GPG_KEY и задаем пароль в строке GPG_PW:

#GPG_KEY='_KEY_ID_'
GPG_PW='<the password you just got from openssl>'

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

Опускаемся ниже до строк TARGET:

TARGET='s3://s3-<region endpoint name>.amazonaws.com/<bucket name>/<folder name>'
TARGET_USER='<your AWS access key ID>'
TARGET_PASS='<your AWS secret key>'

В TARGET задается адрес корзины и директории, в которой будут размещаться резервные копии. И чтобы не думать о правильности заполнения региона, проще всего его задать в виде:

TARGET='s3+http://<bucket name>/<folder name>

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

SOURCE='/'

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

MAX_AGE=6M

Так же стоит обратить внимание на параметр, задающий размер архива, по умолчанию он равен 25 мегабайт, увеличим его вдвое:

VOLSIZE=50
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

Теперь можно сохранить и закрыть файл конфигурации.

Вот теперь продолжаем задавать список директорий, которые мы хотим включить в резервную копию. Для этого создаем файл $HOME/.duply/main/exclude со следующим содержанием:

+ /etc
+ /var/www
- **

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

В качестве основной директории мы задали корень файловой системы, и теперь в файле exclude определили, что из всего набора директорий нам необходимо включать в резервную копию только /etc и /var/www, а все остальные директории и файлы будут исключаться из резервной копии.

После задания всех настроек необходимо будет перейти на сайт aws.amazon.com и в консоли управления S3 создать bucket (корзину) для хранения резервных копий.

Инициализация резервной копии

После проведения настроек потребуется провести пробное создание резервной копии. При первом запуске проводится полный бекап, и часто он занимает продолжительное время (зависит от объемов включаемых данных). Чтобы не возникало проблем, воспользуемся программой tmux:

$ sudo apt-get install tmux
$ tmux

Теперь запускаем создание резервной копии:

$ sudo duply main backup

После чего используем сочетание клавиш Ctrl+b d для того, чтобы отсоединиться от текущей сессии tmux. Теперь можно спокойно закрывать ssh-соединение, программа продолжит свою работу в фоне.

Возвращаемся позже, соединяемся с сервером и подключаемся к сессии tmux:

$ tmux attach

Если увидите в консоли подобное сообщение, значит создание резервной копии прошло успешно:

--------------[ Backup Statistics ]--------------
...
Errors 0
-------------------------------------------------

--- Finished state OK at 16:48:16.192 - Runtime 01:17:08.540 ---

--- Start running command POST at 16:48:16.213 ---
Skipping n/a script '/home/admin/.duply/main/post'.
--- Finished state OK at 16:48:16.244 - Runtime 00:00:00.031 ---

Автоматический запуск с использованием cron

Для того чтобы проводить запуск duply регулярно, достаточно использовать cron:

$ sudo crontab -e

Добавляем в конец файла следующую строчку:

0 2 * * * env HOME=/home/admin duply main backup

В данном случае запуск будет проводиться ежедневно в 2 часа утра. Более подробно по формату задания времени можно узнать в справке cron.

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

Простое восстановление

Для восстановления последнего состояния файлов используется команда restore. При этом указывается директория, в которой будут размещаться восстанавливаемые файлы:

$ sudo duply main restore /restored_files

И после восстановления уже перемещаем файлы/директории в требуемое место. Не пытайтесь использовать команду sudo duply main restore / так как системные файлы (такие как bash, libc и другие) наверняка будут заняты. И восстановление потребует загрузку сервера в режиме восстановления, после чего файлы можно будет перенести на свои законные места.

Восстановление определенных файлов или директорий

Для восстановления определенных файлов или директорий используется команда fetch. К примеру, для восстановления файла /etc/password из бекапа и размещения его в директории /home/admin/password  используется команда:

$ sudo duply main fetch etc/password /home/admin/password

Обратите внимание на то, что при указании файла, который восстанавливаем, первая косая черта пропущена специально, это не ошибка. Так же команда fetch работает и с директориями:

$ sudo duply main fetch etc /home/admin/etc

Восстановление файлов на определенную дату

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

$ duply main status
...
Number of contained backup sets: 2
Total number of contained volumes: 2 
Type of backup set:                            Time:      Num volumes:
               Full         Sat Nov  8 07:38:30 2013                 1
        Incremental         Sat Nov  9 07:43:17 2013                 1
...

В данном примере проведем восстановление из резервной копии за 8 ноября:

$ sudo duply test restore /restored_files '2013-11-08T07:38:30'

Обратите внимание на то, что дата задается в формате w3. Про формат времени более подробно можно почитать на странице the Time Formats section in the Duplicity man page.

Осторожность в хранении ключей/пароля

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

Поэтому храните пароли и ключи в программе 1Password и при этом дублируйте данные на телефон, планшет или другие сервера. Или же используйте альтернативные программы/сервисы, типа LastPass или KeePass.