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

  • Tutorial

Часто бывает так, что существует множество различных проектов, которые необходимо регулярно бэкапить.
Но еще чаще бывает так, что поднимать свой собственный сервис резервного копирования лениво, и копии в лучшем случае делаются время от времени, а в худшем — не делаются вообще. Специально для ленивых людей придумали сервисы синхронизации файлов, такие как 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
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 52

    –1
    > то боевую базу 1С

    Лично я бы не стал доверять что-то более-менее серьезное Дропбоксу или Я.Диску.
    Использую AWS S3/Glacier (разные бакеты для «горячего» и долгосрочного хранения, причем перенос второго на Glacier настроен автоматом через S3 lifecycle) + s3cmd.
      0
      Из опыта использования Яндекса для бекапа 1С с файловым хранилищем:
      Как то в воскресенье позвонил бухгалтер и говорит: я вышла вчера поработать, а сегодня у меня всё то что я вбивало пропало.
      ситуация показалась странной для меня, по консультации с 1Сниками, я проверил журнал работы 1С.
      В журнале работы значилось, что данные были внесены и не удалялись, но ссылки на объекты базы были значились как Ошибка.
      немного поломав голову, я пошел смотреть в папку с базами в ней я обнаружил файлы с названиями:
      1Cv8.1CD
      1Cv8 (2).1CD
      1Cv8 (3).1CD
      сначала я не придал значения этому, а потом в папке с другой базой я увидел что в базе лежит только файл 1Cv8.1CD.
      таким образом переименовав файл с подходящей датой изменения в 1Cv8.1CD база сразу нормально заработала и все записи появились.
      остался только один вопрос после этого: какого черта Яндекс.диск при работе всего с одним сервером, ухитрился получить пять штук конфликтных версий файлов(я предполагаю из-за перебоев связи), и почему даже не сказав мне, он решил что версия которая лежит у него на сервере- главная, а та что у меня на сервере конфликтная — на самом деле эта ситуация очень сильно подпортила ощущения от работы их сервиса.
        0
        Вообще, живую базу, на которой сейчас работают на включенном сервисе синхронизации лучше не хранить… Бэкап — бэкапом, а когда 1Ска на лету изменяет данные, ЯДиск изменения пробует занести — и создает новые файлы из-за коллизий.
        Уж если лежит — ставьте синхронизацию на паузу, пока бухгалтер работает…
        У меня такие косяки по молодости с Voyajerом были (portable — TheBat!).
          +1
          >>Уж если лежит — ставьте синхронизацию на паузу, пока бухгалтер работает…
          смешно, получается что я должен сидеть и ждать когда же бухгалтера не будет работать.
          >>Бэкап — бэкапом, а когда 1Ска на лету изменяет данные, ЯДиск изменения пробует занести — и создает новые файлы из-за коллизий.
          нет здесь никакой коллизии, это кривые руки программиста. Я.диск не должен пытаться что-то изменять пока открыт дескриптор файла на запись, а если уж он все равно выливает базу в состоянии, пока открыт дескриптор на запись, то уж точно, он просто должен непрерывно выливать постоянно файл в инет, и никак не должен мне возвращать файл из своей базы который по определению старее чем мой, потому что мой всё еще в состоянии записи. а они получается передают неправильную метку времени, и тогда их версия оказывается новее моей.
          а вообще, наверно для моих целей лучше пользоваться сервисами для бекапа, но просто яндекс подкупил тем что скорость работы очень приличная.
            0
            Я.диск не должен пытаться что-то изменять пока открыт дескриптор файла на запись

            Кажется, это утверждение неверно. Я редактирую документ в ворде, периодически его сохраняя (дескриптор все это время открыт). Внезано приходит медный таз и накрывает мой компьютер. Вопрос: что я испытаю, когда узнаю, что мой файл не сихронизировался с сервером?
              +1
              Почему открыт? Он открывается в момент записи в основной файл, туда записывается содержимое и файл закрывается.
                0
                Хм. Ваша правда :) По крайней мере, ни одна из нескольких проверенных мной программ не «провинилась».
          0
          Вот о чем и речь.
          А еще у меня были такие случаи с Дропбоксом — 1. внезапно пропал файл. вообще пропал, нет ни локально, ни через вебморду. 2. какой-то косяк с версионированием большого файла — актуальной почему-то была самая первая версия, хотя после самой первой заливки я этот файл обновлял пару десятков раз.
          Т.е. когда нет полного контроля над этим — нет уверенности в надежности.
            0
            Что такое большой файл?
            У меня гигабайтный образ достаточно периодически изменяется и с ним все ок
              0
              Образ TrueCrypt-диска на 200 метров.
                0
                Аналогично, только 2014Мб
                  0
                  Ну фиг знает, может быть был какой-то случайный и временный косяк. В тот раз я просто удалил файл через вебморду и перезалил его заново с нуля. Но осадочек то остался.
                  0
                  Файл образа каждый раз целиком перезаливается?
                    +1
                    Нет.
                    Сам рабочий образ лежал в другом каталоге, и периодически копировался в каталог дропбокса, перезаписывая лежащее там.
                    Вроде как заливались какие-то части при синхронизации (т.е. не целиком он туда фигачился).
                    Через некоторое время похерилась случайно FS. Восстановил систему, и потом данные и тот файл образа из дропбокса (т.е. поставил клиент, и он с сервака вытянул все на диск обратно).
                    И тут, при монтировании его, обнаружил, что версия то образа самая первая, т.е. там не было вообще никаких изменений. По счастливой случайности, у меня бэкап был тогда построен плюс еще и на оффлайновый USB-диск.
                    После этого снес файл образа из вебморды дропбокса, перезалил его, и с тех пор апдейты стали проходить нормально (потом контролировал периодически — все ок было).
                      0
                      То есть, так и не понятно в чем глюк был…
                        +1
                        Но осадочек, как я уже говорил, остался.
                        В общем, я сейчас предпочитаю использовать AWS как основной метод бэкапа важных данных (ну и плюс еще оффлайновый бэкап, просто на всякий случай, и зашифрованные копии в дропбоксе и в gdrive по остаточному принципу (ну мало ли, случаи всякие бывают)). Амазону все-же я как-то больше доверяю, и у меня есть больше контроля над процессом.
                        0
                        Дропбокс бывает совершенно фантастические глюки с версиями выдает. Особенно если синхронизируется несколько мест, файлы держатся открытыми и прочее, бывает башню сносит и наделает этих копий файлов, версии какие-то левые и т. д.
                0
                У меня такая же беда с бэкапом фоток. Копирую новую порцию фотографий — файлы ещё не докопировались, а Яндекс.Диск уже всё синхронизирует. В итоге файлы переименовываются в file (1).jpg. Единственный способ избежать такой проблемы — выключать синхронизацию, перемещать файлы в папку синхронизации, и после того, как они туда легли и их уже ничто не трогает — включать синхронизацию.

                Писал им в техподдержку, ответ был вроде «38000 файлов — это очень много». То есть как баг это не восприняли. Теперь вижу, что не в количестве дело и не я один такой.
              +2
              Спасибо! Как раз подобное решение собирался сделать для своих проектов.
                0
                В свое время начал было тоже ставить синхронизацию с DropBox, но идея не прошла, потому что когда бэкап нужен, то его нужно разворачивать «чем быстрее, тем лучше». А скачивать 10Гб неизвестно откуда в ответственный момент (например, когда все полетело) — большой риск. Поэтому приобрели FTP в сети сервера и все сливается туда.
                Хотя, базы MySQL полезно иметь в DropBox для быстрого скачивания и восстановления.
                  0
                  А зачем что-то скачивать? В тот момент, когда в папку, подключенную к Dropbox, кладется файл, он начинает синхронизироваться со всеми устройствами, подключенными к этой папке. И ничего «скачивать» не нужно, нужно взять файл из папки на сервере.
                    0
                    Я имею ввиду случаи, когда локальная папка не доступна, т.е. в случае полной недоступности системы.
                    Для простого восстановления данных можно вообще никуда ничего не копировать — складывать просто в архив на сервере :)
                      +2
                      Локальная папка где? На бэкап-сервере?
                      Dropbox-аккаунт синхронизируется со всеми компьютерами, к нему подключенными.
                      Имеется аккаунт, и 10 серверов, которые к нему подключены. Все они кладут свои бэкапы в Dropbox.
                      На всех серверах будут копии файлов, которые другие положили. А если легли все 10 серверов — то торопиться уже некуда.
                        0
                        В случае 10-ти серверов — все превосходно, я с вами согласен. Хотя прокачивание бекапа в 10Гб на 10 штук серверов download трафика каждый день — небольшой перебор. Но зависит от тарификации, конечно.
                        У нас просто один сервер, поэтому такой вариант не очень подходит.
                          0
                          Синхронизируйте эту папку с Dropbox-аккаунтом администратора, там есть возможность некоторые папки делать общими для нескольких аккаунтов.
                          Для 10 серверов можно сделать например 10 аккаунтов, или просто подгружать не все папки.
                            0
                            Администратор не хочет качать к себе каждый день 10Гб архив.

                            Кстати, а насколько быстро делается синхронизация? Например отдача 1Гб сколько по времени?
                              0
                              Зависит от канала исключительно.
                              Администратору что — траффика жалко? Ему ничего делать-то не надо, сервер ночью бэкап выгрузил — он ему на машину загрузился к приходу на работу.
                              Или он компьютер на ночь выключает?
                                0
                                Т.е. сам DropBox скорость заливки никак не ограничивает? Какие объемы бэкапа у вас?
                                Трафика, конечно, не жалко и до недавнего времени так и делали: сервер делал копию в 3 часа ночи, сервер на рабочем месте чуть попозже подключался по FTP и забирал копию. Вполне, кстати, работоспособная система для 10-ти серверов и без DropBox :)

                                А когда один раз нужно было закачать архив обратно на сервер, то пару раз были проблемы (канал на отдачу меньше) и приходилось это проделывать несколько раз.
                                  0
                                  Не знаю, не мерял.

                                  У меня — ну где-то по гигу в день с обоих серверов, каждую ночь. У серверов свои аккаунты, у каждого — расшаренна папка с моим аккаунтом. Бэкап в 00:00 по UTC+0, утром я их перемещаю к себе на хранилку.
                                +2
                                А вообще смысл статьи не в призыве использовать Dropbox, а в призыве делать это безопасно ;)
                            0
                            В клиенте есть опция «Выборочная синхронизация».
                      +1
                      Могу посоветовать утилиту Duplicity. Она не только полностью покрывает функционал, описанный в статье, но и избавляет от ненужных телодвижений вроде установки клиента дропбокса.
                        0
                        Спасибо. Не знал, что она уже умеет с дропбоксом работать без клиента.
                        0
                        А зачем ставить dropbox если у него есть api и есть множество готовых скриптов (питон, перл, php, etc)?
                          0
                          А можете объяснить как работает шифрование? А то я не очень понял манипуляции с ключом.
                            +2
                            У GnuPG есть 2 ключа: открытый (публичный) и закрытый (приватный). Публичный ключ можно распространять где хочешь и как хочешь, он используется для шифрования данных (файла, письма, т.д.). А приватный надо хранить у себя в строжайшем секрете, он используется для расшифровки данных.
                            Т.о. автора шифрует публичным ключом бэкапы, а приватный хранит у себя и никому не показывает. Когда понадобится расшифровать бэкап, то автор воспользуется этим приватным ключом.
                            Или вам что-то другое не понятно?
                          +1
                          Да ну. Надежда на публичные сервисы — дополнительная точка отказа. Ну его, такое счастье.
                            0
                            // Промазал комментом. Сорри.
                            0
                            Для дропбокса можно использовать скрипт dropbox_uploader.sh (если по каким-то причинам не хочется ставить клиент) и в скрипт в конце добавить строку типа:
                            /path/to/dropbox_uploader.sh -q upload "$FILE" /backu_srv1/
                              0
                              А почему не использовать для этого Bittorent sync? насколько мне известно из описания, может работать и без интернета(проверить это на практике как то не довелось, но функционал то присутствует). ведь можно автоматические копии сливать в папку( чтобы постоянно канал не занимать) и не затрачивая интернет канал пересылать на нужные зоны хранения. Нужно через интернет пробросить — пожалуйста(это если локалки раздельны и не имеют доступа друг ко другу). Во всяком случае можно быть уверенным, что файлы перешлются даже при разрыве соединения, так как P2P. Ну и естественно дополнительное шифрование для безопасности никто не отменял.
                                0
                                Подтверждаю. Магия. Сам быстро распространяет по локальной сети зеркальные копии синхронизируемых каталогов. Версионирование на уровне хранения в отдельном каталоге старых или удаленных версий файла. Но закрытый исходный код. Зато удобен до безобразия.
                                +2
                                Прошу прощения за откровенность, но заметка ни о чем: все это очевидно каждому, кто знаком с bash. Лучше уж написали бы подробно о duplicity, который может шифровать бэкапы при помощи симметричного шифрования gpg или при помощи открытого ключа, поддерживает инкрементальные бэкапы, и может копировать на: локальный диск, ftp, scp, amazon и другие.

                                Использовал его для копирования шифрованных бэкапов на Amazon, DropBox, флешку и переносной диск.

                                Более гибкое и удобное решение для зашифрованных бэкапов надо еще поискать.
                                  +2
                                  Это не откровенность, а мелкое хамство. «Лучше уж написали бы» — вот и напишите о дуплисити. А автор написал о чем хотел, за что ему спасибо.
                                    0
                                    Статья описывает установку dropbox и написание примитивного скрипта (который можно переписать чуть ли не в одну строку), выполняющего дамп и шифрование базы. До этого за 5 минут дойдет каждый, знакомый с программированием на bash.
                                      0
                                      Так нам ждать ваш топик о дуплисити? :-)
                                        0
                                        Бгг, могу написать :-)
                                          +1
                                          С удовольствием почитаю. Просто всегда интересно посмотреть, способны ли некоторые критики сделать что-то действительно полезное, а не просто языком чесать. :-)
                                            0
                                            Я поискал, о duplicity на Хабрахабре уже писали.
                                              0
                                              Это повод не писать еще одну статью?
                                    0
                                    Совершенно верно, заметка не о дропбоксе. Это написано во втором абзаце, кстати.
                                    Только тут есть один момент: Дропбокс сейчас есть у каждой домохозяйки. У моего папы есть дропбокс, хотя он на компьютере с 1996 года в Diablo в основном играет. И шансов на то, что увидя знакомое слово, кто-то пойдет и сделает себе наконец скрипт резервного копирования — больше, чем на то, что кто-то начнет себе ставить duplicity.
                                    А польза от tutorial'а, которым никто не воспользовался — сомнительна.
                                    0
                                    Скажите только одно — зачем смешивать функции разных сервисов и использовать для резервного копирования то, что предназначено в основном для синхронизации? Есть же прекрасные сервисы специально заточенные под бекапы, работающие в одну сторону, без проблем с копированием открытых файлов, глюками типа внезапного удаления локальных файлов или затирания их какой-то старой версией, потому что дропбоксу чего-то там примерещилось, версионностью хоть на каждые пять минут и т. д? Ведь есть же великолепные backblaze.com и crashplan.com

                                    Only users with full accounts can post comments. Log in, please.