我正在尝试创建加密蓝光备份。我使用以下粗略脚本创建并刻录了映像:
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
因此,由于它在光盘上,所以一定出了问题。
答案1
失败的最可能原因是当介质需要为 LUKS 打开时对它的只读限制。
下面的实验表明 cryptsetup 的 -r 选项可以达到这个效果:
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 上创建加密文件系统是否有帮助。(大量随机访问时的性能会很差。您的 RAM 缓冲区可能会推开其他虚拟内存并使其使用程序运行缓慢。同步或卸载可能会持续很长时间。
如果您使用 BD-R,那么您可以使用 BD-RE 创建图像,然后将其复制到 BD-R 介质。
如果什么都不管用,我可以提供 xorriso 的 -external_filter 功能,该功能会在将文件内容放入具有明文目录树的 ISO 9660 文件系统时对其进行加密。与 LUKS 的隐私性不同,但另一方面不那么奇特。
(你到底为什么要选择 UDF?你是否有 Solaris 或 BSD 机器,它们的 UDF 驱动程序可能比其地下 ISO 9660 驱动程序更好?或者目标阅读器系统不能使用 ext?)
我应该追随的踪迹:
网络上关于 LUKS 和 CD/DVD/BD 的一些问题报告建议使用 cryptsetup 选项 -r 作为灵丹妙药。(即只读而不是块大小将成为绊脚石。)
确保光学媒体与 LUKS 兼容:
我尝试在具有 2K 块(又称扇区)的设备上创建我提议的 BD-RE 部分。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
没有 i/o 错误,报告了 ISO 内容的预期大小。
sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --
报告 ISO 会话的 MD5 匹配。所以这可以工作。现在有人必须投资 BD-R 并将 BD-RE 复制到其中。
磁盘文件和 BD 的块大小差异无关紧要:
我应该先尝试一下。但现在我按照你的处方操作,只是我将加密图像复制到 BD-RE(对于 BD-R 来说还是太省钱了)。
成功了。我可以使用 -t udf 安装 BD-RE,并将文件内容 tar 到 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
答案2
我最终设法安装加密的蓝光,方法是首先将阅读器映射到循环设备,然后让 cryptsetup 在后者上工作:
sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup
然后将加密的蓝光安装在/mnt/backup
。
我发现一份旧的 Red Hat 错误报告,不知道为什么需要循环设备,怀疑这可能是一个错误,因为使用 GUI 自动安装thunar
失败(人们希望它能正常工作),这也是 Red Hat 错误报告中提到的,尽管使用的是 Gnome 桌面。刻录到蓝光光盘的图像可以在没有循环设备的情况下安装,这也很奇怪。
要逆转上述情况,请使用以下命令:
sudo umount /mnt/backup
sudo cryptsetup luksClose myvolume
sudo losetup -d /dev/loop0
我打开了使用 cryptsetup 提交错误报告以防万一它是一个错误。