зашифрованные резервные копии для Linux и FreeBSD, доступные для чтения обоим

8

У меня есть компьютер с Linux и FreeBSD, оба зашифрованы (LUKS и geli соответственно). Мне интересно, как сделать резервные копии, которые также были бы зашифрованы и были бы доступны для чтения обоим (чтобы в случае сбоя одного из компьютеров я мог быстро восстановить данные, используя другой).

К сожалению, кажется, что bot LUKS и geli являются модулями ядра для этих соответствующих систем, которые никогда не были перенесены на соответствующие другие системы. Судя по нескольким угрозам в BSD / Linux-совместимых файловых системах, кажется, что достаточно сложно создать незашифрованные резервные копии, которые были бы доступны для чтения обоим (ext2, очевидно, является единственным вариантом для файловой системы, которая позволила бы это).

Поэтому я подумал о том, чтобы установить виртуальную FreeBSD в Linux KVM, которая могла бы читать и записывать внешний диск с зашифрованным гели и передавать данные на незашифрованный виртуальный том ext2 внутри файловой системы с шифрованием LUKS в Linux (и другим способом). около). Это, однако, кажется ужасно сложным и на самом деле не похоже на правильный способ сделать это.

Есть ли лучшие / более легкие / более предпочтительные способы? Или способ, описанный выше, в настоящее время является наилучшим вариантом?

Спасибо; Я ценю любые мысли по этому вопросу.

0range
источник
2
Единственное, что я вижу в этом списке en.wikipedia.org/wiki/… , поддерживаемом обоими, - это eCryptFS en.wikipedia.org/wiki/ECryptfs, хотя это не шифрование на уровне блоков. Это слой файловой системы.
Zoredache
1
Я бы скорее установил другую коробку с моей любимой ОС для обслуживания и хранения резервных копий.
Ярослав Рахматуллин
Большое спасибо вам обоим за ваши мысли. Я надеюсь, что когда-нибудь в будущем кто-то перенесет LUKS на FreeBSD или geli на Linux (к сожалению, мне не хватает как необходимых навыков / опыта программирования, так и времени для их приобретения.)
0

Ответы:

3

Давайте установим пару предположений. Прокомментируйте, если они не верны.

  1. вы запускаете машины с разными операционными системами и потенциально разными платформами.
  2. Вы описываете это для случая с 2 машинами, а также Linux и FreeBSD
  3. ваши машины используют зашифрованные файловые системы
  4. вы хотите создавать резервные копии ваших данных и хотите, чтобы эти резервные копии также были зашифрованы
  5. вы хотите иметь возможность доступа к данным в этих зашифрованных резервных копиях с любой из платформ, участвующих в архиве

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

Вы упоминаете, что хотели бы получить доступ к данным других систем с выжившей машины. Одним из способов может быть сохранение незашифрованных резервных копий на локальном компьютере в зашифрованной файловой системе. Другим может быть хранение зашифрованных резервных копий на локальном компьютере в незашифрованной файловой системе. Я предлагаю хранить зашифрованные резервные копии на незашифрованных файловых системах.

Однако в качестве отступления - всегда есть проблема с зашифрованными резервными копиями: - вам действительно нужно быть осторожным с ключом - частичное повреждение обычно убивает всю резервную копию

мое предложение: использовать

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

Чтобы сохранить все это в вашей локальной сети, вы можете:

  1. создать «резервную» файловую систему на обоих хостах, чтобы хранить зашифрованные резервные «пакеты». Не требуется зашифрованная файловая система, так как сохраненные в ней резервные «пакеты» (brackup называет их «чанками») будут зашифрованы
  2. экспортируйте эти файловые системы, например, с помощью NFS, и смонтируйте их на других хостах соответственно
  3. при создании резервных копий выведите их в локальную файловую систему и отразите их в каталог, смонтированный по NFS, на другом хосте. У этого есть хороший побочный эффект наличия двух экземпляров ваших файлов резервных копий.

Теперь у вас будут следующие файловые системы на ваших серверах:

на tux, ваш Linux-компьютер:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

