Began many years ago on an OpenMediaVault 2.0 box. Started with an array of two data disks and one parity disk, all 3TB. Shortly after the initial setup I wanted to test recovery to be sure I was happy with the program. I basically followed the online manual and the result was perfect.
My use case is basically sync and scrub every three days using a script I found online and look over the emailed reports. Never got any type of unexpected result. Never had to do a for real full disk recovery but have recovered a few accidentally deleted files along the way. My server has 12 internal bays so when they were all filled up the way to grow it without adding an external DAS box was to replace old small disks with new big disks. I used dd growpart, e2fsck, and resize2fs for this in the shell. Never had any problems with anything. Very happy with the program. Keep up the good work!
Now for the problem. I was doing the above replace small disk with big disk thing and made a error with the dd command, specifically I directed the output to the wrong disk. It went to one of my data disks instead of the new empty disk. Ouch. I immediately disabled the script I use for that sync and scrub operation to be sure not to wreck my chances of recovery.
So I got reconfigured to begin the recovery of the lost data using the snapraid fix command right out of the manual after triple checking the UUID of the empty target disk.
I started the fix and watched it for a while. Big number for that ETA :-) Then I looked in the target disk and saw directories with files in them appearing. One every thirty seconds or so. But when I looked at the files I noticed some of them were much smaller than they should be. They are all MP4 files so I sampled a few with VLC media player. Some wouldn’t play at all, some started to play, but crashed part way through, and some played all the way to the end as they should. In summary what is being recovered are some proper files, and some mangled files.
I don’t know what’s happening here with this recovery. The most recent sync and scrub was the night before I hosed the disk and there was nothing in the emailed report out of the ordinary. So I think I can conclude that all the disks were proper. Sampling all the other data disks, every file I looked at was proper. I ran e2fsck on all disks with no problems.
The array consists of 2x 14TB parity disks , 2x 14TB, 4x 12TB, and 1x 8TB data disks.
Does anyone have any thoughts or suggestions? I had a lot of confidence going into this recovery.
Thanks,
FG
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. I did what you said. Results below.
The fix.log file has many fragments of this: Read error at position 0
Clearly the file sizes are different. The recovered file will not play in VLC Media Player.
The last sync was on 12-28-2023 and ran without any errors. I presume this is where the line from today's snapraid list run came from. It says the file is a little over 2GB
The file recovered today is a little over 524K
Please clarify the disparity.
Thanks
FG
From the **snapraid list** run you suggested here is for one file.
**2125835633** 2023/11/21 04:46 multimedia-content/movies/Love\ Affair\ \(1994\)\ \[1080p\]\ \[BluRay\]\ \[5.1\]\ \[YTS.MX\]/Love.Affair.1994.1080p.BluRay.x264.AAC5.1-\[YTS.MX\].mp4
In the shell where the recovered file sits.
-rw------- 1 fred users **524288** Jan 2 14:23 'Love.Affair.1994.1080p.BluRay.x264.AAC5.1-[YTS.MX].mp4'
Last edit: Fred Grayson 2024-01-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have to wait for the fat lady to sing. "It isn't over until ..."
SnapRAID operations traverse the array from start (Parity_Block #0) to finish (Parity_Block MAX).
In the case of fix, for example, files are incrementally recovered, as their blocks are encountered during this traversal.
You are looking at files whose recovery is still "in progress".
Oh, ye of little faith.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
First a brief history of my use of SnapRAID.
Began many years ago on an OpenMediaVault 2.0 box. Started with an array of two data disks and one parity disk, all 3TB. Shortly after the initial setup I wanted to test recovery to be sure I was happy with the program. I basically followed the online manual and the result was perfect.
My use case is basically sync and scrub every three days using a script I found online and look over the emailed reports. Never got any type of unexpected result. Never had to do a for real full disk recovery but have recovered a few accidentally deleted files along the way. My server has 12 internal bays so when they were all filled up the way to grow it without adding an external DAS box was to replace old small disks with new big disks. I used dd growpart, e2fsck, and resize2fs for this in the shell. Never had any problems with anything. Very happy with the program. Keep up the good work!
Now for the problem. I was doing the above replace small disk with big disk thing and made a error with the dd command, specifically I directed the output to the wrong disk. It went to one of my data disks instead of the new empty disk. Ouch. I immediately disabled the script I use for that sync and scrub operation to be sure not to wreck my chances of recovery.
So I got reconfigured to begin the recovery of the lost data using the snapraid fix command right out of the manual after triple checking the UUID of the empty target disk.
I started the fix and watched it for a while. Big number for that ETA :-) Then I looked in the target disk and saw directories with files in them appearing. One every thirty seconds or so. But when I looked at the files I noticed some of them were much smaller than they should be. They are all MP4 files so I sampled a few with VLC media player. Some wouldn’t play at all, some started to play, but crashed part way through, and some played all the way to the end as they should. In summary what is being recovered are some proper files, and some mangled files.
I don’t know what’s happening here with this recovery. The most recent sync and scrub was the night before I hosed the disk and there was nothing in the emailed report out of the ordinary. So I think I can conclude that all the disks were proper. Sampling all the other data disks, every file I looked at was proper. I ran e2fsck on all disks with no problems.
The array consists of 2x 14TB parity disks , 2x 14TB, 4x 12TB, and 1x 8TB data disks.
Does anyone have any thoughts or suggestions? I had a lot of confidence going into this recovery.
Thanks,
FG
Assuming that you are not getting any error messages while running fix, then I would suspect that the files were bad even before the data loss.
To confirm, you could run snapraid list and compare the size listed with the size of one of the small recovered files.
Unfortunately it means that you won't be able to repair any of the bad files.
Thanks for your reply. I did what you said. Results below.
The fix.log file has many fragments of this: Read error at position 0
Clearly the file sizes are different. The recovered file will not play in VLC Media Player.
The last sync was on 12-28-2023 and ran without any errors. I presume this is where the line from today's snapraid list run came from. It says the file is a little over 2GB
The file recovered today is a little over 524K
Please clarify the disparity.
Thanks
FG
Last edit: Fred Grayson 2024-01-02
You have to wait for the fat lady to sing. "It isn't over until ..."
SnapRAID operations traverse the array from start (Parity_Block #0) to finish (Parity_Block MAX).
In the case of fix, for example, files are incrementally recovered, as their blocks are encountered during this traversal.
You are looking at files whose recovery is still "in progress".
Oh, ye of little faith.
Thank you, I'll grow some more patience and hope. So, will I see the size of a 'bad' file increasing if I look at it from time to time?
Yes. (But, remember: Link.) :)
How true. When the fix is running an oscillating ETA is shown. Is that in hours:minutes?