dd of=/dev/where/to/restore通常我会使用with从备份中恢复分区内容输入流从某个地方（比如 ssh 连接）。
然而，在恢复已知写入耐久性严重有限的 SSD 驱动器时，这意味着覆盖整个驱动器（在典型情况下，分区放置在整个驱动器大小上）。当我在稀疏分区（即包含大量零）恢复期间查看驱动器的智能属性total_LBA_written（或等效属性）时，事实证明，即使是完全置零的块也会包含在该属性中，这意味着它们也会消耗闪存写入周期。
因此，我正在寻找一种方法来仅覆盖备份流源和目标驱动器中不同的那些块。典型用例可能是：
进行备份，然后在短时间内对驱动器进行少量更改后恢复它：只有少量不同的块会被覆盖。
创建
blkdiscard驱动器，然后在其上恢复稀疏备份：只有少量非零块会被覆盖。
我不想担心我的分区有 FS（或缺少 FS）。
可以使用哪些工具和方式来实现我的目标？
UPD：根据评论中的建议，我可以尝试：
rsync超过块设备bscp其功能几乎相同的实用程序rsync- 对于
blkdiscard'ed 驱动器（即包含全零），dd conv=sparse可以使用。
这些都是不错的工具，我会尝试它们，但是，它们并没有实现我的完整目标：能够使用溪流(rsync和bscp) 而不仅仅是先前清零的目标驱动器 ( dd conv=sparse)。
答案1
这毫无意义；无论如何，闪存抽象层必须在覆盖数据之前读取数据（因为您写入的块通常与纠错代码块的大小不同），因此它从一开始就不会覆盖相同的数据。另请注意，您的闪存可能与您想象的完全不同 - 您看到的 LBA 块对于磨损均衡算法实际上毫无意义（该算法适用于内部块大小，并且还必须合并用于相当复杂的错误的存储） -无论如何，您需要的校正数据）和实际的物理介质。
因此，坦率地说，一旦您每周执行的完整备份恢复次数超出了您的计算范围，我就会担心写入周期。你似乎不这么认为。
我不想担心 FS（或缺少 FS）
那么，内置快照的写入时复制文件系统将完全解决您的问题。 （再说一遍，了解更多，但不是全部，关于闪存内部工作原理，所以我怀疑我们在这里提出的任何聪明的方案会比 CoW/快照更好，因为它们永远不会覆盖数据） 。
Linux 默认带有这样的文件系统。
我的分区有。
那么，使用带快照的 LVM 精简卷代替分区，“仅覆盖更改的部分”就失去了意义，因为在恢复备份时，您不会覆盖更改的部分，而只是忘记了复制-修改-写入副本中的更改。原始数据。您还可以将外部备份存储与该方案结合起来，但这样做会导致太过分。