4

У меня есть новый внешний жесткий диск USB 2 ТБ, и я хотел бы использовать его в качестве резервной копии для моего домашнего сервера.

Мои пожелания:

  • полное шифрование диска (диск будет храниться вне сайта)
  • предотвращение гниения

В настоящее время я использую старый внешний диск емкостью 320 ГБ с шифрованием на уровне разделов TrueCrypt. Но так как это не обеспечивает защиту от гниения и TrueCrypt устарела, я хотел бы попробовать что-то еще.

Мой сервер работает под управлением Ubuntu Server 14.04.3 LTS и имеет ECC-память с 2x 3 ТБ дисками в RAID 1.

Что касается шифрования, использование LUKS, вероятно, лучший выбор, верно?

Но когда дело доходит до гниения, все становится немного сложнее. По крайней мере, для конфигурации с одним диском. Один из вариантов - создать 2 одинаковых раздела и создать RAID 1 с регулярной очисткой. Но это решение кажется немного странным на одном диске.

Будет ли вариант btrfs? Можно ли добавить избыточность для конфигурации с одним диском?

Я не против пожертвовать половину хранилища ради избыточности. Потеря в производительности также не проблема для меня.

2 ответа2

4

Учитывая, что у вас есть все основные предпосылки, в частности ОЗУ ECC, я думаю, что ZFS (через реализацию ZFS On Linux ) может быть полезным вариантом.

В отличие от btrfs, который позаимствовал у ZFS много идей по дизайну, ZFS - это проверенная и надежная (менеджер томов) файловая система. Конечно, у порта Linux есть некоторые неровности, которые с течением времени сглаживаются, но код и дизайн были протестированы во многих реальных сценариях сбоев.

Вы можете использовать ZFS либо с двумя отдельными разделами в зеркальной конфигурации, либо с одним разделом и установив copies=2 в корневой файловой системе пула. Дисковое пространство и накладные расходы производительности ввода-вывода будут аналогичными. Любой из них позволит вам перейти на более крупные диски или конфигурации с несколькими дисками, поскольку ваши потребности со временем меняются. Вы можете использовать raidz vdevs (с разными уровнями избыточности: один, два или три диска), но это создает проблемы, если вы когда-нибудь захотите изменить уровни избыточности.

Я бы посоветовал серьезно рассмотреть возможность запуска ZFS поверх LUKS.

Противоположность (запуск LUKS поверх ZFS) также возможна, но значительно более сложна. Вы также можете запустить что-то вроде ecryptfs поверх незашифрованной ZFS, но это может привести к утечке значительного количества метаданных файловой системы.

Другими словами, создайте контейнеры LUKS (по одному для каждого диска или раздела), а затем используйте эти контейнеры для создания пула ZFS. Запуск ZFS поверх LUKS должен быть достаточным для предотвращения автономного злоумышленника в большинстве сценариев, хотя это будет небольшим препятствием для злоумышленника онлайн. Является ли это проблемой, зависит от вашей модели угроз, но для резервного копирования за пределы сайта автономный доступ часто является более важным аспектом, который следует учитывать.

Запуск двух отдельных разделов в виде отдельных контейнеров LUKS должен помочь избежать повреждения заголовка LUKS, делая обе копии недоступными, но другие методы также могут сделать это (например, надежно сохраненная резервная копия заголовка LUKS). Запуск одного раздела LUKS-контейнера для каждого диска позволит ZFS принимать решения о хранении метаданных файловой системы в различных избыточных местах.

Если вы идете с copies=2 , убедитесь, что вы установили это сразу при создании пула. Другими словами, вы хотите что-то вроде:

cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create -O copies=2 tank /dev/mapper/sdx-crypt

и не

cryptsetup luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx sdx-crypt
zpool create tank /dev/mapper/sdx-crypt
zfs set copies=2 tank

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

Обратите внимание, что, как и в любой файловой системе с копированием при записи, ZFS работает лучше всего, когда уровень использования диска поддерживается на уровне ниже 75-80%, и вы должны ожидать фрагментации со временем. Для резервных копий это не должно быть серьезной проблемой.

0

Par2 - это зрелая программная опция для создания файлов четности. Вы можете настроить его, чтобы разрешить и установить процент файла, который будет потерян, но все еще подлежит восстановлению. [1] [2] Например, 30% резервирование:

par2 c -r30 file-to-protect

LUKS нужна хорошая конфигурация для безопасности. aes-xts-plain64:sha256 или чуть лучше PBKDF2-sha512 со случайным 256/512-битным ключом качества является стандартной рекомендацией [3]

[1] https://en.wikipedia.org/wiki/Parchive

[2] https://github.com/Parchive/par2cmdline

[3] https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup

[4] Насколько безопасным является полнодисковое шифрование Ubuntu по умолчанию?
https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption

PS Зашифрованная ZFS, разработанная SUN для корпоративных данных, была бы хороша, но только на Solaris. ZFS в Linux поддерживает только ZFS + LUKS, а не собственное шифрование. ZFS Scrub проверяет наличие битрота и часто настраивается на ежедневную работу для накопителей потребительского класса. Вы могли бы даже сделать трехстороннее зеркало ZFS для максимальной безопасности данных. https://help.ubuntu.com/community/encryptedZfs

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .