磁带集上的压缩......但在 2.27TB.. 空间结束

elb*_*rna 4 backup tape tar

我插入了 LTO6 磁带

tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'ULTRIUM 6       '
Revision: '4142'
Attached Changer API: No
SerialNumber: 'HU1322VW9U'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x5a
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 3
Run Code Online (Sandbox Code Playgroud)

但是当备份达到 2.27TB(磁带压缩为 6TB)时,由于磁带未压缩而出现错误退出

2,27TiB 8:39:36 [75,6MiB/s] [                                                                        <=>                             ]
pv: write failed: Spazio esaurito sul device
error writing output file
Run Code Online (Sandbox Code Playgroud)

我在 slackware 14.2 上使用 tar 进行备份

tar cMpf - -X /etc/file.exclude  /| openssl enc -e -aes256 -salt -pass file:filepass |(pv -p --timer --rate --bytes > /dev/st0)
Run Code Online (Sandbox Code Playgroud)

Joh*_*ald 17

在您的情况下,是文件级加密阻止了压缩。

加密尝试使数据流看起来尽可能多的随机“噪音”。压缩试图增加数据“密度”,这与限制进一步压缩的效果类似。

  • @elbarna 因为`tar` 不知道磁带已经用完了;它只知道它正在写入管道,并且管道坏了。`pv` 知道磁带已满,但它没有任何代码来处理它,因此它报告磁带已满并破坏管道。如果你想让 tar 做磁带处理,*你必须让它处理磁带*。 (14认同)

Tom*_*Tom 5

压缩假设它可以工作。tar 文件通常无法压缩(它们已经压缩了),所以是的,您最终可能无法获得“平均压缩率”。纯文本文件可能压缩得更多。压缩目标是估计值。

  • 裸`tar` 文件*未压缩*。这就是为什么你经常看到`.tar.bz2` 和朋友。OP 正在加密未压缩的纯 tar 输出,这破坏了链中后期压缩的任何希望。(AES-256-CBC 非常接近随机函数。) (33认同)
  • @TomTom:考虑编辑您的答案以删除不能压缩 tar 文件的声明 - 这是错误且具有误导性的;如果您从关于加密/噪声的评论中添加一点,这将是一个更好的答案:-) (6认同)
  • 以防万一有人不知道这一点,LTO 和大多数磁带驱动器会自动检测压缩是否导致扩展并切换到磁带上未压缩的数据存储。因此,加密数据的限制约为 2.5 TB。 (3认同)