主页 / user-557095

Alan Tone's questions

Martin Hope
Alan Tone
Asked: 2020-01-30 08:10:17 +0800 CST
  • 1

服务器具有带有几个卷的 Thin LVM：

vm-130-disk-0 - was deleted and need to be restored.
vm-137-disk-0 - was NOT deleted.

尝试恢复在删除之前创建的 /etc/lvm/archive/pve_00336-2034680334.vg：

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0
      Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311.
      ...

# lvs -a              
  LV              VG   Attr       LSize   Pool Origin Data%  Meta%
  data            pve  twi---tz--   1.57t      # NOT activated pool data
  [data_tdata]    pve  Twi-a-----   1.57t      # OK  a=Activated
  [data_tmeta]    pve  ewi-a-----  16.00g      # OK  a=Activated                                              
  root            pve  -wi-a-----  10.00g      # OK  a=Activated                                 
  vm-130-disk-0   pve  Vwi---tz--  32.00g data # NOT activated deleted volume
  vm-137-disk-0   pve  Vwi---tz--  22.00g data # NOT activated non-deleted volume
  ...

好吧，这里我们失败了，因为 tmeta 和 tpool 之间的事务不匹配。互联网上大多数回答的人都有镜像情况：tpool=312 和 tmeta=324，看起来像 .vg 文件中的 transaction_id 修复对他们有帮助。让我们尝试修复 .vg 文件并激活：

Changed by hands transaction_id from 311 to 324 in /etc/lvm/archive/pve_00336-2034680334.vg ..

# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0
   device-mapper: reload ioctl on (254:19) failed: No data available

In debug log appears: pve-vm--130--disk--0: Skipping NODE_DEL [trust_udev]

# lvs -a
  LV              VG   Attr       LSize   Pool Origin Data%  Meta%
  data           pve  twi-aotz--   1.57t             5.86   0.44  # OK
  [data_tdata]   pve  Twi-a-----   1.57t                          # OK                      
  [data_tmeta]   pve  ewi-a-----  16.00g                          # OK                      
  root           pve  -wi-a-----  10.00g                          # OK                      
  vm-130-disk-0  pve  Vwi---tz--  32.00g data                     # NOT activated deleted volume
  vm-137-disk-0  pve  Vwi-a-tz--  22.00g data        67.91        # OK activated non-deleted volume
  ...

已删除卷的“无可用数据”。伤心。AFAIK tpool 有 transaction_id=324，我需要以某种方式将 tpool 回滚到 312。不知道怎么做。

我可以用什么激活 pve/vm-130-disk-0 ？

# lvm version
  LVM version:     2.02.168(2) (2016-11-30)
  Library version: 1.02.137 (2016-11-30)
  Driver version:  4.35.0

# uname -a
Linux adminslotlogicrestoreasap 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux

谢谢阅读！我将不胜感激任何建议。

lvm disk-volume data-recovery
Martin Hope
Alan Tone
Asked: 2020-01-25 08:17:35 +0800 CST
  • 1

拥有独立的 Proxmox 节点，其中包含 LVM Thin 和 VM 130 卷 /dev/pve/vm-130-disk-0。VM 130 被意外删除。Mysql 数据库随 VM 丢失。在我们发现它一天后，该节点上的所有虚拟机都已停止以防止写入 /dev/pve。新备份也被删除，没有恢复的机会。删除后没有创建新的虚拟机。

如何从丢失的卷（以前称为 /dev/pve/vm-130-disk-0）中恢复数据库表？

我尝试过的（没有运气）：

  1. 将 vm130 上的 LVM 元数据回滚到删除时刻。由于命令“lvs”的输出，我可以看到卷 /dev/pve/vm-130-disk-0，但它处于非活动状态并且无法激活，因为出现错误：device-mapper: reload ioctl on (253:7) failed ：没有可用数据恢复时我被迫使用“lvconvert --repair”损坏了LVM，就像这里https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 链接的解决方法有助于激活pve/数据，但不是 /dev/pve/vm-130-disk-0。

  2. testdisk 在物理磁盘 /dev/sda3 上查找 VM 分区。找到了 18 个分区，但没有人知道来自 VM 103 的测试字符串。使用 bgrep 进行测试。请注意，这些分区不涵盖整个物理磁盘。

  3. 使用 bgrep 搜索来自 VM 130 的 /dev/sda3 文本字符串。在 testdisk 创建的 VM 分区之外的磁盘上的两个不同位置中找到的字符串。

  4. 使用“undrop-for-innodb”搜索整个磁盘 /dev/sda3 来恢复 mysql 表。为不同的数据库获得了 12 GB 的页面，包括我正在寻找的数据库。但是字典/SYS_TABLES.sql 会产生巨大的表 ID，例如 5643947289462206311 和奇怪的符号 \0！在表名中：

    2020203D2020 4E414D455F434F SYS_TABLES "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0std\n\0\0!\0!\0 !\0database_name\0INSERT INTO tbl_log_\n SET log_id " 5643947289462206311 NULL NULL 1600742439 "" 741488441

    此外，使用这些巨大的表 ID，dictionary/SYS_INDEXES.sql 什么也找不到。很好的方法在这里的第一个答案：https ://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database

在 /dev/pve/vm-130-disk-0 内部：

# fdisk -l

     Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     Disklabel type: dos
     Disk identifier: 0x65ab60ca

     Device     Boot    Start      End  Sectors  Size Id Type
     /dev/sda1  *        2048 64286719 64284672 30.7G 83 Linux
     /dev/sda2       64288766 67106815  2818050  1.4G  5 Extended
     /dev/sda5       64288768 67106815  2818048  1.4G 82 Linux swap / Solaris

     Above /dev/sda1 is ext4 with mysql database files.

mysql
     - mysql-server-5.5               5.5.47-0+deb8u1                  amd64
     - tables stored in innoDB format.
     - tables stored in separate files (my.cnf):
            innodb_file_per_table = 1
     - binary log forced enabled, but it rotated very othen:
            expire_logs_days    = 7

Proxmox 详细信息：

# uname -a
    Linux wz020 4.15.18-12-pve #1 SMP PVE 4.15.18-35 (Wed, 13 Mar 2019 08:24:42 +0100) x86_64 GNU/Linux
# pveversion
    pve-manager/5.4-3/0a6eaa62 (running kernel: 4.15.18-12-pve)
# pvs
    PV         VG  Fmt  Attr PSize PFree
    /dev/sda3  pve lvm2 a--  1.64t 6.00g
# vgs
    VG                           #PV #LV #SN Attr   VSize VFree
    pve                            1  26   0 wz--n- 1.64t 6.00g

我将不胜感激任何建议和想法。谢谢！

mysql lvm ext4 data-recovery