![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опять про бэкапы
Sep. 15th, 2014 12:44 amЯ тут писал как-то про разделение-разбиение файлов по папкам для более удобного бэкапа/синхронизации двух ноутбуков, с тех пор система несколько эволюционировала.
Я долго искал удобную утилиту бэкапа на удаленное хранилище, экспериментировал с различными сервисами (даже одно время безуспешно отлаживал поделку ребят Кима Доткома). В конце концов где-то полгода назад я остановился на проекте syncany, оупенсорсном, на джаве, после некоторой допилки .synignore которого вполне можно было бэкапить рабочие папки с горячими рабочими файлами фильтруя всякий треш типа .obj, .tmp, .opt, .ilk и прочего, чем обычно вижлстудия (и другие системы сборки) гадият в рабочих каталогах. Шифрование файлов происходит на клиенте, поддерживаются удаленные стораджи, от FTP и WebDav, до SFTP и амазоновских хранилищ. На удаленной стороне формируется нечто вроде файловой системы из динамического количества чанков определенной длины, которыми можно достаточно удобно удаленно манипулировать, обеспечивая обновление файлов без лишнего оверхеда. До отправки производится полная дедупликация и сжатие. Бонусом является хранение версий файлов, которые несколько геморройно вытаскивать, но сам факт радует. Работает оно из консоли, интерфейсом очень напоминает svn (от которого отличается наличием сравнительно простой процедуры удаления старых копий файлов из хранилища).
Короче говоря, я так жил какое-то время, само хранилище хостил у себя на VPS-ке где-то в Германии (в сжатом дедуплицированном виде получалось около 20 ГБ), но паранойя и ценовые воины за место между дропбоксом, эпплом и майкрософтом привели к мысли что пора бы это дело более надежно организовать. Готового нового решения я пока не нашел, но требования вырисовываются такие:
-- хранить одну репу syncany на удаленном своем сервере, использовать для синка между тачками (т.е. заливать-сливать может несколько машин, мастер-мастер, как сейчас). это праймари сайт, дальше идут бэкапы
-- опционально эта репа с удаленного сервера должна миррориться на проприетарный клауд-сторадж1 (мастер-слейв), на всякий случай
-- должен существовать отдельный от syncany механизм дублирования, который должен миррорить файлики на проприетарный клауд-сторадж2 и на флешку воткнутую в машину, обеспечивая шифрование (это мастер-слейв, без возможности синка с другими тачками)
Если с первыми двумя все понятно, то с третьим не совсем. Кроме как засунуть все в трукрипт-контейнер (копируя в него изменения), а его уже засунуть в уандрайв и миррорить на флешку, идей пока не нашлось.
Я долго искал удобную утилиту бэкапа на удаленное хранилище, экспериментировал с различными сервисами (даже одно время безуспешно отлаживал поделку ребят Кима Доткома). В конце концов где-то полгода назад я остановился на проекте syncany, оупенсорсном, на джаве, после некоторой допилки .synignore которого вполне можно было бэкапить рабочие папки с горячими рабочими файлами фильтруя всякий треш типа .obj, .tmp, .opt, .ilk и прочего, чем обычно вижлстудия (и другие системы сборки) гадият в рабочих каталогах. Шифрование файлов происходит на клиенте, поддерживаются удаленные стораджи, от FTP и WebDav, до SFTP и амазоновских хранилищ. На удаленной стороне формируется нечто вроде файловой системы из динамического количества чанков определенной длины, которыми можно достаточно удобно удаленно манипулировать, обеспечивая обновление файлов без лишнего оверхеда. До отправки производится полная дедупликация и сжатие. Бонусом является хранение версий файлов, которые несколько геморройно вытаскивать, но сам факт радует. Работает оно из консоли, интерфейсом очень напоминает svn (от которого отличается наличием сравнительно простой процедуры удаления старых копий файлов из хранилища).
Короче говоря, я так жил какое-то время, само хранилище хостил у себя на VPS-ке где-то в Германии (в сжатом дедуплицированном виде получалось около 20 ГБ), но паранойя и ценовые воины за место между дропбоксом, эпплом и майкрософтом привели к мысли что пора бы это дело более надежно организовать. Готового нового решения я пока не нашел, но требования вырисовываются такие:
-- хранить одну репу syncany на удаленном своем сервере, использовать для синка между тачками (т.е. заливать-сливать может несколько машин, мастер-мастер, как сейчас). это праймари сайт, дальше идут бэкапы
-- опционально эта репа с удаленного сервера должна миррориться на проприетарный клауд-сторадж1 (мастер-слейв), на всякий случай
-- должен существовать отдельный от syncany механизм дублирования, который должен миррорить файлики на проприетарный клауд-сторадж2 и на флешку воткнутую в машину, обеспечивая шифрование (это мастер-слейв, без возможности синка с другими тачками)
Если с первыми двумя все понятно, то с третьим не совсем. Кроме как засунуть все в трукрипт-контейнер (копируя в него изменения), а его уже засунуть в уандрайв и миррорить на флешку, идей пока не нашлось.
Star Trek stabilized
May. 31st, 2014 05:39 pmСтабилизированные сцены из TOS и TNG, где камера "трясется" эмулируя тряску корабля. Представляю как весело было снимать это в несколько дублей :)
http://i.imgur.com/4A7Yolq.gif
http://i.imgur.com/e8Aw6h6.gif
http://www.reddit.com/r/StarTrekStabilized
http://i.imgur.com/4A7Yolq.gif
http://i.imgur.com/e8Aw6h6.gif
http://www.reddit.com/r/StarTrekStabilized
Чего-то я не понимаю как это поделие Кима Доткома работает. Заявлено, что все шифрование выполняется на стороне клиента, и на стороне сервера никто ничего декодировать не может. В принципе это круто, если ключем является пароль, то это то что нужно. Никто кроме знающего пароль файлики не расшифрует (кстати, у них клиент умеет эксклюдить файлы по маске, что очень хорошо).
Однако ж, решил проверить. Скачал прогу синхронизации, зарегился с простым паролем. Прожка попросила валидировать имейл, в письме была ссылочка, по которой открылась страничка с арканойдом и блоками в форме букв NSA :) Типа, так они энтропию собирают для создания RSA ключа. Окей, сгенерили ключик.
Далее забавно. Я пошел на сайт и сменил пароль на более крутой. По-идее, подключенный клиент должен был тут же возмутиться и спросить новый пароль. Однако ж, я добавил в сторадж новый файл через клиент и тот успешно его зааплоадил, файл потом открылся через браузер (скачался и декодировался локально жабаскриптом). Опа. Обратный трюк тоже работает, если зааплоадить файл через сайт (в браузере вбит новый пароль), то тот успешно скачивается клиентом и открывается.
Собственно, выходит что кодируется файл нифига не паролем, а каким-то ключиком полученным с сайта. Или я чего-то не понимаю в криптографии, или заявление что никто кроме юзера не может раскодировать данные - просто маркетинговый булшит.
UPD: Я тут еще немного подумал, скорее всего они с введением возможности менять пароль изменили саму схему шифрования:
Логично предположить что теперь у них паролем защищены сами сгерененные ключи (как с ssh ключами, например) и чтобы декодировать данные нужно с начала декодировать ключик.
Тогда понятно, что ключ сам не меняется, а при смене пароля они его тупо декодируют старым и заново защищают новым паролем.
И тогда понятно почему на локальном клиенте все декодируется, потому что ключ де-факто не менялся.
Т.е. фактически на серваке меги лежит пара - публичный (для шифрования) и приватный (для дешифрования) ключики, приватный при этом защищен паролем юзера. Но все равно как-то неуютно, при такой схеме вполне незаметно для юзера можно вообще не защищать ключи.
Однако ж, решил проверить. Скачал прогу синхронизации, зарегился с простым паролем. Прожка попросила валидировать имейл, в письме была ссылочка, по которой открылась страничка с арканойдом и блоками в форме букв NSA :) Типа, так они энтропию собирают для создания RSA ключа. Окей, сгенерили ключик.
Далее забавно. Я пошел на сайт и сменил пароль на более крутой. По-идее, подключенный клиент должен был тут же возмутиться и спросить новый пароль. Однако ж, я добавил в сторадж новый файл через клиент и тот успешно его зааплоадил, файл потом открылся через браузер (скачался и декодировался локально жабаскриптом). Опа. Обратный трюк тоже работает, если зааплоадить файл через сайт (в браузере вбит новый пароль), то тот успешно скачивается клиентом и открывается.
Собственно, выходит что кодируется файл нифига не паролем, а каким-то ключиком полученным с сайта. Или я чего-то не понимаю в криптографии, или заявление что никто кроме юзера не может раскодировать данные - просто маркетинговый булшит.
UPD: Я тут еще немного подумал, скорее всего они с введением возможности менять пароль изменили саму схему шифрования:
Логично предположить что теперь у них паролем защищены сами сгерененные ключи (как с ssh ключами, например) и чтобы декодировать данные нужно с начала декодировать ключик.
Тогда понятно, что ключ сам не меняется, а при смене пароля они его тупо декодируют старым и заново защищают новым паролем.
И тогда понятно почему на локальном клиенте все декодируется, потому что ключ де-факто не менялся.
Т.е. фактически на серваке меги лежит пара - публичный (для шифрования) и приватный (для дешифрования) ключики, приватный при этом защищен паролем юзера. Но все равно как-то неуютно, при такой схеме вполне незаметно для юзера можно вообще не защищать ключи.
Облачные бэкапы
Mar. 24th, 2014 04:31 amС переездами с ноутбука на ноутбук снова посетила мысля о том, что неплохо было бы все хозяйство зааплоадить куда-нибудь в интернет (и даже возможно разделить офисный бук и домашний, сохранив общую среду). Структурировано оно уже неплохо (я когда-то писал уже про это) и весь переезд заключается в копировании одной папки и запуске пары скриптов для создания junction points (симлинков, типа).
В простейшем случае можно было бы купить подписку на несколько десятков гигабайт от dropbox/msft/google, но есть две проблемки:
1. ключи и пароли. какой-нибудь дропбокс традиционно хранит свою аутентификацию на кучке девайсов, потеря одного автоматически компромайзит все, что совсем не круто
2. синхронизировать нужно проектные файлы тоже, а всякие там студии при сборке рядом раскладывают гигабайты сборочных файлов. которые в принципе нужны, но бэкапить их совершенно незачем
Я года два-три назад писал про гуглодрайв, когда он только вышел, что удивлен, что они как и дропбокс не сделали возможность синхронизировать файлы по маске (или хотя бы эксклюдить по маске). С тех пор, если я правильно понимаю, ничего не изменилось.
В итоге имеем два реквайрмента:
1. выбор файлов для синхронизации по маске
2. шифрование
С локальными бэкапами все просто. Сервачок, шара, раз в сутки умный скриптик по маске жмет файлики из нужных подразделов в зашифрованный архив и кладет на шару.
С облаками как-то непросто все получается.
Я пока вижу два одинаково странных варианта:
1. заюзать утилиту CryptSync, которая умеет миррорить каталоги сжимая каждый файл отдельно в запароленный 7zip архив (результирующий каталог - синхронизируется в интернет)
2. rcync'аться по маске в отдельный TrueCrypt раздел, а уже его в виде огромного блоба синхронизировать в интернет
Оба варианта в виде фичи имеют необходимость во второй копии файлов. Первый при этом шифрует каждый файл отдельно, что с точки зрения криптографии не очень гуд (хотя я не от NSA защищаюсь). Второй - сильно зависит от способности клиента конкретного сервиса детектить изменения по блокам, а не тупо аплоадить файл при каждом изменении.
А еще, говорят, что у Amazon AWS есть вполне удобное API, к нему можно написатьвелосипедклиента, который будет делать выборку по маске и шифровать самостоятельно.
В простейшем случае можно было бы купить подписку на несколько десятков гигабайт от dropbox/msft/google, но есть две проблемки:
1. ключи и пароли. какой-нибудь дропбокс традиционно хранит свою аутентификацию на кучке девайсов, потеря одного автоматически компромайзит все, что совсем не круто
2. синхронизировать нужно проектные файлы тоже, а всякие там студии при сборке рядом раскладывают гигабайты сборочных файлов. которые в принципе нужны, но бэкапить их совершенно незачем
Я года два-три назад писал про гуглодрайв, когда он только вышел, что удивлен, что они как и дропбокс не сделали возможность синхронизировать файлы по маске (или хотя бы эксклюдить по маске). С тех пор, если я правильно понимаю, ничего не изменилось.
В итоге имеем два реквайрмента:
1. выбор файлов для синхронизации по маске
2. шифрование
С локальными бэкапами все просто. Сервачок, шара, раз в сутки умный скриптик по маске жмет файлики из нужных подразделов в зашифрованный архив и кладет на шару.
С облаками как-то непросто все получается.
Я пока вижу два одинаково странных варианта:
1. заюзать утилиту CryptSync, которая умеет миррорить каталоги сжимая каждый файл отдельно в запароленный 7zip архив (результирующий каталог - синхронизируется в интернет)
2. rcync'аться по маске в отдельный TrueCrypt раздел, а уже его в виде огромного блоба синхронизировать в интернет
Оба варианта в виде фичи имеют необходимость во второй копии файлов. Первый при этом шифрует каждый файл отдельно, что с точки зрения криптографии не очень гуд (хотя я не от NSA защищаюсь). Второй - сильно зависит от способности клиента конкретного сервиса детектить изменения по блокам, а не тупо аплоадить файл при каждом изменении.
А еще, говорят, что у Amazon AWS есть вполне удобное API, к нему можно написать
Хороший коммент на хабре
Dec. 15th, 2013 01:52 amВ теме о покупке гуглом компании MassiveBoston Dynamics (это та, которая собакоробота безголового сделала пару лет назад, а сейчас экспериментирует с первыми прототипами сайлонов).
> Сочетание «поисковый робот Google» приобретает новый, зловещий, оттенок.
>> вы будете рассказывать внукам о временах, когда поисковые роботы не умели заходить в дома
> Сочетание «поисковый робот Google» приобретает новый, зловещий, оттенок.
>> вы будете рассказывать внукам о временах, когда поисковые роботы не умели заходить в дома
http://web.mit.edu/newsoffice/2013/simple-scheme-for-self-assembling-robots-1004.html
http://www.youtube.com/watch?v=6aZbJS6LZbs
Reminds me of Replicators from Stargate.
http://www.youtube.com/watch?v=6aZbJS6LZbs
Reminds me of Replicators from Stargate.
