☰

如何仅备份 GPT 分区和文件系统类型（无文件/文件夹）？

tag-icon • tag-icon filesystems backup restore cloning
如何仅备份 GPT 分区和文件系统类型（无文件/文件夹）？

为了灾难恢复的目的，我们确实希望备份：

  1. GPT分区表，
  2. 磁盘几何（恢复到不同大小的驱动器）
  3. 以及每个分区对应的文件系统类型和文件系统设置。

例如rsync可以做剩余文件和文件夹的备份和恢复部分。 GPT 分区磁盘上的五个分区及其 FAT 和 RAID-1 样式 BTRFS 文件系统也需要备份。

Sgdisk不恢复文件系统

有sgdisk驱动器备份和恢复命令。这仅备份和恢复分区配置，而不会恢复相应分区上的文件系统。

File确实输出许多文件系统详细信息

# file -sL /dev/sda?
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 32, heads 64, hidden sectors 8192, sectors 2097152 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 2048, reserved 0x1, serial number 0x7181b420, unlabeled
/dev/sda2: BTRFS Filesystem label "root", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=b81e9d42-c0a2-4a1e-8197-f6775419f654, 3018244096/20971520000 bytes used, 1 devices
/dev/sda3: BTRFS Filesystem label "home", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=2cf4e529-b242-4913-b283-fd18df73316a, 194707456/9965666304 bytes used, 1 devices

有可能对输出进行备份file -sL，但仍然缺少如何恢复这部分。

在线备份

我们需要一个在线（不必关闭系统来进行备份）“克隆”命令，该命令不会备份文件夹和文件本身。换句话说，可以恢复文件和文件夹之前的所有驱动器配置（使用不同的工具）。

命令？

哪些命令在文件和文件夹之前负责驱动器灾难恢复？

注意：相对于必须输入多个命令，单行语句会得到更好的答案。

答案1

仅考虑 GPT 分区表，您应该使用明智的备份

export DISK=/dev/sda
echo -e "b\n/tmp/gpt-backup-"${DISK##*/}"\nq\n" | gdisk $DISK

但这个备份是二进制格式的。

就我的目的而言，我总是更喜欢简单的gdisk -l /dev/sda.除非您需要恢复到完全相同的设备，否则文本备份是更好的选择，因为无论如何您都需要进行调整。

根据我个人的经验，我总是需要恢复内容，但文件系统类型本身通常是无关紧要的。只要目标安装点适合您要恢复的数据并提供与以前相同的功能（ACL、扩展属性、硬链接），您就可以从基于 rsync 的备份进行恢复。

一般来说，指导方针是备份相关数据，而不是磁盘上的精确布局。这使得过程简单、易于验证并且独立于实践中不需要的细节。

答案2

分区表已经在另一个答案中涵盖了。

对于 (S)ATA 上大于约 128 GiB（或正好 2^28 块）和 SCSI 上约 8 GiB 的磁盘，旧的 C/H/S 样式磁盘几何结构已过时且无关紧要：磁盘真正关心的唯一事情是LBA块号。磁盘上的实际物理几何结构比C/H/S更复杂：例如，为了达到必要的存储密度，外磁道将比内磁道具有更多的扇区。

除非您使用一些非常旧的文件系统类型来尝试基于几何的性能优化，否则磁盘几何应该对文件系统内容完全没有影响。

通常，我将“备份文件系统”理解为备份其中的文件和目录。但是，您已经这样做了，并且正在考虑备份文件系统配置设置以及其他文件系统级元数据。不幸的是，这是特定于文件系统类型的，因此不可能有一个命令适用于所有文件系统。有时，在创建文件系统后，其中一些内容无法更改，因此您应该考虑以下方面：重新创造而不是恢复恢复文件和目录之前文件系统的配置。

命令的输出lsblk -f或blkid将告诉您文件系统标签、UUID（或“卷序列号”，因为 VFAT 文件系统 ID 不是真正的 UUID）。您可能希望记录这些内容，并在灾难恢复上下文中重新创建文件系统时明确指定它们。

所以，最终的答案是：记录用于创建文件系统的命令， 和重复使用相同的命令（可能进行修改以考虑在线容量扩展等）以在恢复场景中重新创建它们。如果您有用于部署新系统的标准化/自动化程序，也许您也可以在灾难恢复中重复使用该程序（部分）？

但既然你使用的是 BTRFS，你应该知道拥有多个具有相同 UUID 的已挂载文件系统可能很危险，因为 BTRFS 驱动程序可以假设它们只是访问相同文件系统内容的多个路径，因此可能会损坏内容。我认为近年来已经添加了一些针对此问题的保护措施，但我认为它还不是完美的。创建 BTRFS 文件系统磁盘副本（外观）的任何过程必须请确保在尝试将副本安装到使用原始副本的同一系统中之前，将副本的 UUID 替换为唯一的 UUID。这不仅包括磁盘映像备份，还包括基于 SAN 的文件系统快照。

在 BTRFS 本身内创建的任何快照都可以；文件系统根据定义了解它们。当通过 BTRFS 外部的方式创建表观克隆时，就会出现问题：拆分 RAID1 集、克隆磁盘或告诉 SAN 存储系统对特定 LUN 进行快照并将快照呈现为新 LUN 可能存在风险，除非存在在实际挂载新快照/副本之前，明确程序以更改文件系统 UUID。

在工作中，我们有一个客户广泛使用 SAN 级快照和克隆过程：他们可能会克隆生产文件系统来测试应用程序更新，然后在经过测试并发现良好后将克隆呈现给生产系统。他们迟早会拥有两个文件系统，这两个文件系统最初是作为克隆对（但从那时起具有非常不同的生活）呈现给同一主机的。然后他们开始收到各种“重复 UUID”错误，我参与修复它。一旦更改了适当的 UUID 以使 UUID 再次唯一，一切就都顺利了。然后我们完成了他们的过程，并添加了缺少的步骤，以在克隆磁盘的任何步骤之后更改 UUID，以防万一克隆磁盘对的两半稍后都将呈现给同一系统。

幸运的是，他们没有使用 BTRFS……但他们确实使用了 LVM，它对此类事件具有令人惊讶的强大保护。每当您获得具有相同 UUID 的多个 LVM PV 时，LVM 工具都会大声抱怨，并迫使您在执行其他操作之前弄清楚发生了什么并修复它。如果热插入新的 LVM PV，LVM 仅在没有任何歧义的情况下才会自动启用它们。

device-mapper-multipath（LVM 期望在 LVM 看到磁盘之前，任何多路径都应该已经被处理或类似处理。与 ZFS 一样，BTRFS 似乎也集成了类似 LVM 的功能。）

相关内容