Я пытаюсь создать зашифрованную резервную копию Blu-Ray. Я создал и записал изображение, используя следующий грубый скрипт:

imgsize=23000M
imgfile=~/backup.img
imgloop=`sudo losetup -f`
truncate -s $imgsize $imgfile
sudo losetup $imgloop $imgfile
sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop
sudo cryptsetup luksOpen $imgloop mybackup
sudo mkudffs /dev/mapper/mybackup
if [ ! -d "/mnt/backup" ]; then
    sudo mkdir /mnt/backup
fi
sudo mount /dev/mapper/mybackup /mnt/backup

# Now copy all files that are part of the backup
echo "Copy files to backup to /mnt/backup. Type 'ready' when done";
while read line; do
    echo "$line";
    if [ "$line" == "ready" ]; then
        break;
    fi
done

sudo umount /mnt/backup
sudo cryptsetup luksClose /dev/mapper/mybackup
sudo losetup -d $imgloop

Когда сценарий был закончен, я использовал следующую команду, чтобы записать его на M-Disc BD-R:

growisofs -dvd-compat -Z /dev/dvd=backup.img

Ожог завершен без сбоев. Я могу открыть том luks, используя:

sudo cryptsetup luksOpen /dev/dvd mybackup

Который производит устройство /dev/mapper/mybackup ; однако, когда я пытаюсь смонтировать его с помощью:

sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Я получаю следующую ошибку:

mount: /dev/mapper/mybackup is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Системный журнал содержит следующую ошибку:

[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found
[ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1)

Обновление 1

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

sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Так что что-то идет не так, потому что это на диске.

|источник

2 ответа2

3

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

Приведенные ниже эксперименты показывают, что опция -r of cryptsetup делает свое дело:

sudo cryptsetup luksOpen -r /dev/dvd mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Первая неверная теория:

Основное различие между оптическими носителями и файлами данных или дисковыми устройствами заключается в размере блока 2048 байт. Например, редакторы разделов могут запутаться при проверке таблиц разделов изогибридных DVD-дисков. Может быть, LUKS аналогичным образом зависит от того, чтобы иметь одинаковый размер базового устройства с шифрованием и дешифрованием.

Если вы используете носитель BD-RE, вы можете попробовать, поможет ли он создать зашифрованную файловую систему непосредственно в /dev /dvd, а не в файле ~ /backup.img. (Производительность с большим произвольным доступом будет плохой. Ваши буферы ОЗУ могут оттолкнуть другую виртуальную память и заставить ее использующие программы работать медленно. Синхронизация или размонтирование могут длиться довольно долго.

Если вы используете BD-R, то вы можете использовать BD-RE для создания образа и затем скопировать его на носитель BD-R.

Если ничего не работает, я мог бы предложить функцию -external_filter в xorriso, которая зашифровывает содержимое файла, пока оно помещается в файловую систему ISO 9660 с деревом каталогов открытого текста. Не такая же конфиденциальность, как с LUKS, но менее экзотическая, с другой стороны.

(Почему в мире вы идете на UDF? У вас есть машины Solaris или BSD, которые могут иметь драйверы UDF лучше, чем их подземные драйверы ISO 9660? Или целевые системы чтения не могут использовать ext?)

След, который я должен был следовать:

В некоторых сообщениях о проблемах в Интернете о LUKS и CD/DVD/BD рекомендуется использовать параметр cryptsetup -r в качестве чудесного средства. (Т.е. камень только для чтения, а не размер блока).

Убедитесь, что оптические носители работают с LUKS:

Я попробовал BD-RE часть моего предложения по созданию на устройстве с 2K блоками (или секторами). BD-RE находится в /dev /sr4. Настройка как зашифрованный диск:

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4
sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre

Чтобы избежать необходимости быть суперпользователем при запуске xorriso, я передаю появившийся файл устройства группе "cdrom", членом которой я являюсь:

chgrp cdrom /dev/dm-0

Использование xorriso для написания ISO. Вы должны сделать UDF и заполнить его:

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory /

Это чертовски медленно, возможно, из-за управления дефектами BD-RE, на которое xorriso не может влиять через уровень криптоустройства. Я читаю по tar и (потому что он у меня есть) по xorriso:

sudo mount /dev/mapper/mybdre /mnt/iso
tar cf - /mnt/iso | wc

Нет ошибок ввода / вывода, сообщается об ожидаемом размере содержимого ISO.

sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --

сообщает о совпадении MD5 сессии ISO. Так что это будет работать. Теперь кто-то должен будет вложить BD-R и скопировать в него BD-RE.

Разница в размерах блоков дисковых файлов и BD не имеет значения:

Я должен был попробовать это первым. Но теперь я следовал вашему рецепту, за исключением того, что скопировал зашифрованное изображение на BD-RE (все еще слишком экономный для BD-R).

Оно работает. Я могу смонтировать BD-RE с помощью -t udf и скопировать содержимое файла в wc.

Таким образом, слухи о параметре cryptsetup -r на носителях только для чтения, похоже, остаются единственной правдоподобной теорией.

Успех с CD-RW в качестве замены BD-R:

Я попытался использовать неформатированный CD-RW, который Linux считает доступным только для чтения.

sudo cryptsetup luksOpen /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Никогда не буду делать это снова. Диск был сброшен ядром. Одна из строк /var /log /messages говорит, что Linux пытался писать в него. Только хорошо, что это в коробке USB. Так что я мог бы восстановить его с помощью цикла питания.

С опцией -r все работает нормально:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc
|источник
0

Мне, наконец, удалось смонтировать зашифрованный bluray, сначала подключив считыватель к устройству цикла и запустив cryptsetup на последнем:

sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup

Затем зашифрованный bluray монтируется в /mnt/backup .

Я обнаружил это в старом отчете об ошибке Red Hat, и понятия не имею, зачем нужно петлевое устройство, и подозреваю, что это может быть ошибкой, так как автоматическое монтирование с использованием графического интерфейса в thunar дает сбой (можно было бы ожидать, что это сработает), что также Отчет об ошибках Red Hat упоминается, хотя и с рабочим столом Gnome. Также очень странно, что изображение, которое сгорает до синевы, может быть смонтировано без петлевого устройства.

Чтобы отменить вышесказанное, используйте следующее:

sudo umount /mnt/backup
sudo cryptsetup luksClose myvolume
sudo losetup -d /dev/loop0

Я открыл отчет об ошибках с помощью cryptsetup на тот случай, если это ошибка.

|источник

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