Linux Ubuntu 14.04（Azure 服务器）
我试图备份 /dev/sda1 驱动器，因此我执行了
sudo dd if=/dev/sda1 of=/dev/sdc1
命令。执行命令时可用，但空间显示为负数。我终止了命令。之后我无法打开该驱动器，因此我运行了此命令。
sudo reboot
该磁盘上有一些重要数据。现在我无法在列表中看到已安装的驱动器df -h。
当我尝试安装它时。
sudo mount /dev/sdc1 /datadrive
然后我得到这个输出
sudo: unable to resolve host abc
mount: /dev/sdc1: can't read superblock
有谁知道是什么原因导致了这种行为？
答案1
如果你这样做
sudo dd if=/dev/sda1 of=/dev/sdc1
并且您的数据确实在 sda1 上，那么您的数据在 sda1 上应该仍然是安全的。
其余一切及所有赌注均无效。
答案2
我建议您也备份 MBR dd，以便在磁盘克隆过程之后恢复，重写分区表（只是为了确保万无一失）。
复制 MBR：
~# dd if=<SOURCE_DISK> of=/path/to/mbr_file.img bs=512 count=1
恢复分区表：
~# dd if=/path/to/mbr_file.img of=<DESTINATION_DISK> bs=1 skip=446 count=64
但是，使用dd磁盘备份并不是备份 Linux SO 的最佳选择。处理 *NIX 服务器时，更好的方法是使用tar或rsync（这种方法最适合远程复制），因为在更改文件系统、磁盘大小和分区方案时可以获得更大的灵活性。我总是用它rsync来部署 Linux 服务器。
笔记：对于 NTFS 克隆，我推荐使用 Partimage 作为工具。
答案3
我在那个磁盘上有一些重要的数据。
你指的是 sdc1 吗？如果是的话，从中恢复数据的希望就不大了。
如果执行了 dd 命令，那么 sdc1 头部的数据将被覆盖。超级块位于文件系统的头部。它可能也被覆盖了。这就是您在尝试挂载 sdc1 时收到错误消息的原因。
为了从 sdc1 恢复尽可能多的数据，我的想法是从超级块的备份中恢复超级块。（超级块的副本存储在文件系统的不同位置）并在可读时尝试从 sdc1 复制文件。如果某些文件使用位于分区头部的块，则它们可能会损坏。（这些块已被覆盖）。
这是一个很好的关联关于超级块。
其实我也遇到过和你一样的情况，最后什么都没恢复。
此外，在执行任何恢复步骤之前，请使用 dd 命令备份 sdc1 以防止进一步损坏。