Безопасное резервное копирование с помощью публичных сервисов

Часто бывает так, что существует множество различных проектов, которые необходимо регулярно бэкапить.
Но еще чаще бывает так, что поднимать свой собственный сервис резервного копирования лениво, и копии в лучшем случае делаются время от времени, а в худшем — не делаются вообще. Специально для ленивых людей придумали сервисы синхронизации файлов, такие как Dropbox, Yandex.Disk и иже с ними. Суть всегда одна — файл, загруженный на одном привязанном устройстве, появляется на всех остальных. Ура, решение найдено 🙂
Но встает другой вопрос — безопасность загруженного контента. И если за фотки с Майорки можно особо не переживать, то вот боевую базу 1С так бэкапить чревато. И вот тут, в этой самой статье, есть небольшой how-to про то, как остаться лентяем и сохранить файлы в безопасности.

Предположения

При написании этого HOW-TO я предполагаю, что читатель знаком с основами системного администрирования, может самостоятельно создать аккаунт и настроить сервис синхронизации на удаленном компьютере. Я буду показывать на примере CentOS 6 Linux, своих узлов и сервиса Dropbox. Все тоже самое можно сделать и на других ОС и сервисах. И даже вместо GnuPG можно использовать OpenSSL.

Установка софта на хранилище

Установка и настройка Dropbox

Качаем и ставим. Кстати, несмотря на то, что в зависимостях есть X11, можно спокойно ставить с —nodeps

[root@server ~]# wget https://www.dropbox.com/download?dl=packages/fedora/nautilus-dropbox-1.6.0-1.fedora.x86_64.rpm [root@server ~]# rpm -i --nodeps nautilus-dropbox-1.6.0-1.fedora.x86_64.rpm  Dropbox installation successfully completed! You can start Dropbox from your applications menu. [root@server ~]# su user [user@server ~]$ dropbox start -i Downloading Dropbox... 100% Unpacking Dropbox... 100% Done! [user@server ~]$ dropbox stop [user@server ~]$ ~/.dropbox-dist/dropboxd  This computer isnt linked to any Dropbox account... Please visit https://www.dropbox.com/cli_link?host_id=**************************************** to link this device. This computer isnt linked to any Dropbox account... Please visit https://www.dropbox.com/cli_link?host_id=**************************************** to link this device.

Переходим по ссылке, вводим пароли, и вот:

This computer is now linked to Dropbox. Welcome ********* ^C ~/.dropbox-dist/dropboxd  & [user@server ~]$ exit [root@server ~]# rpm -e nautilus-dropbox 

Установка GNUPG2 и создание ключей

[root@server ~]# yum install gpg [... skipped ...] [root@server ~]# su user

Создаем пару ключей

[user@server ~]$ gpg --gen-key [... skipped ...]  Please select what kind of key you want:    (1) RSA and RSA (default)    (2) DSA and Elgamal    (3) DSA (sign only)    (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid.          0 = key does not expire       <n>  = key expires in n days       <n>w = key expires in n weeks       <n>m = key expires in n months       <n>y = key expires in n years Key is valid for? (0)  Key does not expire at all Is this correct? (y/N) y  GnuPG needs to construct a user ID to identify your key.  Real name: Backup Server Email address: backup@my.company.com Comment: Main backup server You selected this USER-ID:     "Backup Server (Main backup server) <backup@my.company.com>"  Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. [... skipped ...] gpg: key E4E021AB marked as ultimately trusted public and secret key created and signed.  gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u pub   4096R/E4E021AB 2014-01-29       Key fingerprint = 0FDC B999 6FEB FBB5 1E59  48BD 71C2 6663 E4E0 21AB uid                  Backup Server (Main backup server) <backup@my.company.com> sub   4096R/C7212824 2014-01-29

Если при генерации gpg будет ругаться, что не хватает энтропии, создайте её 🙂
Я обычно захожу в другую консоль и делаю что-то вроде:

[user@server ~]$ while true; do find / -type f; done

Осталось только расшарить публичный ключ между всеми участниками — кладем его в Dropbox.

[user@server ~]$ gpg --export -o ~/Dropbox/public.gpg

Установка софта на резервируемом сервере

В принципе, все тоже самое, но свои ключи можно не генерировать.
Достаточно сделать

[user@server ~]$ gpg --import ~/Dropbox/public.gpg

Процесс резервного копирования

Можно по-разному. У меня у каждого сервера есть свой dropbox-аккаунт, и папка, которая является общей (Shared folder) с бэкап-сервером. Типа backu_srv1, backup_srv2 итд. Хотя можно просто иметь 1 аккаунт на все сервера — всё зависит от объемов данных, которые будут резервироваться.
Главная «фишка» — шифрование файлов перед тем, как положить их в Dropbox.
Ниже — пример скрипта, бекапящего базу данных mysql.

#!/bin/sh FILE="~/Dropbox/backup_srv1/mysql_$(date +%d.%m.%y).sql.gz.gpg" LOG="~/scripts/backup.log" USER="************" PASS="************" DB="**********" KEY="0xE4E021AB" export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl mysqldump -u${USER} -p${PASS} $DB|gzip -c|gpg --trust-model=always --yes -e -r $KEY -o "$FILE" && echo "$FILE : OK" >> "$LOG" && exit echo "$FILE : ERROR" >> "$LOG" && exit 

Обратите внимание на KEY — это ID публичного ключа, который мы получили в пункте 2 и который мы импортировали в на сервер.

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

Дальнейшее использование бэкапов

Возможны варианты. Можно расшифровывать все полученные бэкапы и складывать их куда-нибудь, можно хранить зашифрованными до часа «Х». Это дело вкуса. Единственное, что я рекомендую — это иметь несколько копий приватного ключа, в том числе на листочках A4 в конверте в сейфе. Если все остальные варианты потеряете — будете набивать с листочка много-много символов 🙂

[user@server ~]$ gpg --armor --export-secret-keys

Ах, да. Сама расшифровка.

[user@server backup_srv1]$ gpg -o ~/mysql_29.01.14.sql.gz -d mysql_29.01.14.sql.gz.gpg  Необходима фраза-пароль для доступа к секретному ключу пользователя: "Backup Server (Main backup server) <backup@my.company.com>" 4096-бит RSA ключ, ID C7212824, создан 2014-01-29 (главный ключ ID E4E021AB)  gpg: зашифровано 4096-битным ключом RSA, с ID C7212824, созданным 2014-01-29       "Backup Server (Main backup server) <backup@my.company.com>"

А теперь — важная вещь:
Не расшифровывайте свои бэкапы в папки, которые синхронизируются с Dropbox!

Вместо заключения

Если вы, прочитав эту статью, побежали регистрировать аккаунт на каком-нибудь сервисе и генерировать ключи — значит вы из тех, кто уже делает бэкапы. Поздравляю! 🙂
Если же вам всё еще лениво — не отчаивайтесь, вас ждет отличный опыт и много адреналина. Когда-нибудь.
А если вам захотелось узнать, что еще умеет делать gnupg — можете заглянуть сюда

—
8033A3EF/DBD1 B794 73AD 3A5C 9279 A8E1 16B5 6AA3 8033 A3EF