☰

削除された Proxmox VM から MySQL テーブルを回復する

tag-icon • tag-icon mysql lvm ext4 data-recovery
削除された Proxmox VM から MySQL テーブルを回復する

スタンドアロンの Proxmox ノードに LVM シンと VM 130 ボリューム /dev/pve/vm-130-disk-0 があります。VM 130 は誤って削除されました。Mysql データベースは VM とともに失われました。1 日で発見した後、このノードのすべての VM は /dev/pve への書き込みを阻止するために停止されました。新しいバックアップも削除され、回復の可能性はありませんでした。削除後、新しい VM は作成されませんでした。

失われたボリューム (以前は /dev/pve/vm-130-disk-0 と呼ばれていました) からデータベース テーブルを回復するにはどうすればよいですか?

私が試したこと（運がなかった）:

  1. vm130 の LVM メタデータを削除時点にロールバックします。コマンド「lvs」の出力の結果として、ボリューム /dev/pve/vm-130-disk-0 が表示されますが、エラー: device-mapper: reload ioctl on (253:7) failed: No data available のため非アクティブでありアクティブ化できません。復元中に、「lvconvert --repair」を使用する必要があり、ここでのように LVM が破損しました。バグ: リンクからの回避策は pve/data のアクティブ化に役立ちますが、/dev/pve/vm-130-disk-0 のアクティブ化には役立ちません。

  2. testdisk は物理ディスク /dev/sda3 上の VM パーティションを検索します。18 個のパーティションが見つかりましたが、VM 103 からの既知のテスト文字列はありません。bgrep でテストしました。これらのパーティションは物理ディスク全体をカバーしているわけではないことに注意してください。

  3. VM 130 からの /dev/sda3 テキスト文字列を bgrep で検索しています。testdisk によって発見された VM パーティション外のディスク上の 2 つの異なる場所に文字列が見つかりました。

  4. 'undrop-for-innodb' を使用してディスク /dev/sda3 全体を検索し、mysql テーブルをリカバリします。探している DB を含むさまざまなデータベースに対して 12 GB ページを取得しました。ただし、dictionary/SYS_TABLES.sql は、5643947289462206311 のような巨大なテーブル ID と、テーブル名に奇妙な記号 \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 NULL 1600742439 "" 741488441

    また、dictionary/SYS_INDEXES.sql は、これらの巨大なテーブル ID を使用しても何も見つけることができません。最初の回答に良いハウツーがここにあります:https://dba.stackexchange.com/questions/23251/mysql データベースの削除を回復する方法はありますか?

/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

アドバイスやアイデアがあれば、ぜひ教えてください。ありがとうございます!

答え1

'undrop-for-innodb' を使用してディスク /dev/sda3 全体を検索し、mysql テーブルをリカバリします。探している DB を含むさまざまなデータベースに対して 12 GB ページを取得しました。ただし、dictionary/SYS_TABLES.sql は、5643947289462206311 のような巨大なテーブル ID と、テーブル名に奇妙な記号 \0! を生成します。

SYS_TABLESテーブル名でインデックスを見つけるには/ が必要ですSYS_INDEXES。SYS_* が破損しているようです (または、stream_parser誤って属していないページを見つけた可能性があります)。

つまり、SYS_* テーブルはありませんが、これらの 12G 相当のページのどこかにデータがあるはずです。どうすればよいでしょうか? を試してくださいgrep。たとえば、テーブルに文字列が含まれている必要があることがわかっている場合は、その文字列を含むインデックスを見つけて、それが本当に探しているテーブルであるかどうか[email protected]を確認します。c_parser

これは非常に手作業が多く、複雑で時間のかかるプロセスです。それ以外の場合はデータベースの回復を試み、事後検証でバックアップ プロセスを確認します。

答え2

まず LVM を復元する必要があると思います。その後で、ファイル システム内の mysql db ファイルを復元する方法を検討してください。

同様の質問: 削除された LVM 論理ボリュームから ext4 ファイルシステムを回復する方法はありますか?

関連情報