| 1 |
On 2018.12.17 17:32, Heiko Baums wrote: |
| 2 |
> Am Sat, 15 Dec 2018 18:33:35 -0500 |
| 3 |
> schrieb Jack <ostroffjh@×××××××××××××××××.net>: |
| 4 |
> |
| 5 |
>> Some months ago, I borked a laptop HDD by trying to move a partition |
| 6 |
>> in a way that left both the old and new partitions invalid. (For my |
| 7 |
>> sanity, I've forced the details out of my memory, but the old and |
| 8 |
>> new locations overlapped, and I think the move might have been |
| 9 |
>> interrupted. My own fault, I know.) |
| 10 |
> |
| 11 |
> Have you written anything on this HDD after moving those partitions? |
| 12 |
> And did you move the partitions or did you repartition the HDD? |
| 13 |
At this point, unfortunately, my memory is hazy. I did not |
| 14 |
repartition, but the damage made accessing anything difficult (see |
| 15 |
details below). The additional problem is that now I'm getting |
| 16 |
physical read errors on the drive, so to be safe, I'd need to get |
| 17 |
another drive large enough to use ddrescue, and then go digging. |
| 18 |
> |
| 19 |
> You could try to find the beginning of the old partitions with |
| 20 |
> hexedit and set a pointer to this position with losetup. Set the |
| 21 |
> offset to this position. Linux actually doesn't need partitions to |
| 22 |
> access the HDD and/or mount file systems. Partitions just make it a |
| 23 |
> lot easier. |
| 24 |
At this point, I think I've forgotten the details, but using the |
| 25 |
example of a 300G drive with 100G empty and then a 200G partition, when |
| 26 |
I moved the partition to the beginning of the disk (using gparted, as I |
| 27 |
remember) once it moved more than the first 100G of the partition, it |
| 28 |
overwrote the beginning of the original partition, and once it |
| 29 |
overwrote any of the directory structure it still needed to know where |
| 30 |
stuff was, game over. The first 100G of the "new" partition is |
| 31 |
essentially intact, but the damage to the beginning of the "old" |
| 32 |
partition makes it difficult to start. I suppose I could go looking |
| 33 |
for any intact directory inodes and see whether it's intact enough to |
| 34 |
find anything of interest. (There are really only a few files I would |
| 35 |
still like to recover - but as they are in fact .VDI files, it's likely |
| 36 |
all or nothing, because I don't think just part of one of them will be |
| 37 |
at all useful.) In fact, it would be more acurate to say there was |
| 38 |
another 100G before all of that, and that partition is still intact, |
| 39 |
except for the read errors. |
| 40 |
> |
| 41 |
> And keep in mind that partitions are written to the partition table |
| 42 |
> at the beginning of the drive. Repartitioning usually doesn't |
| 43 |
> overwrite any data. So if you haven't written anything onto the new |
| 44 |
> partitions (incl. formatting the new partitions) all the data is most |
| 45 |
> likely still there. |
| 46 |
The "new" partition is incomplete, but essentially intact, as much of |
| 47 |
it is there. The beginning of the "old" partition is overwitten with |
| 48 |
stuff from somewhere in the middle of the partition being moved. |
| 49 |
> |
| 50 |
> So you could also try to recover your old partition table. Maybe the |
| 51 |
> backup of your old super block is still intact. Unfortunately I can't |
| 52 |
> remember how to find it out. Maybe with fdisk resp. gdisk or with |
| 53 |
> testdisk. |
| 54 |
I know the location of all the partition starts and ends, so that's not |
| 55 |
the issue. I just need lots more empty space to put the copies so I |
| 56 |
can safely go digging. |
| 57 |
> |
| 58 |
> But there is a chance that the behavior of moving partitions is a bit |
| 59 |
> different than repartitioning the HDD, so that the data is actually |
| 60 |
> already overwritten by moving those partitions. |
| 61 |
Exactly. |
| 62 |
> |
| 63 |
> On the other hand, if you had really moved the partitions the |
| 64 |
> partitioning tool you used should have seen that both partitions |
| 65 |
> would overlap and shouldn't have done this. |
| 66 |
I think I mentioned that. I'm going to have to do some testing, and |
| 67 |
probably learn that gparted is smarter than I thought, which means I've |
| 68 |
clearly forgotten something else stupid that I did. Otherwise, I'll |
| 69 |
file a bug against gparted. |
| 70 |
> |
| 71 |
> That said, no matter which problem you have with an HDD, always stay |
| 72 |
> calm and think first before you do anything. In most cases you can |
| 73 |
> recover your data. But the first step is to stop working |
| 74 |
> (particularly writing) with this HDD. The second step is - as the |
| 75 |
> others already mentioned - to make a copy with dd or ddrescue. |
| 76 |
All that would be good and "easy" (for some definition) if the disk |
| 77 |
itself were not in process of failing. |
| 78 |
> |
| 79 |
> I had a lot of HDD crashes, logical and physical ones. And once I |
| 80 |
> even didn't have a backup. I never lost any data so far, not even a |
| 81 |
> bit. |
| 82 |
I'd call that "famous last words" :-) |
| 83 |
> |
| 84 |
> Heiko |
| 85 |
Jack |
Archives