Opened 8 years ago
Closed 7 years ago
#16099 closed defect (fixed)
Possible Disk Corruption with total data loss, caused by VDI resize.
| Reported by: | mpack | Owned by: | |
|---|---|---|---|
| Component: | virtual disk | Version: | VirtualBox 5.1.6 |
| Keywords: | vboxmanage VDI resize corruption | Cc: | |
| Guest type: | Windows | Host type: | Mac OS X |
Description
I'm writing this to draw attention to a discussion about a VDI disk which seems to have been corrupted (boot sector erased to all zeros) after it was resized by VBoxManage. We've had two or three similar reports in recent weeks, but I think this is the first I've dug into.
Discussion here: https://forums.virtualbox.org/viewtopic.php?f=8&t=80233
The drive had 54933 allocated blocks at the time it was resized, from about 55GB, to exactly 65000MB.
On examining the corrupted header I found that the blockmap had a 4K alignment, but the image started at 1MB - not consistent with a 64GB drive using 4K alignment. I'm wondering if either (a) you have bug whereby a section of resizing code assumes 1MB alignment, or perhaps (b) you attempt to realign the VDI to 1MB boundaries but fail part way through due to a host error. The latter feature would require all blocks to be moved, this might explain why the early sectors are zeroed.
This corruption leaves the drive effectively wiped (no partition map), and all data lost. The shuffling of blocks would render recovery of any data well nigh impossible.
Change History (7)
comment:1 by , 8 years ago
comment:3 by , 8 years ago
I tried looking at ticket #15983, it certainly looks similar. I tried to compare the header provided there, unfortunatedly it appears to be unreadable - either that or WinZip doesn't handle some obscure bz2 variant correctly. Anyway a dev mentioned the fact that the image starts at 1MB, and that would indeed make it similar, since in previous versions the image would have started at 2MB.
comment:4 by , 8 years ago
I added a zip archive with the same content as header.tar.bz2. I hope this works for you.
comment:6 by , 7 years ago
The fix in #15983 solved my problem. If possible you can try it out on your problem instance.
comment:7 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
The fix is part of VBox 5.1.10. Please reopen if necessary.
I forgot to add the observation that block[0], which can usually be counted on to appear at the start of the image (the block map entry will be 0), had instead been relocated to the end. That's what made me suspect you have new code to change the alignment of a drive (in place!).