Анонимный и безопасный бэкап данных

анонимный и безопасный бэкап данных

Tahoe?

что все же лучше брать для это цели – дедик или впн с большим виртуальным "диском"? Мне кажется, что все равно, но может быть какие есть соображения?

Дедик по умолчанию лучше защищён от атаки уборщицы, как мне кажется.

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

Основной ключ (пароль) должен быть в голове, остальное шифруется им.

Если делать криптоконтейнер, то криптоконтейнер с полутерабайтом данных заколебешься через сеть передавать на сервер.

Но как-то же они должны туда быть переданы, не через астрал же.

как передавать данные, чтобы противник не узнал, где ты их хранишь? Если через Tor, то опять таки очень долго передавать данные объемом полутерабайт – терабайт.

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

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

Если хочется регулярно обновлять бэкап, есть программы^*, которые это делают без передачи всех файлов. В любом случае придётся либо делать удалённую ФС с ключами на локальной машине^**, либо всё нужное шифровать и высылать на удалённый сервер цельным файлом.

Есть какие-нибудь идеи?

Почти все соображения уже высказывались тут, если что. Лучше бы свой вопрос там и задавали в продолжение дискуссии.

^*Не уверен, что именно это умеет rsync.
^**eCryptFS, EncFS? Обсуждались они тут ранее.

Есть немного. Подойдут ли?
Я, например, важные данные не доверяю облакам. Понятно, многие не согласятся с такой позицией и будут правы в какой-то мере. Однако, мало что меня может заставить лить важные или критически важные данные на удаленные хосты в целях бэкапа. Зашифровать и залить всегда можно. Можно это сделать довольно оперативно и в приличных объемах, в том числе анонимно (через Tor). Но будут ли они там в надежности и сохранности? Как с ними потом работать? В каком виде они там должны быть? Для чего? К тому же данные могут быть разные, у каждого свое понятие критичности и оценка важности.
Вот у вас 500-1000 Гб данных. Залить их куда-то на скорости 1 мегабайт в секунду займет в сферическом вакууме около недели-двух. Tor может обеспечить такую скорость и по дефолту на быстрых нодах и при выборе цепочек индивидуально. Т.е., в реальности на это уйдет грубо говоря месяц-полтора. Допустим все уже на серваке в Конконге. Дальше что? С данными надо как-то работать, платить за нехилое пространство. Удобством, оперативностью, гибкостью, надежностью и мобильностью это назвать сложно. разве что анонимностью и только.


Это правда? Как восстанавливали? С чего, если все вынесли изъяли?
Вы не предусмотрели вариант, когда силовые структуры вторгаются к вам в помещение. Допустить обыск, засветиться – уже ошибка. Которую можно исправить, предусмотрев ее. Но еще лучше ее избежать и учится на чужих.

Хранить 0,5-1 Тб бэкапа можно на съемном зашифрованном HDD. И все проблемы с каналами, аптаймом и пр. головной болью уходят. 2,5 дюйма, пара сотен граммов и пара тысяч рублей – вот и вся цена вопроса. Репликация данных на разные носители, хранящиеся в разных местах. Когда речь идет о действительно важных данных цена вопроса в несколько тысяч или максимум десятков тысяч рублей крайне невелика. Хотя для кого как. Студент и контрафактный софт – это одно, бизнес и комерческая тайна – другое, запрещенный контент и рядовой пользователь – третье и так далее по списку.

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

Полюбуйтесь на duplicity. С точки зрения передачи данных её можно считать неким балансом между шифрующей пофайлово ФС и контейнером.Но работы с бэкапом онлайн не будет.

Спасибо.


Есть одна гипотетическая ситуация, при которой эта метода не работает. Это когда после обыска вы пускаетесь в бега, с друзьями и знакомыми встречаться смертельно опасно, т.к. всюду засады, а всплыть в интернете можете только за границей, причём заранее неизвестно даже где. Бегать по лесам и откапывать тайники с дисками времени тоже не будет, т.к. надо делать ноги.

За вами уже вылетели выехали.
Вас на досмотре в аэропорту поймают. Лучше добровольно сдайтесь.
Откуда пишете-то? С брата? И как, жив курилка?
Вы инспектируйте, записывайте, хороший 3D-экшон получится, да и на попкорне озолотимся!
В школе еще каникулы не начались, а тут уже такие страсти.

