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

  • Tutorial
Duplicity

О возможностях использования нашего облачного хранилища для резервного копирования мы уже писали. Архивирование и резервное копирование в хранилище осуществляется при помощи широкого спектра программного обеспечения; на нашем сайте опубликован список таких программ, который регулярно пополняется.

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

Зачем нужно шифрование?


Резервное копирование, как известно, нужно для того, чтобы обеспечить сохранность наиболее ценной и важной информации. Само по себе сохранение резервной копии в удаленном хранилище (пусть даже в самом надежном) не является достаточной мерой для ее защиты. О том, что абсолютно вся наша информация уязвима и может быть использована против нас, сегодня не говорит только ленивый. В новостях то и дело появляются сообщения об ухищрениях, которые киберпреступники используют для получения доступа к секретным документам. Полгода назад никому ранее не известный американский гражданин Эдвард Сноуден вызвал немалый переполох во всем мире, рассказав о том, как спецслужбы используют информационные технологии для слежки за людьми.

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

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

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

Duplicity поддерживает различные протоколы для соединения с файловым сервером: SSH/SCP, FTP, HSI, WebDAV, Tahoe-LAFS и Amazon S3. С поддержкой OpenStack Swift дело обстоит несколько сложнее.

На официальной man-странице указано, что для этого нужны дополнительные модули и плагины, но не дано подробных рекомендацией по их установке и настройке. Ниже мы расскажем о том, как «подружить» Duplicity с нашим хранилищем.

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


Программа Duplicity включена в репозитории большинства современных Linux-систем и устанавливается при помощи стандартного менеджера пакетов:

$ sudo apt-get install duplicity


Для работы с облачным хранилищем на клиентской машине должны быть обязательно установлены пакеты python-swiftclient и librsync:

$ sudo apt-get install python-swiftclient
$ sudo apt-get install librsync-dev


Теперь нужно установить плагин swiftbackend. Сначала клонируем с launchpad соответствующий репозиторий (для этого на клиентскую машину потребуется также установить систему контроля версий Bazaar — Launchpad использует именно ее):

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


Затем выполним следующую команду:

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


По завершении установки Duplicity будет готова к работе с облачным хранилищем.

Настройка резервного копирования


Теперь откроем любой текстовый редактор и напишем небольшой скрипт для резервного копирования:

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

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

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


Сохраним этот файл под именем, например, backup.sh и сделаем его исполняемым (chmod +x backup.sh). После этого выполним следующую команду:

$ ./backup.sh


Далее GnuPG попросит кодовое слово для доступа к файлам.
После этого начнется резервное копирование. Статистка будет отображена в консоли:

