Pull to refresh

Comments 23

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

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

# Выполнение архивирования 
duplicity list-current-files --encrypt-key "<ключ шифрования>" --sign-key "<ключ подписи>" swift://имя контейнера в хранилище


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

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

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

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

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

как альтернативу выбрал пока DAR.
Фича реквест к селектелу. Хотелось бы, когда создаешь ссылку на файл из облачного хранилища, иметь возможность сразу указать, хочется его скачать по https протоколу. Добавьте что ли галочку в форме.
Фичреквесты значительно эффективнее делать через тикет-систему.
Есть ещё duplicati.
The Duplicati project was inspired by duplicity. Duplicati and duplicity are similar but not compatible.
Понравился на нём GUI клиент для Windows. Заявляют, что он есть для Linux и Mac OS.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
selectel.ru
Employees
501–1,000 employees
Registered

Habr blog