제거된 Proxmox VM에서 MySQL 테이블 복구

제거된 Proxmox VM에서 MySQL 테이블 복구

내부에 LVM 씬 및 VM 130 볼륨 /dev/pve/vm-130-disk-0이 있는 독립 실행형 Proxmox 노드가 있습니다. VM 130이 실수로 삭제되었습니다. VM에서 MySQL 데이터베이스가 손실되었습니다. 하루 만에 이를 발견한 후 /dev/pve에 쓰기를 방지하기 위해 이 노드의 모든 VM이 중지되었습니다. 복구 가능성 없이 새로운 백업도 삭제되었습니다. 삭제 후 새 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 : 사용할 수 있는 데이터가 없습니다. 복원하는 동안 여기와 같이 LVM을 손상시킨 "lvconvert --repair"를 사용해야 했습니다.https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 링크를 통한 해결 방법은 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 파티션 외부 디스크에 있는 서로 다른 두 문자열에서 문자열이 발견되었습니다.

  4. 전체 디스크 /dev/sda3을 검색하는 'undrop-for-innodb'를 사용하여 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

프록시목스 세부정보:

# 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

전체 디스크 /dev/sda3을 검색하는 'undrop-for-innodb'를 사용하여 mysql 테이블을 복구합니다. 내가 찾고 있는 DB를 포함하여 다양한 데이터베이스에 대해 12GB 페이지가 있습니다. 그러나 Dictionary/SYS_TABLES.sql은 5643947289462206311과 같은 거대한 테이블 ID와 이상한 기호 \0을 생성합니다! 테이블 이름에:

테이블 이름으로 인덱스를 찾으려면 SYS_TABLES/가 필요합니다 . SYS_INDEXESSYS_*가 손상된 것 같습니다(또는 stream_parser실수로 속하지 않는 페이지를 발견했을 수도 있습니다).

따라서 SYS_* 테이블은 없지만 데이터가 12G 상당의 페이지 어딘가에 있기를 바랍니다. 무엇을 해야 할까요? 노력하다 grep. 예를 들어 테이블에 문자열이 있어야 한다는 것을 알고 있는 경우 [email protected]해당 문자열이 포함된 인덱스를 찾은 다음 해당 c_parser테이블이 실제로 찾고 있는 테이블인지 확인합니다.

이는 매우 수동적이고 복잡하며 시간이 많이 걸리는 프로세스입니다. 그렇지 않으면 데이터베이스를 복구한 다음 사후에 백업 프로세스를 검토하겠습니다.

답변2

처음에는 LVM을 복원해야 한다고 생각합니다. 그런 다음 파일 시스템에서 mysql db 파일을 복원하는 방법에 대해 생각해 보십시오.

비슷한 질문: 삭제된 LVM 논리 볼륨에서 ext4 파일 시스템을 복구할 수 있는 방법이 있습니까?

관련 정보