Я хочу восстановить данные из раздела XFS. Кажется, мне нужно xfs_repair раздела, но я не уверен, что потеряю данные, поэтому предпочитаю обратиться к экспертам. Я запускаю Virtual Box Linux Mint. Вот что я сделал:
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
Раздел, который я хочу восстановить, - это / 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).
Потом попробовал смонтировать
sydney@sydney-VirtualBox ~ $ sudo mount /dev/md3 /mnt/pik
mount: Structure needs cleaning
Я попытался 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.
Итак, я сначала запустил в безопасном режиме 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.
Что будет следующим шагом? xfs_repair /dev/sdb4 или xfs_repair -L /dev/sdb4 Кажется, что -L может вызвать потерю данных.
РЕДАКТИРОВАТЬ Почему я сбежал mdadm?
sydney@sydney-VirtualBox ~ $ sudo -t xfs mount /dev/sdb4 /mnt/storage
mount: unknown filesystem type 'linux_raid_member'
После поиска ошибки было решено запустить mdadm команда.