на Beastie, вы FreeBSD машина:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

в зависимости от объема данных, которые вам необходимо сохранить, вы также можете подумать о внешнем контейнере, который подойдет любому облачному провайдеру. В настоящее время я играю с настройкой своих контейнеров S3, чтобы старые вещи старели до Glacier, что выглядит очень многообещающе, по цене.

Флоренц Клей
источник
не совсем. мне не нужно, чтобы он был по блокам, и мне не нужно, чтобы он был по сети (хотя инструменты, которые вы предлагаете, кажутся очень интересными). скорее проблема (как это правильно поняли Зорече и Ярослав Рахматуллин), что если по какой-либо причине какая-либо из систем выходит из строя, мне нужен какой-то способ доступа к резервным копиям. поэтому резервные копии должны храниться в зашифрованной файловой системе (на другом диске), доступной для обеих систем. это создает проблему, поскольку как собственные системы шифрования, так и собственные файловые системы linux и freebsd несовместимы. извините, что не ответил ранее.
0
о, и я должен упомянуть, что некоторые из этих архивов просто зашифрованы вручную для меня, как моего адресата PGP. Позже более разумные настройки содержат два файла: один архив, зашифрованный с помощью симметричного ключа, и ключ, зашифрованный с помощью PGP, оба в другом архиве, поэтому файлы не теряются при передаче. Ничто из этого не так хорошо автоматизировано, как упомянутые сценарии, но оно сделало свою работу.
Флоренц Клей
Я никогда не слышал о двуличности, но это звучит как то, что я ищу! Ты знаешь сколько ему лет? Это стабильно? Я не могу найти даты начала проекта.
CNST
Duplicity [ duplicity.nongnu.org] существует с 2002 года, я использую его с ок. 2004.
Флоренц Клей
@ 0range - немного убрал различие в «шифровании». То, что я предлагаю, не блок за блоком, это основано на файле. Предложите использовать незашифрованные файловые системы, потому что они могут быть прочитаны обеими системами. Храните зашифрованные резервные копии на них, они тоже могут быть прочитаны на обеих платформах с помощью соответствующих собственных инструментов. Это должно поставить галочку как на ваших требованиях, шифровании и читаемости, на обеих платформах.
Флоренц Клей
2

Duplicity - отличный инструмент для решения этой задачи, использует GPG для шифрования. Я использую это в течение некоторого времени, и я действительно рекомендую.

В качестве альтернативы вы можете попробовать:

  • obnam - это новый проект, но имеет некоторые приятные особенности (он немного медленный при использовании через ssh / scp)
  • отрыжка - шифрование с паролем
Spinus
источник
см. мой комментарий к ответу Флоренц Клей выше. (и спасибо, что предложили эти инструменты)
0
Извините, я мог только добавить комментарий здесь. Эти инструменты не блок за блоком, а FS (вы можете сделать резервную копию FS и восстановить его даже в Windows). GPG является стандартом для шифрования - он также работает на обоих. Эти программы не только сетевые, вы можете сделать резервную копию dir в dir. Таким образом, с двуличностью вы можете создавать резервные копии обеих машин и восстанавливать зашифрованные резервные копии везде, где у вас есть двуличие и ключ GPG.
Spinus
2

TrueCrypt должен работать как под Linux, так и под FreeBSD. Хотя я регулярно использую TrueCrypt только под Windows и не пробовал FreeBSD Truecrypt самостоятельно. YMMV.

Михаил Купчик
источник
1

Вы можете создавать резервные копии файлов ваших машин, используя обычные rsyncна жестких дисках других машин. В любом случае, поскольку вы используете локальное шифрование, оно шифруется с помощью шифрования локальных систем, а передача защищена TLS. Обновления выполняются быстро, и вы придерживаетесь проверенных механизмов шифрования и резервного копирования.

Если вам просто нужно сделать резервную копию файлов в какой-то ненадежной системе, обычный GPG хорошо сработал для меня. Я автоматизировал некоторые функции шифрования и FTP-передачи с помощью python, который работает уже два года.

Майкл
источник