Решил я поделится опытом в сабже, т.к. часто даю советы как делать, но при этом не написал, как же оно у меня сделано.
Речь пойдёт про нетбук с Linux. В десктопе ситуация намного проще, т.к. потерять десктоп намного сложнее. А вот нетбук -- легко. Особенно мой, потому-что HDD у меня давно сломался, и я использую флешки. Т.е. сам-то нетбук у меня останется, а вот мои данные окажутся у неизвестно кого. Это конечно не очень меня обрадует. Не фатально, но согласитесь -- неприятно.
Периметр
Прежде всего следует ограничить периметр охраняемой информации. Всё, что за периметром нужно защищать, а что внутри периметра -- не нужно, и вредно. Если так не сделать, тогда при любом действии придётся доказывать системе, что я -- не верблюд, а хозяин. В большинстве случаев это конечно излишне.
Очевидно, в качестве неохраняемого периметра можно выбрать оперативную память. Т.о. будем считать, что ВСЁ что вне памяти либо общедоступно, либо зашифровано. В том числе и основной носитель информации конечно.
Теперь про наполнение периметра: очевидно, что ОС (у меня Slackware Linux) прятать глупо. Потому она лежит вне периметра, и доступна врагам. В том числе и каталог /etc/ с общими настройками. Подразумевается, что враг может украсть у меня носитель, но не может украсть, а потом вернуть мне его так, что-бы я этого не заметил. (если-бы такой риск был, то пришлось-бы как-то подписывать файлы системы, дабы враг не смог понапихать мне жучков. Но такого риска не было). Также и каталог /boot/ тоже доступен всем подряд(кто имеет доступ к носителю). Каталог /tmp/ недоступен, и смонтирован в память. Т.е. лежит внутри периметра. Что касается $HOME, то это -- взаимоисключающие параграфы. Например $HOME/Download/ должно быть вне периметра, а вот $HOME/.ssh/ безусловно внутри его. ИМХО намного проще поместить весь $HOME внутрь периметра, а всякие Download вынести наружу, что и было сделано: я создал /unsecure/drb/, задал себя его хозяином, и переместил туда все большие публичные "папки", вроде Download & Music. Ну а внутри $HOME я создал симлинки.
Сам $HOME я смонтировал в память, как tmpfs (вообще-говоря, tmpfs может вылезти из периметра в swap. Мне это не грозит по причине отсутствия свопа, но в общем случае этот вопрос нужно как-то решить)
Создание бекапа
Теперь всё просто: нетбук сам создаёт каждые N минут бекап(и перед выключением тоже), а когда я включаю комп, последний бекап разворачивается в память, которая $HOME. Я посмотрел, размер $HOME у меня получился всего ~150Мб, или ~30Мб в архиве. Т.ч. на всё про всё нужно немного ресурсов и времени. Бекап сжимается программой bzip2, и затем шифруется GnuPG. Шифрование происходит открытым ключом автоматически, а вот для дешифровки приходится ввести пасфразу. Но только один раз(впрочем, пароль-то вы тоже вводите? А я вместо этого ввожу пасфразу, которой зашифрован закрытый ключ).
Гладко было на бумаге, но забыли про овраги -- проблема с консистентностью.
Тащем-то всё прекрасно, вот только бекап делается не мгновенно, а какое-то время. За это время всё может изменится. ИЧСХ -- меняется. Потому развернётся ЭТО в эпичный глюкодром. В чём же проблема? А проблема тут в нарушении принципа причинности(ПП). Если из-за изменения файла А меняется файл Б, то это может привести к серьёзным проблемам, в том случае, если мы сохраним (а потом восстановим) сначала старую версию А1, а потом новую версию Б2. Просто IRL такого не бывает, а бывает такое:
Код: Выделить всё
А1 Б1
А2 Б1
А2 Б2т.к. файл Б -- это следствие А. У нас всё перепуталось, и нарушение ПП приведёт к фатальным последствиям. (т.к. у нас будет комбинация А1 Б2, которой НИКОГДА не бывает, и быть не может. Поведение наших программ будет НЕОПРЕДЕЛЕНО ( http://en.wikipedia.org/wiki/Undefined_behavior )).
Что же делать? Ну во первых, эта хаутушка про домашний компьютер, т.е такая ситуация встречается редко. Её нельзя игнорировать, но и бояться особо не надо -- во многих бекапах такого не будет, а если и будет, то не очень часто. Потому мы можем применить сравнительно простое решение: перед изготовлением бекапа запомним время t0, а после изготовления найдём файлы изменившиеся после t0. И их добавим в бекап.
Это была хорошая новость. Плохая заключается в том, что простой командой вроде
Код: Выделить всё
tar -cjf backup.tbz $HOMEнам уже не отделаться. Впрочем, это было ясно с самого начала: бекап должен создаваться сам по себе, а значит бекапилка должна сама адекватно реагировать на проблемы. Потому лучше пусть делает постепенно, иначе ей будет сложнее разобраться.
Хотел обосновать... Лень. Если вам нравится -- делайте всё одной командой, я не против. Единственное, если что-то пойдёт не так, то ваша система превратится в бесполезный кирпич, ибо ваистену -- безопасность системы повернётся к вам своим задом...
поиск и упаковка
Очевидно, что сначала надо найти файлы. Менее очевидно, что искать надо утилитой find. Но других вариантов действительно нет, ибо IRL условие для поиска слишком сложное(около 253х символов).
Условие составлено из трёх частей:
1. предварительное условие
Код: Выделить всё
find . \( -path "./exclude1" -o -path "./exclude2" -o -path "./exclude3" \) -prune -o -user username3 каталога ./exclude{1,2,3} полностью исключаются из бекапа. Действие -prune даёт всегда истинный результат, причём find даже не смотрит в этот каталог(и). Потому дальше стоит опция -o (ИЛИ), для всех других каталогов(но не этих). Там же включена фильтрация по пользователю -- в бекап не включаются левые файлы.
2. условие времени
Код: Выделить всё
-newermt @1384958585сохраняются только те файлы, которые изменились после определённого времени. В первый раз этого условия просто нет. См. выше, зачем это нужно.
3.
Код: Выделить всё
\( -type f -o -type d -empty -o -type l \) -printсохраняются только файлы, или только пустые каталоги, или только ссылки. Непустые каталоги не сохраняются явно, а только неявно (их сохраняет tar, вместе с файлами, которые там есть)
Эти три условия объединяются, и отдаются eval (без неё код намного сложнее и запутаннее)
Получившийся список сортируется, и отдаётся команде tar, которая добавляет(--append) файлы к архиву. Некоторые файлы могут добавляться 2 раза, старая и новая версия. Если они изменились. Сам файл tar лежит в /tmp/ (т.е. в памяти))
После создания архива, команда find ищет ещё раз. Но уже с момента начала бекапа. Если выяснилось, что изменились файлы, процесс повторяется сначала (с этим же архивом, и файлы ищутся не все, а только с момента начала добавления). И так далее, пока не создастся констистентная версия архива.
Сжатие и шифрование
После успешного создания /tmp/*.tar файла, там же файл сжимается, и шифруется асимметрично для нескольких реципиентов (потому-что у каждого моего компьютера имеется свой ключ, которого на других нет). Кроме того файл подписывается специальным ключом для подписи, который имеется исключительно на этом устройстве. Т.е. враг не сможет подменить архив, если не сможет его расшифровать(т.к. секретный ключ для подписи внутри этого архива), или как-то иначе получить доступ внутрь периметра.
Далее бекап переносится на флешку.
