Recuperação de dados para partição XFS

Question

Eu quero recuperar dados de uma partição XFS. Parece que preciso xfs_repair da partição, mas não tenho certeza se perderia os dados, por isso prefiro perguntar aos especialistas. Eu corro um Virtual Box Linux Mint. Aqui está o que eu fiz:

sydney@sydney-VirtualBox ~ $ sudo parted -l
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 21,5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  17,2GB  17,2GB  primary   ext4            boot
 2      17,2GB  21,5GB  4293MB  extended
 5      17,2GB  21,5GB  4293MB  logical   linux-swap(v1)


Model: Generic External (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name     Flags
 1      32,9MB  2040MB  2007MB  ext3            primary  raid
 2      2040MB  2303MB  263MB   linux-swap(v1)  primary  raid
 3      2303MB  3315MB  1012MB  ext3            primary  raid
 4      3315MB  1000GB  997GB   xfs             primary  raid

A partição que eu quero recuperar é / dev / sdb4.

sydney@sydney-VirtualBox ~ $ sudo mdadm --assemble --run /dev/md3 /dev/sdb4
mdadm: /dev/md3 has been started with 1 drive (out of 2).

Então eu tentei montá-lo

sydney@sydney-VirtualBox ~ $ sudo mount /dev/md3 /mnt/pik
mount: Structure needs cleaning

Eu tentei xfs_check

sydney@sydney-VirtualBox ~ $ sudo xfs_check /dev/sdb4
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

Então, eu primeiro corri em modo de segurança xfs_repair

sydney@sydney-VirtualBox ~ $ sudo xfs_repair -n /dev/sdb4
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Qual seria o próximo passo? xfs_repair /dev/sdb4 ou xfs_repair -L /dev/sdb4 Parece que -L pode causar perda de dados.

EDITAR Por que corri mdadm ?

sydney@sydney-VirtualBox ~ $ sudo -t xfs mount /dev/sdb4 /mnt/storage
mount: unknown filesystem type 'linux_raid_member'

Depois de procurar o erro, a solução foi executar o comando mdadm .