มีโหนด Proxmox แบบสแตนด์อะโลนที่มี LVM thin และ VM 130 volume /dev/pve/vm-130-disk-0 อยู่ข้างใน VM 130 ถูกลบโดยไม่ได้ตั้งใจ ฐานข้อมูล Mysql หายไปกับ VM หลังจากที่เราค้นพบมันในหนึ่งวัน VM ทั้งหมดบนโหนดนี้จะหยุดเพื่อเปลี่ยนการเขียนไปยัง /dev/pve การสำรองข้อมูลใหม่ก็ถูกลบเช่นกันโดยไม่มีโอกาสในการกู้คืน หลังจากลบ VM ใหม่ไม่ได้สร้าง

ฉันจะกู้คืนตารางฐานข้อมูลจาก Volume ที่สูญหาย (ก่อนหน้านี้รู้จักกันในชื่อ /dev/pve/vm-130-disk-0) ได้อย่างไร

สิ่งที่ฉันพยายาม (ไม่มีโชค):

  1. ย้อนกลับข้อมูลเมตา LVM บน vm130 เพื่อลบช่วงเวลา ผลที่ได้คือผลลัพธ์ของคำสั่ง "lvs" ฉันสามารถเห็นโวลุ่ม /dev/pve/vm-130-disk-0 แต่มันไม่ทำงานและไม่สามารถเปิดใช้งานได้เนื่องจากข้อผิดพลาด: device-mapper: reload ioctl on (253:7) ล้มเหลว : ไม่มีข้อมูลขณะกู้คืน ฉันถูกบังคับให้ใช้ "lvconvert --repair" ซึ่งทำให้ LVM เสียหายเช่นนี้https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 วิธีแก้ปัญหาจากลิงก์ช่วยเปิดใช้งาน pve/ ข้อมูล แต่ไม่ใช่ /dev/pve/vm-130-disk-0

  2. testdisk เพื่อค้นหาพาร์ติชัน VM บนฟิสิคัลดิสก์ /dev/sda3 พบ 18 พาร์ติชัน แต่ไม่มีใครรู้จักสตริงทดสอบจาก VM 103 ทดสอบด้วย bgrep โปรดทราบว่าพาร์ติชั่นเหล่านี้ไม่ครอบคลุมดิสก์กายภาพทั้งหมด

  3. ค้นหาด้วย bgrep เหนือสตริงข้อความ /dev/sda3 จาก VM 130 พบสตริงในสองที่แตกต่างกันวางบนดิสก์นอกพาร์ติชั่น VM ที่ก่อตั้งโดย testdisk

  4. กู้คืนตาราง mysql ด้วย 'undrop-for-innodb' เพื่อค้นหาทั้งดิสก์ /dev/sda3 มีเพจขนาด 12 GB สำหรับฐานข้อมูลต่างๆ รวมถึง DB ที่ฉันกำลังมองหา แต่ dictionary/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 NULL 1600742439 "" 741488441

    นอกจากนี้ dictionary/SYS_INDEXES.sql ยังไม่พบสิ่งใดโดยใช้ ID ตารางขนาดใหญ่เหล่านี้ Howto ที่ดีในคำตอบแรกที่นี่: 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

ฉันจะขอบคุณสำหรับคำแนะนำและความคิดใด ๆ ขอบคุณ!

answer

Recovery mysql tables with 'undrop-for-innodb' searhing whole disk /dev/sda3. Got 12 GB pages for different databases, including DB which I'm looking for. But dictionary/SYS_TABLES.sql produce huge table IDs like 5643947289462206311 and strange symbols \0! in the table name:

คุณต้องSYS_TABLES/ SYS_INDEXESเพื่อค้นหาดัชนีตามชื่อตาราง ดูเหมือนว่า SYS_* ของคุณจะเสียหาย (หรืออาจstream_parserพบหน้าที่ไม่เหมาะสมโดยไม่ได้ตั้งใจ)

ดังนั้นไม่มีตาราง SYS_* แต่หวังว่าข้อมูลของคุณจะอยู่ที่ไหนสักแห่งในหน้ามูลค่า 12G เหล่านี้ จะทำอย่างไร? ลองgrep. ตัวอย่างเช่น ถ้าคุณรู้ว่าตารางต้องมีสตริง[email protected]ให้ลองค้นหาดัชนีที่มีตารางนั้น จากนั้นตรวจสอบc_parserว่าเป็นตารางที่คุณต้องการจริงๆ หรือไม่

เป็นกระบวนการที่ใช้คนมาก เกี่ยวข้อง และใช้เวลานาน ฉันจะพยายามกู้คืนฐานข้อมูลเป็นอย่างอื่น จากนั้นตรวจสอบกระบวนการสำรองข้อมูลของคุณในการชันสูตรพลิกศพ

ฉันคิดว่าในตอนแรกคุณควรกู้คืน LVM จากนั้นให้นึกถึงวิธีกู้คืนไฟล์ mysql db ในระบบไฟล์

คำถามที่คล้ายกัน: วิธีใดในการกู้คืนระบบไฟล์ ext4 จากโลจิคัลวอลุ่ม LVM ที่ถูกลบ