Да. Всегда найдется гипотетическая ситуация, при которой та или иная метода не работает. Поэтому, ничего страшного, если метода не работает. Гораздо хуже, когда голова не работает.

Хотите, я угадаю, что вы сейчас случаете? Николая Носкова, композиция "Вот она пришла весна, как паранойя")

Пусть позвонят, как подъедут, а то охрана, электронные пропуска, забор, да потом искать нужную дверь долго.


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


Не угадали.


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

Подсказываю свою методу хранения бекапов и паролей к разным данным. В голове держу мастер-пароль и нижеописанный алгоритм:
домен сервера с бекапами = md5(host|backup|master_pass).com
пароль к архивам бекапов = md5(data|backup|master_pass)
рутовый пароль к серверу = md5(root|server_ip|master_pass)

Самые важные данные бекапятся автоматически, их не больше гигабайта. Остальное не фатально потерять.

Как возможно получить пароль=md5(data|backup|master_pass) при том, что зашифрованные data зависят от пароля? Или это просто имя архива?

data это не данные, это такая строчка. Вычисляется т.е. если мастер-пароль qwerty, паролем на архив будет md5(data|backup|qwerty) = 1FE1C0C2A7CCD6049155E8D549A8E570

Уметь бы его ещё считать прямо в голове!

Уметь бы его ещё считать прямо в голове!

Ещё один повод встроить чип себе в мозг? :)

Только на основе OpenHardware!

Посмотрел на неё, на rsync и на rdiff-backup. Пока остановился на последнем, но это всё равно не то, что хотелось бы, а хочется следующего:


Все эти инкрементальные бэкапы в duplicity и rdiff-backup для решения задачи подходят плохо. То, что они инткрементальные — это как раз хорошо, но вот они не являются идентичными копиями исходной директории. Duplicty вообще создаёт шифрованный tar-архив, потому не подходит сразу, а rdiff-backup делает уже настоящую копию директории, но к ней ещё есть директория с метаданными, инкрементами, статистикой и прочим. Директорию, куда сделал бэкап rdiff-backup, ни в коем случае нельзя менять, т.к. rdiff-backup — это скорее версионник для директории, который хранит список последних изменений и даже позволяет извлечь снапшот директории за какой-то промежуток времени. Грубо говоря, если хочется подключить бэкап, его надо разворачивать в новую директорию, и уже с ней работать. Если речь идёт о десятках-сотнях гигабайт данных, это, прежде всего, куча времени и бессмысленных копирований. Т.е. как бэкап-то оно работает, но бэкап «не живой». Можно ли сделать «живой» бэкап, который редактируем и подключаем на лету в любой момент? Или это несовместимо с инкрементальностью обновлений бэкапа? Казалось бы, rsync достаточно умён, чтобы синхронизировать директории даже без специальной БД о последних изменениях.

Подумалось ещё о такой аналогии: есть RAID'ы, когда идентичная информация пишется сразу на несколько носителей. Хочется получить то же самое, но чтобы информация писалось только в один из дисков «рейда», а потом можно было руками указать, содержимое какого из дисков отзеркалить на все остальные^*. И отзеркалирование должно происходить не постоянно, как в рейдах, а раз в сутки/неделю — что-то типа такого.

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

Пример из жизни, где это нужно: на работе и дома есть почти идентичные директории. Допустим, дома я поработал, внёс какие-то изменения, что-то удалил, другие файлы добавил. Потом прихожу на работу, подключаюсь по сети к домашнему компьютеру и синхронизирую его с рабочим, после чего должен получить идентичную копию директории. Затем, поработав на работе, могу прийти домой и синхронизировать теперь уже домашний компьютер по рабочему. Как решают такие задачи? Здесь есть простота, т.к. заранее оговаривается, что в любой момент времени изменения вносятся только в одну из директорий. Наверное, нужен версионник, который содержит в себе всю БД изменений. Поработал дома — закоммитил изменения, подключился на работе — обновил свою версию из центральной БД версионника, а после изменений снова закоммитил. Если центрального сервера нет, БД с версионником должна быть либо дома, либо на работе.

Так это не бэкапы, а VCS.