--------------[ Статистика резервного копирования ]--------------
StartTime 1391068911.00 (Thu Jan 30 12:01:51 2014)
EndTime 1391068911.02 (Thu Jan 30 12:01:51 2014)
ElapsedTime 0.02 (0.02 seconds)
SourceFiles 5
SourceFileSize 190210 (186 KB)
NewFiles 5
NewFileSize 190210 (186 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 5
RawDeltaSize 186114 (182 KB)
TotalDestinationSizeChange 185217 (181 KB)
Errors 0
-----------------------------------------------------------------


В указанный контейнер облачного хранилища будут добавлены новые файлы:

duplicity-full-signatures.20140130T073550Z.sigtar.gpg
duplicity-full.20140130T073550Z.manifest.gpg
duplicity-full.20140130T073550Z.vol1.difftar.gpg


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

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


Сохраним этот скрипт под именем restore.sh и сделаем соответствующий файл исполняемым.

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

Читателей, не имеющих возможности комментировать посты на Хабре, приглашаем к нам в блог.

Selectel

110,00

ИТ-инфраструктура для бизнеса

Поделиться публикацией
Комментарии 23
    +1
    Судя по информации на сайте GnuPG, она также поддерживает асимметричное шифрование.
    ИМХО, было бы интересно увидеть мануал именно с его использованием, так как с симметричным настроить автоматические бэкапы не получится, не храня ключ на сервере. В моей практике(и допускаю что не только в моей), большинство бэкапов делается автоматически, а не в ручном режиме.
      +1
      Проще всего шифровать предварительно файл архива AES через тот же openssl, почти везде есть аппаратная поддержка AES( ну может только в атомах нет), процесс занимает секунду :)
      openssl aes-256-cbc -in backup.tar -out backup.tar.aes -password:pass
        +2
        Спасибо за замечание. Для резервного копирования с ассиметричным шифрованием скрипт будет выглядеть так:

        # Авторизационые данные для подключения к хранилищу
        export SWIFT_USERNAME="имя пользователя"
        export SWIFT_PASSWORD="пароль для входа в хранилище"
        export SWIFT_AUTHURL="https://auth.selcdn.ru"
        
        # Выполнение архивирования 
        duplicity list-current-files --encrypt-key "<ключ шифрования>" --sign-key "<ключ подписи>" swift://имя контейнера в хранилище
        


          +1
          Спасибо.
          0
          AES симметричный алгоритм, а значит надо хранить на сервере ключ шифрования в открытом виде, что не есть хорошо. Хотя скорость симметричного шифрования действительно будет выше.
            +1
            Имхо, если получили доступ к серверу, то уже нет разницы, чем и как был шифрован бэкап.
          0
          А что мешает хранить на сервере просто публичный ключ — ним ведь можно только зашифровать данные?
          А для восстановления уже брать закрытый из надежного источника…
            0
            ничего не мешает. именно с этой целью я и спрашивал про ассиметричное шифрование.
          +3
          Почему-то, прочитав заголовок, я думал, что будет подробная статья…
          А как же рассказать про инкрементальные бэкапы? Про ротацию старых бэкапов? Про просмотр файлов в бэкапе?
            +1
            Мне тоже эта система кажется какой-то громоздкой. Лично я предпочитаю делать резервные копии при помощи cryptfs, который не собирает все файлы в один архив, а оставляет их россыпью, но шифруя в том числе и имена. Это позволяет очень серьезно экономить трафик и элементарно автоматизируется через обычный механизм монтирования простым bash-скриптом. При гибкость этого механизма в том, что не важно куда направляется резервная копия: на ftp, dav или в dropbox — разницу этих технологий скрывает за собой fuse, а cryptfs, расположенный поверху, скрывает данные от провайдеров этих хранилищ.
              0
              Во-первых, тут речь о бэкапах, в первую очередь на серверах, cryptfs/encfs в дропбоксе для этого не подходят. Ну, а во-вторых, исходя из личного опыта вы будете пользоваться им до тех пор, пока не потеряете свои данные. Я год пользовался :)
                0
                Не кривите душой. FUSE дает не меньше, а даже больше вариантов хранилищ (даже такие экзотические, как GridFS, Gitfs, gmailfs). Дело не в дропбоксе, как вы выразились, а в том, что при наложении cryptfs/encfs на любую обычную файловую систему (а fuse превращает в нее почти что угодно), с файлами в ней можно прозрачно работать, например для создания инкрементальных резервных копий, не выгружая весь архив. Вы, в данном случае, просто пропагандируете собственную инфраструктуру хранилищ, а не новый способ сохранения резервных копий. Так что не берите на себя так уж много, утверждая, что только ваш подход обеспечивает сохранность данных. Лучше сосредоточтесь на недостатках вашего решения — например архитектурной проблеме с инкрементальными резервными копиями.
                  0
                  Да ради бога, я никому ничего не навязываю. Просто у меня есть негативный опыт, которым я поделился. Конкретно работы encfs+dropbox на десктопе, когда файлы бьются в процессе синхронизации и вы теряете данные. Проблем с инкрементальными резервными копиями на серверах у меня нет, rsync — наше всё.
                    0
                    Просто у меня есть негативный опыт, которым я поделился. Конкретно работы encfs+dropbox на десктопе

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

                    Проблем с инкрементальными резервными копиями на серверах у меня нет, rsync — наше всё.

                    Вот об этом я и талдычу! fuse+cryptfs при всех прочих равных (зашифрованном сетевом хранилище) дают работать rsync для нормальной автоматизации инкрементальных резервных копий.
                      0
                      Хорошо. Рассмотрим ситуацию. Что произойдет, если ваша сетевая fs отвалится? Канал там, например, или сам сервер с бэкапами. Если отвалится в процессе этого самого инкрементального бэкапа? Не будем рассматривать экзотические, а к примеру sshfs, ftpfs.
                        0
                        придется повторить rsync :) fuse берет на себя и перезапуск соединений и обработку ошибок, так что будет то же самое, что и с обычной файловой системой — надо только следить за статусами операций.
              +4
              Рискую нарваться на минусы и потоки ненависти, но мне не понравилось.

              Duplicity была настроена у моих коллег для дифференциального резервного копирования объёмных (около 25 Гб в сумме) сайтов. Возможно, мы уделили мало времени на изучение работы этой утилиты, но экспериментировать было некогда — сайт уже работал. Небольшой сбой при передаче данных, например разрыв ftp-соединения (манифест не записался целиком), может привести к состоянию, когда копию развернуть не получается, и приходится либо очищать папку с копией и делать полный бэкап, либо «разворачивать» вручную. В конце концов вернулись к обычному tar/bzip и bash-скриптам. Да, неэкономно, но полностью прозрачно и видно на каком этапе произошла ошибка и что делать, если что-то пошло не так.
                0
                ага, duplicity всегда мне казалась слишком не надёжной для backup тулзы, в конце концов она beta + внушительный список багов bugs.launchpad.net/duplicity

                как альтернативу выбрал пока DAR.
                +1
                Bacula также поддерживает шифрование:
                www.bacula.org/en/dev-manual/main/main/Data_Encryption.html
                  0
                  Фича реквест к селектелу. Хотелось бы, когда создаешь ссылку на файл из облачного хранилища, иметь возможность сразу указать, хочется его скачать по https протоколу. Добавьте что ли галочку в форме.
                    +1
                    Фичреквесты значительно эффективнее делать через тикет-систему.
                    0
                    ИМХО обертка в виде backupninja удобней.
                      +2
                      Есть ещё duplicati.
                      The Duplicati project was inspired by duplicity. Duplicati and duplicity are similar but not compatible.
                      Понравился на нём GUI клиент для Windows. Заявляют, что он есть для Linux и Mac OS.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое