No Volumes No Shares - Superblock Issue?

[NigelBrownless]

Code: Select all

mount -o ro /dev/md4 /mountpoint

Worked :applause

I looked inside the directory and see...

Code: Select all

root@fvdw-sta-kirkwood:/mountpoint # ls
afp_db       autoupdate   images       lost+found   shares       tmp          torrent_dir  var

And in the "shares" directory there are some numbered folders that look like they contain some familiar data.

So I think I just need to go through them now, and copy the files off to another location?
What is the best method of copying files?

[fvdw]

:punk finally some succes lets hope it contains the files you need. I would also look in tmp and lost+found folders. As lcie firmware could have moved files there.
For copying files you could use vsftp server which is included in the fvdw-sl console (uploaded when you uploaded the tools) that would enable you to use an ftp client to search an copy files or directories.

To start the ftp server give this command

Code: Select all

vsftpd &

After that you can logging using a ftp client like filezilla
username: root
password: giveit2me
You will get access to system root (/) with full read/write permissions

NOTE:
Of course it is important to remember to use in the client always "binairy" transfer mode to avoid corrupting of data when transferring types seen as text file (I learned the hard way when backing up the forum once :mrgreen: )

see also here https://plugout.net/viewtopic.php?f=2&t=2513&hilit=vsftp#p22715

I find it peculiar that we found SB's every 4096 MB and 465 AG's and now the repaired file system is using only 4 AG's with size of about 500GB as indicated in the original primary SB. What has happened with this filesytem to get the 465 AG's and SB's which are apparently useless. :scratch Do you have any idea?

[fvdw]

you could also try to fire up the lacie firmware and let it access the raid, should work now, but I am not sure what it will do with the data. Maybe better to first try to get the data copied which are of value to you using vsftp and standalone kernel

[NigelBrownless]

I connected via FTP after starting the Server and managed to download all of the files from the "Shares" directory.
Nothing in "Lost+Found" or "Tmp". So all files seem to have been recovered successfully.

Once that had completed, I rebooted the Lacie and let it start normally. Once back into the native Lacie Admin, all of the Shares had re-appeared and I could map it to a Drive on my Mac, so it is all back running how it used to be, with full access to the files outside of the Kernel.

I find it peculiar that we found SB's every 4096 MB and 465 AG's and now the repaired file system is using only 4 AG's with size of about 500GB as indicated in the original primary SB. What has happened with this filesytem to get the 465 AG's and SB's which are apparently useless. :scratch Do you have any idea?

The issues occurred, when I was trying to copy lots of data from the Lacie to a new Synology NAS, Ironically! I was also removing redundant data on the Lacie, before copying, and during this process we lost power. When power was restored, that was when the Shares all disappeared and the File System became corrupt. Assume this was the culprit?

[fvdw]

Maybe it was caused by the power cut and startup after it, but still why set up 465 AG with wrong size and in it SB'with data for 4 AG's of 500 GB. It doesn't make sense to me. Note if it has written 465 SB after the power cut then it might have overwritten some data on the disk , so some files may be corrupt or partly lost
Anyhow you have your data back and I have learned something more on XFS file systems :-D merry christmas

[NigelBrownless]

Thank you so much for your perseverance on this. It is much appreciated.
I have no idea how it got corrupted, but it seems as if I got lucky in the end.
Your support has been magnificent. Seasons Greetings to you too.

[NigelBrownless]

Once I've made sure I've got copies of any relevant data off the Lacie Drive, I'm planning on Formating/Resetting it back.
Before I do, is there anything that you would like me to download to aid any further investigations/analysis in the future for your Learnings, before it is wiped?

[fvdw]

Hi, thx yes there is a request, I would like to see whats now in the primairy superblock this to compare with the old one and learn from the changes

Code: Select all

dd if=/dev/md4 bs=1M count=1 of=sb-repaired.img

[NigelBrownless]

Result of

Code: Select all

dd if=/dev/md4 bs=1M count=1 of=sb-repaired.img

attached....

[fvdw]

Only a few differences with original bad SB

Code: Select all

differences
byte 100-101: file system version and flags  A4 F4-> A4 E4
byte 148-151: number of free blocks  03 CD 16 A3 -> 03 CD 55 E2
byte 160-167:  user quota inode  00 00 00 00 00 00 00 83 -> 00 00 00 00 00 00 00 9B
byte 168-175:  group quota inode 00 00 00 00 00 00 00 84 -> 00 00 00 00 00 00 00 9F

Number of free blocks I can imagine.
The user and group quota I would expected not to be required but probably the lacie firmware has enabled quota use
Maybe it is also the reason for differences in the file system version and flags settings. Cannot find info on this on the internet.

:dontknow