This is odd. I’m curious and not sure why all of a sudden the BGI is running through the data is safe. It’s supposed to happen when you first configure VD.
It is complicated. I have an 8-disk RAID 50 array where two disks on the same sub-array were marked as "failed", resulting in an apparent complete failure of the array. I did not have a backup so I attempted to image the data off of the "failed" disks using ddrescue. This operation was largely successful but then I was left with somewhat inconsistent RAID metadata since I replaced the "failed" disks with the clones. Instead of trying to edit the metadata I decided to recreate the virtual disk using the fast initialization, thus letting the controller prepare metadata consistent with the current disks. This is tricky and I did this by
1. Imaging the first 8M and zeroing the last 8M of each disk.
2. Returning the disks to the server, recreating the virtual disk and performing a quick initialization, then shutting down the system.
3. Removing the disks, restoring the first 8M to each disk from the saved images, and then returning the disks back to the server.
I had a second array that was not holding valuable data and I experimented with it (even replacing two disks with clones) in order to verify the procedure. The procedure works fine but I did notice that background initialization started soon after the server was restarted with the new metadata. I let the initialization complete and I did not observe any problems with the data on the array (which is consistent with your answer).
Now, since I have your attention, I have another question. I was able to image 99% of one disk and 75% of the other. Thus there is a low but finite probability that I will have data missing in the same stripe on two disks in some places. I understand that this data is lost, but I wonder what background initialization or consistency check will do when it encounters one of these spots? I worry about creating punctures, which will produce even more headaches.
One final note is that, once I cloned the data from the failing disks, I used raid recovery software on a separate computer to backup vital files from the repaired array. This worked fine and I now have a bit of a cushion in case something goes wrong when the disks are re-inserted in the server.
Hello consistency check can help you check bad blocks and that's about it. In order to achieve what you want to do, I think you need to go to the OS level (file level) for a file copy.
Praveen.Singh
3 Apprentice
•
483 Posts
0
March 26th, 2023 00:00
Hello @boulderlund no there is no impact on production.
DELL-Young E
Moderator
•
5.4K Posts
0
March 26th, 2023 20:00
This is odd. I’m curious and not sure why all of a sudden the BGI is running through the data is safe. It’s supposed to happen when you first configure VD.
https://dell.to/40Ehzsk
NOTE Unlike full or fast initialization of virtual disks, background initialization does not clear data from the physical disks.
boulderlund
8 Posts
0
March 26th, 2023 21:00
Young,
It is complicated. I have an 8-disk RAID 50 array where two disks on the same sub-array were marked as "failed", resulting in an apparent complete failure of the array. I did not have a backup so I attempted to image the data off of the "failed" disks using ddrescue. This operation was largely successful but then I was left with somewhat inconsistent RAID metadata since I replaced the "failed" disks with the clones. Instead of trying to edit the metadata I decided to recreate the virtual disk using the fast initialization, thus letting the controller prepare metadata consistent with the current disks. This is tricky and I did this by
1. Imaging the first 8M and zeroing the last 8M of each disk.
2. Returning the disks to the server, recreating the virtual disk and performing a quick initialization, then shutting down the system.
3. Removing the disks, restoring the first 8M to each disk from the saved images, and then returning the disks back to the server.
I had a second array that was not holding valuable data and I experimented with it (even replacing two disks with clones) in order to verify the procedure. The procedure works fine but I did notice that background initialization started soon after the server was restarted with the new metadata. I let the initialization complete and I did not observe any problems with the data on the array (which is consistent with your answer).
Now, since I have your attention, I have another question. I was able to image 99% of one disk and 75% of the other. Thus there is a low but finite probability that I will have data missing in the same stripe on two disks in some places. I understand that this data is lost, but I wonder what background initialization or consistency check will do when it encounters one of these spots? I worry about creating punctures, which will produce even more headaches.
One final note is that, once I cloned the data from the failing disks, I used raid recovery software on a separate computer to backup vital files from the repaired array. This worked fine and I now have a bit of a cushion in case something goes wrong when the disks are re-inserted in the server.
DELL-Young E
Moderator
•
5.4K Posts
0
March 26th, 2023 23:00
Hello consistency check can help you check bad blocks and that's about it. In order to achieve what you want to do, I think you need to go to the OS level (file level) for a file copy.