4

I want to recover data from a XFS partition. It seems that I need to xfs_repair the partition but I am not sure I would lose the data, so I prefer to ask to experts. I run a Virtual Box Linux Mint. Here is what I did:

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

The partition I want to recover is /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).

Then I tried to mount it

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

I tried 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.

So I first ran in safe mode 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.

What would be the next step? xfs_repair /dev/sdb4 or xfs_repair -L /dev/sdb4 It seems that -L may cause data loss.

EDIT Why did I run mdadm?

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

After looking up the error, the solution was to run the mdadm command.

Sydney
  • 141
  • 1
  • 4
  • You forgot to tell us about your mdadm RAID. – Michael Hampton Jun 07 '15 at 15:47
  • I am sorry but I don't know what is mdadm RAID. I took the hard drive from a friend who wants me to recover the data. What information do you need? Thanks – Sydney Jun 07 '15 at 16:59
  • Then why are you running mdadm assemble commands on it? – Michael Hampton Jun 07 '15 at 17:05
  • Because I got an error when trying to mount. See edit – Sydney Jun 07 '15 at 17:36
  • 1
    Your "friend" needs to give you both disks, not just one. And, you should not be doing this at all. You're more likely to destroy whatever's left of his data than to recover it. Have him seek help from a data recovery company if it's actually important. – Michael Hampton Jun 07 '15 at 17:41
  • Have you tried running XFS recovery utility? I've heard that these utilities were crucial and really takes care of your data if it's lost or has been deleted accidentally. Can't assure you exactly if it works on your case or not. – nathandgeek Jun 09 '15 at 09:42

0 Answers0