Comments 14
UFO just landed and posted this here
С точки зрения решения проблемы — в принципе да. Тут, я считаю, чем проще — тем лучше.
С точки зрения причины — проблема в «трансляции» сбойных кластеров с нижнего уровня — базовой файловой системы — на верхний — в файловую систему контейнера. Точнее, в её отсутствии.
Если бы TrueCrypt «умел» бы определять сбойные кластеры на «родительской» файловой системе и переносить данные с них на другие, исправные… (Что в конце концов пришлось сделать вручную)
Хоть TrueCrypt и open source, но слишком далеко от моей специализации, чтобы взяться и сделать самому.
С точки зрения причины — проблема в «трансляции» сбойных кластеров с нижнего уровня — базовой файловой системы — на верхний — в файловую систему контейнера. Точнее, в её отсутствии.
Если бы TrueCrypt «умел» бы определять сбойные кластеры на «родительской» файловой системе и переносить данные с них на другие, исправные… (Что в конце концов пришлось сделать вручную)
Хоть TrueCrypt и open source, но слишком далеко от моей специализации, чтобы взяться и сделать самому.
UFO just landed and posted this here
Я, возможно, спрошу очевидность, но если вы скриптами даже запускаете менеджер паролей, то могли бы озаботится и автоматическим резервированием. Хотя бы по шедулеру давать пинок сотруднику (я так понимаю, скорее всего, речь идет о рабочих данных). Есть бэкаперы, которые при подключении схемного накопителя делают бэкап.
«озаботиться»
Резервирование настроено. Вся критическая информация, которая, будучи потеряна, не сможет быть восстановлена или приведёт к неприемлемым задержкам в делах, копируется при любом удобном случае. Например, бакап базы паролей делается тем же скриптом, который запускает менеджер паролей, минимум дважды в сутки.
В контейнере же хранится оперативная информация (типа кэша). То есть такая, которая где-то ещё разбросана по накопителям, там же, при необходимости, резервируется и т.п. Всю её можно, потратив какое-то время, собрать заново. Например, сканы паспортов, свидетельств о рождении, сохранённые веб-страницы. Ценность эта информация представляет только из-за того, что здесь и сейчас она — со мной и не надо совершать лишних телодвижений, чтобы её получить.
В конце концов время, потраченное на восстановление, действительно оказалось гораздо меньше ориентировочного времени, которое я потратил бы на сбор всего этого заново.
В контейнере же хранится оперативная информация (типа кэша). То есть такая, которая где-то ещё разбросана по накопителям, там же, при необходимости, резервируется и т.п. Всю её можно, потратив какое-то время, собрать заново. Например, сканы паспортов, свидетельств о рождении, сохранённые веб-страницы. Ценность эта информация представляет только из-за того, что здесь и сейчас она — со мной и не надо совершать лишних телодвижений, чтобы её получить.
В конце концов время, потраченное на восстановление, действительно оказалось гораздо меньше ориентировочного времени, которое я потратил бы на сбор всего этого заново.
В «итогах» не хватает пункта «Научился делать ежедневные бэкапы».
Приоритеты для себя я давно расставил и особо важные «активы» — выделил. Всё, что нужно, — бэкапится. В контейнере хранится только оперативная информация, которая хранится также и в других местах и потеря которой в данном месте не критична. Затраты на бэкап, как показал «инцидент», не окупились бы всё равно.
UFO just landed and posted this here
Может быть. Не знаю насчёт Dropbox'a, а git и svn будут воспринимать криптоконтейнер как бинарный файл. Причём так как он «крипто-», то различий между двумя его версиями будет очень много. Поэтому «версионировать» по сети малыми diff'ами для синхронизации 500 Мб криптоконтейнер, по моему мнению, не получится.
Архивировать для хранения — тоже не вариант, опять же из-за того, что файл шифрованный и энтропия его велика.
А гонять по сети туда-сюда каждый раз по 500Мб — удовольствие на любителя.
Архивировать для хранения — тоже не вариант, опять же из-за того, что файл шифрованный и энтропия его велика.
А гонять по сети туда-сюда каждый раз по 500Мб — удовольствие на любителя.
Расскажи плз подробнее про автоматическое монтирование с вводом пароля.
Я правильно понимаю, что когда вы втыкаете в юсб внешний винт автоматом запускается truecrypt с какими-то параметрами? есть какие то варианты как это можно сделать без авторана новых устройств?
Я правильно понимаю, что когда вы втыкаете в юсб внешний винт автоматом запускается truecrypt с какими-то параметрами? есть какие то варианты как это можно сделать без авторана новых устройств?
Правильно понимаете.
Вариант есть. Нужен установленный nnCron. У него есть семейство очень полезных ключевых слов Watch*. А конкретнее, в данном случае:
При появлении диска с совпадающей буквой (т.е. «флешки» с криптоконтейнером на ней) срабатывает описанное ниже в скрипте правило:
При появлении в системе диска B: (интервал сканирования настраивается. По умолчанию — 1000 мс) проверяется его содержимое. На диске должен быть KeePass. Если он есть — он запускается. Но не непосредственно, а батником. Файл KeePass.cmd делает бэкап базы паролей, добавляя в имя файла штамп времени и сохраняя его в выделенные каталоги (рядом на флешке и в «Моих документах» текущего пользователя. База зашифрована, за содержимое можно не волноваться).
Теперь с использованием интерфейса командной строки TrueCrypt монтируется контейнер на выделенную букву диска. Ну, и дальше — всё что нужно.
В принципе, можно запрограммировать любые действия в пределах компетенций языка Форт, встроенного в nnCron.
Вариант есть. Нужен установленный nnCron. У него есть семейство очень полезных ключевых слов Watch*. А конкретнее, в данном случае:
WatchDrive: "B" При появлении диска с совпадающей буквой (т.е. «флешки» с криптоконтейнером на ней) срабатывает описанное ниже в скрипте правило:
\ Проверить, "флешка" ли это - есть ли файл "H:\KeePass Password Safe\KeePass.exe"
FILE-EXIST: "B:\KeePass Password Safe\KeePass.exe"
\ Если есть - запустить "B:\KeePass Password Safe\KeePass.exe"
IF
\ Если KeePass.exe ещё не запущен...
PROC-EXIST: "KeePass.exe" NOT
IF
\ ... запустить его.
StartIn: "B:\KeePass Password Safe"
ShowNormal NormalPriority
START-APP: "B:\KeePass Password Safe\KeePass.cmd"
THEN
При появлении в системе диска B: (интервал сканирования настраивается. По умолчанию — 1000 мс) проверяется его содержимое. На диске должен быть KeePass. Если он есть — он запускается. Но не непосредственно, а батником. Файл KeePass.cmd делает бэкап базы паролей, добавляя в имя файла штамп времени и сохраняя его в выделенные каталоги (рядом на флешке и в «Моих документах» текущего пользователя. База зашифрована, за содержимое можно не волноваться).
\ Запустить монтирование тома на "флешке"
FILE-EXIST: "B:\TrueCrypt\TrueCrypt.exe"
IF
\ Если файл криптоконтейнера существует на "флешке" ...
FILE-EXIST: "B:\MyDocs.tc"
IF
StartIn: "B:\TrueCrypt\"
ShowNormal NormalPriority
START-APPW: "B:\TrueCrypt\TrueCrypt.exe" /b /letter I /volume "B:\MyDocs.tc"
...
Теперь с использованием интерфейса командной строки TrueCrypt монтируется контейнер на выделенную букву диска. Ну, и дальше — всё что нужно.
В принципе, можно запрограммировать любые действия в пределах компетенций языка Форт, встроенного в nnCron.
Sign up to leave a comment.
Спасение «битого» переносного винчестера с TrueCrypt-контейнером