web-dev-qa-db-ja.com

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

LVMシンとVM 130ボリューム/ dev/pve/vm-130-disk-0を内部に持つスタンドアロンProxmoxノードを用意します。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）が失敗したためアクティブ化できません：利用可能なデータがありません復元中に、ここのようにLVMを損傷する「lvconvert--repair」を使用することを余儀なくされました https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 リンクからの回避策は、pve/dataをアクティブ化するのに役立ちますが、/ dev/pve/vm-130-disk-0はアクティブ化しません。

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

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

  4. 'undrop-for-innodb'がディスク全体/ dev/sda3を検索するリカバリmysqlテーブル。私が探しているDBを含め、さまざまなデータベース用に12GBのページを取得しました。しかし、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/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

アドバイスやアイデアをいただければ幸いです。ありがとう！

mysqllvmext4data-recovery
1
Alan Tone

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

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

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

これは非常に手動で、複雑で時間のかかるプロセスです。それ以外の場合はデータベースを回復してから、事後分析でバックアッププロセスを確認します。

0
akuzminsky

最初はLVMを復元する必要があると思います。そして、ファイルシステムでmysqldbファイルを復元する方法を考えてください。

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

0
uor