Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Странный Вы, гуглу почту не доверяете, а бэкапы дропбоксу — пожалуйста.
В статье сказано: архивируется 7zip-ом с паролем. Так что, они не смогут прочитать бэкапы.
я бы не был таким категоричным. было бы желание.
Только фантазии за желаемое выдавать не нужно, у 7-zip — AES используется, а для хэширования пароля используется PBKDF2 с sha256 и несколькими сотнями тысяч раундов. Так что TrueCrypt намного проще ломануть.
Особенно если пароль плайнтекстом в скрипте, ага.
Для того, чтобы архивы открыли надо моему хостеру скооперироваться с дропбоксом, что для меня маловероятно.
А зачем хостеру кооперироваться? Дропбоксовые данные у Вас в том же скрипте.
И как это поможет дропбоксовцам или тем кто его ломанет? Откуда они достанут этот скрипт с паролем? С таким же успехом можно про терморектальный криптоанализ вспомнить, но это никакого отношения к 7zip не имеет.
Так эта тема вообще не про 7zip. А про доверие к сервисам. Если уж параноить и не доверять гугломылу и прочим, то надо быть параноиком до конца, и пользовать свои облака. Тем более, что средств для этого придостаточно. Вы так не считаете?
Ну вам отписали, что дропбоксу отправляется только пароленный 7-zip. А Вы сказали, типа его могут открыть при желании, вот только непонятно как им это сделать.
Что касается своего облака, а своё облако, что сломать не могут?
Что касается своего облака, а своё облако, что сломать не могут?
Вы чуть-чуть недопонимаете. Своё облако вы контролируете сами, зная его структуру, определяете политики доступа, следите, кто получает на него доступ. Сможете ли вы опредилить, не синхронизирует ли ваши файлы из дропбокса кто-нибудь еще? Сможете ли вы со 100% увереностью сказать, сколько копий ваших бекапов хранит дропбокс. Ведь получи они пароль от архива, смогут посмотреть всю историю.
Подождите, у нас тут ветка о том, что дропбокс, как вы утверждаете, может получить мои данные, которые я кладу в архив.
Пароль на архив он где найдёт?
Пароль на архив он где найдёт?
Т.е. вы на 100% уверены, что в API который в с дропбокса скачали бэкдора нет? (и быть не может)
Ну, пусть будет и бэкдор, я то ему даю уже зашифрованный файл.
Как-то вы упорно гнёте свою линию, не разобравшись в вопросе…
Как-то вы упорно гнёте свою линию, не разобравшись в вопросе…
А вы этот API видели вообще, или так фантазии на тему? У него как бы открытый исходный код, и никаких бэкдоров там нет, он тупо выполняет HTTP-запросы к API Dropbox, там никакой магии нет.
Как вам уже ответили, алгоритм у 7zip'а хороший, а пароли у меня буквенно-цифровые, в разном регистре и более 15-ти знаков.
Ходят страшилки что клиент читает\хеширует файлы на машине и шлёт куда надо.
Тоже самое бы про облако.mail.ru с шифрованием — так и не придумал куда их 1 Тб использовать.
У меня самого тот же террабайт места, пока только заливаю файлы с шифрованием через BoxCryptor, ведь в cloud.mail.ru пока не разродились API.
Есть 400 гигабайт Яндекс.Диска за закрытие Яндекс.Видео и баг, который убивал винду.
Вот всё думаю сделать бекапы туда. Тем более, что там WebDav и его можно подмонтировать просто разделом в систему.
Вот всё думаю сделать бекапы туда. Тем более, что там WebDav и его можно подмонтировать просто разделом в систему.
Для инкрементных бекапов подходит 7z-архив (http://a32.me/2010/08/7zip-differential-backup-linux-windows/). Удалённые папки/файлы не останутся.
Главное иметь отдельный dropbox аккаунт только для бэкапов, иначе в случае взлома любого из ваших серверов, запороленные бэкапы не представляют ценность, а другая информация из соседних папок может оказаться ценнее пароля на zip архив )
То есть, вы считаете, что заполучив мой скрипт бэкапа с паролем, используемым для архивирования, злоумышленник получит доступ к аккаунту дропбокса?
Если так, то вы не очень внимательно читали статью.
1. Для бэкапа создается виртуальное «приложение» (как, например, приложения в VK), которое имеет доступ только к своей папке.
2. Пароль для архивирования не такой же, как пароль к дропбоксу.
Если так, то вы не очень внимательно читали статью.
1. Для бэкапа создается виртуальное «приложение» (как, например, приложения в VK), которое имеет доступ только к своей папке.
2. Пароль для архивирования не такой же, как пароль к дропбоксу.
Может лучше на MEGA? MEGAsync for Linux
У меня для бэкапов есть отдельный аккаунт dropbox, и я поставил в крон простой bash-скрипт, который c помощью rdiff-backup ежедневно скидывает инкрементальные бэкапы определенных папок из /var/www в папку дропбокса. Еще туда сбрасываются дампы баз данных MySQL для указанных сайтов. Если кому-то интересно, подробнее можно ознакомиться здесь
Тут же уже была отличная статья. Пароли это зло, они утекают. А правильный выход это pgp и на сервере только публичный ключ для которого будут шифроваться данные.
Я себе так настроил.
Я себе так настроил.
gpg --trust-model=always --yes -e -r 0xId_pgp_key -o crypted.sql.gz.pgp source.sql.gz
Я для резервного копирования приспособил Яндекс.Диск и утилиту ydcmd. А для экономии места в облаке сжимаю данные zpaq в инкрементальные архивы — для моих данных сжатие получается существенно лучше чем у 7z.
Присматривался к bitcasa за ее дешевизну (объемы достаточно большие и цена играет роль), но невозможность удалять файлы помноженная на странный способ адресации объектов в хранилище свела на нет все кажущиеся преимущества.
Присматривался к bitcasa за ее дешевизну (объемы достаточно большие и цена играет роль), но невозможность удалять файлы помноженная на странный способ адресации объектов в хранилище свела на нет все кажущиеся преимущества.
Т.е. сначала с zpaq делаем архив папок и потом кладем в я.диск?
Да. Что-то в стиле:
Такая команда будет создавать зашифрованные инкрементальные архивы вида user.001.zpaq, user.002.zpaq и т.д. При этом первый архив может быть достаточно большой (полный), остальные содержат только измененные части. Если между вызовами файлы не изменились, то дополнительного архива просто не создается.
Такая схема позволяет уменьшить трафик (т.к. нужно загружать только дельты), ну и сам zpaq сжимает достаточно неплохо (особенно, скажем, дампы баз).
Единственное неудобство для меня было в том, что в Debian версия zpaq достаточно старая и приходилось на каждом сервере собирать руками. В конечном итоге это надоело и сделал для себя пакет zpaq-upstream.
$ zpaq a '/home/backup/user.???.zpaq' /home/user -threads 4 -method 5 -quiet -key 123456
Такая команда будет создавать зашифрованные инкрементальные архивы вида user.001.zpaq, user.002.zpaq и т.д. При этом первый архив может быть достаточно большой (полный), остальные содержат только измененные части. Если между вызовами файлы не изменились, то дополнительного архива просто не создается.
Такая схема позволяет уменьшить трафик (т.к. нужно загружать только дельты), ну и сам zpaq сжимает достаточно неплохо (особенно, скажем, дампы баз).
Единственное неудобство для меня было в том, что в Debian версия zpaq достаточно старая и приходилось на каждом сервере собирать руками. В конечном итоге это надоело и сделал для себя пакет zpaq-upstream.
Попробуйте BitTorrent Sync www.bittorrent.com/sync — данные только на ваших серверах, без посредника
Не вижу в вашем случае зачем нужно делать инкрементальные бэкапы. Dropbox идеально сам справляется с этой задачей. Сохраняете каждый день свой полный бэкап под одним и тем же именем, а Dropbox позаботится о версионности. Сейчас посмотрел у себя — у файл бэкапа доступно последние 30 версий, при этом файл занимает всего 1.5Гб.
Так как приложение ограничено только своей директорией, то можно не боятся, что в случае компрометации вашего приложения уйдет что-то еще кроме бэкапов.
У нас в Plesk'e мы решили проблему хранения бэкапов на внешних источниках тем, что шифруем пароли и подписываем сам бэкап. И да, у нас есть расширение для хранения бэкапов в Dropbox'e:
devblog.plesk.com/2013/10/dropbox-backup-extension/
devblog.plesk.com/2014/07/dropbox-backup-2-0/
Если интересно, могу подготовить обзор на русском языке.
Так как приложение ограничено только своей директорией, то можно не боятся, что в случае компрометации вашего приложения уйдет что-то еще кроме бэкапов.
У нас в Plesk'e мы решили проблему хранения бэкапов на внешних источниках тем, что шифруем пароли и подписываем сам бэкап. И да, у нас есть расширение для хранения бэкапов в Dropbox'e:
devblog.plesk.com/2013/10/dropbox-backup-extension/
devblog.plesk.com/2014/07/dropbox-backup-2-0/
Если интересно, могу подготовить обзор на русском языке.
Я просто не хочу каждые сутки перекачивать 1,5гб с сервера на дропбокс и по те же 1,5гб на каждый из подключенных компов. Еще раз поясню — клиент дропбокса не используется, некому считать хэши кусков и т.п. За то полный бэкап у меня сейчас большой, а каждые сутки архивируется примерно по 30мб, если не заливать в бложики видеофайлы.
Если файлы шифруются, то они будут каждый раз разные (так как любая более-менее нормальная софтина для шифрования каждый раз использует как минимум разные векторы инициализации, а скорее всего еще и случайные ключи). Так что каждый день качать 1,5 гига на dropbox сомнительное удовольствие.
Маленькое уточнение для нубов. Первый скрипт нужно назвать как-нибудь оригинально, например mydropbox.py
Я же наступил на грабли — dropbox.py
Traceback (most recent call last):
File "./dropbox.py", line 6, in <module>
import dropbox
File "/home/dropbox.py", line 13, in <module>
flow = dropbox.client.DropboxOAuth2FlowNoRedirect(app_key, app_secret)
AttributeError: 'module' object has no attribute 'client'Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бэкап файлов, базы данных и настроек сервера в Dropbox