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 для нормальной автоматизации инкрементальных резервных копий.
Рискую нарваться на минусы и потоки ненависти, но мне не понравилось.
Duplicity была настроена у моих коллег для дифференциального резервного копирования объёмных (около 25 Гб в сумме) сайтов. Возможно, мы уделили мало времени на изучение работы этой утилиты, но экспериментировать было некогда — сайт уже работал. Небольшой сбой при передаче данных, например разрыв ftp-соединения (манифест не записался целиком), может привести к состоянию, когда копию развернуть не получается, и приходится либо очищать папку с копией и делать полный бэкап, либо «разворачивать» вручную. В конце концов вернулись к обычному tar/bzip и bash-скриптам. Да, неэкономно, но полностью прозрачно и видно на каком этапе произошла ошибка и что делать, если что-то пошло не так.
Duplicity была настроена у моих коллег для дифференциального резервного копирования объёмных (около 25 Гб в сумме) сайтов. Возможно, мы уделили мало времени на изучение работы этой утилиты, но экспериментировать было некогда — сайт уже работал. Небольшой сбой при передаче данных, например разрыв ftp-соединения (манифест не записался целиком), может привести к состоянию, когда копию развернуть не получается, и приходится либо очищать папку с копией и делать полный бэкап, либо «разворачивать» вручную. В конце концов вернулись к обычному tar/bzip и bash-скриптам. Да, неэкономно, но полностью прозрачно и видно на каком этапе произошла ошибка и что делать, если что-то пошло не так.
ага, duplicity всегда мне казалась слишком не надёжной для backup тулзы, в конце концов она beta + внушительный список багов bugs.launchpad.net/duplicity
как альтернативу выбрал пока DAR.
как альтернативу выбрал пока DAR.
Фича реквест к селектелу. Хотелось бы, когда создаешь ссылку на файл из облачного хранилища, иметь возможность сразу указать, хочется его скачать по https протоколу. Добавьте что ли галочку в форме.
ИМХО обертка в виде backupninja удобней.
Есть ещё duplicati.
Понравился на нём GUI клиент для Windows. Заявляют, что он есть для Linux и Mac OS.
The Duplicati project was inspired by duplicity. Duplicati and duplicity are similar but not compatible. Понравился на нём GUI клиент для Windows. Заявляют, что он есть для Linux и Mac OS.
Sign up to leave a comment.
Duplicity — резервное копирование с шифрованием