- Oct 5, 2002
- 456
- 12
- 18,785
I have a raid array that houses a Windows install I am trying to clone to recover, it's two 1TB SSDs that were setup in a 2TB RAID0 configuration and formatted as a GPT disk.
I managed to recover the array in a virtual way by using images of the raw disks and several tools in Linux. However, since this array only exists virtually this way I would need to clone it to a physical disk to actually use it (I need to be able to actually boot it on the original motherboard it came from to recover some data that is encrypted by my Windows install). So I tried to use dd for that to clone it to a 2TB HDD. I assumed that this would not be an issue as I had cloned the array to a single 2TB HDD before when I needed a copy of my install I would not have to worry about potentially damaging when I tested/experimented with software and tweaks, but would have issues if I ever needed to copy it back to the SSDs because the SSDs were apparently a tiny bit smaller, so I assumed a 2TB HDD would be slightly larger than the array and be able to clone it fine.
However, dd errored out saying it ran out of space with apparently one "record"... whatever a record means... to go: "1907730+0 records in 1907729+0 records out"
I am not sure if this means that once it ran out of space it stopped, or if it ran out of space just barely being one "record" short. I looked at the partitioning of the virtualized raid and saw that the last 400MB or so were unpartitioned space, so I assumed I would likely be fine since it seemed to have run out of space simply copying an unpartitioned area.
However, I was then told that apparently GPT stores a secondary partition table at the end of the drive, and it's possible this did not get copied when it ran out of space.
So first of all... this secondary GPT partition table, is it something like a backup in case the main partition table gets corrupted, similar to MBR having a secondary backup partition table and if it's missing the drive is still fine as long at the main one is intact? Or is it something necessary for the drive to be read properly and/or the OS to boot? And is it something Linux or Windows-specific? Or is having a second partition table at the end of the drive a GPT standard that every OS that supports GPT adheres to?
And second, what if I were to try to clone it to a 3TB HDD then? I would definitely have enough space to do it in that case, but, since dd just does a blind sector-by-sector copy, this would mean that it would just write this end-of-drive secondary partition table somewhere around 2/3rds of the way through the drive, not at the end of it, and I don't know if this would be the same as GPT not seeing a partition table at the end of the drive at all.... since it would not be at the end of it but slightly past the middle of it.
I managed to recover the array in a virtual way by using images of the raw disks and several tools in Linux. However, since this array only exists virtually this way I would need to clone it to a physical disk to actually use it (I need to be able to actually boot it on the original motherboard it came from to recover some data that is encrypted by my Windows install). So I tried to use dd for that to clone it to a 2TB HDD. I assumed that this would not be an issue as I had cloned the array to a single 2TB HDD before when I needed a copy of my install I would not have to worry about potentially damaging when I tested/experimented with software and tweaks, but would have issues if I ever needed to copy it back to the SSDs because the SSDs were apparently a tiny bit smaller, so I assumed a 2TB HDD would be slightly larger than the array and be able to clone it fine.
However, dd errored out saying it ran out of space with apparently one "record"... whatever a record means... to go: "1907730+0 records in 1907729+0 records out"
I am not sure if this means that once it ran out of space it stopped, or if it ran out of space just barely being one "record" short. I looked at the partitioning of the virtualized raid and saw that the last 400MB or so were unpartitioned space, so I assumed I would likely be fine since it seemed to have run out of space simply copying an unpartitioned area.
However, I was then told that apparently GPT stores a secondary partition table at the end of the drive, and it's possible this did not get copied when it ran out of space.
So first of all... this secondary GPT partition table, is it something like a backup in case the main partition table gets corrupted, similar to MBR having a secondary backup partition table and if it's missing the drive is still fine as long at the main one is intact? Or is it something necessary for the drive to be read properly and/or the OS to boot? And is it something Linux or Windows-specific? Or is having a second partition table at the end of the drive a GPT standard that every OS that supports GPT adheres to?
And second, what if I were to try to clone it to a 3TB HDD then? I would definitely have enough space to do it in that case, but, since dd just does a blind sector-by-sector copy, this would mean that it would just write this end-of-drive secondary partition table somewhere around 2/3rds of the way through the drive, not at the end of it, and I don't know if this would be the same as GPT not seeing a partition table at the end of the drive at all.... since it would not be at the end of it but slightly past the middle of it.
Facebook
Twitter
Instagram