After buying a good metal USB3 case for 2 HDDs the first thing I've tried was an installation of 2 RAID1 drives mentioned in this post , Unfortunately Windows was unable to properly detect these devices via USB interface marking them as "RAW" and prompted me to initialize them. The worst thing in this cool story is that I completely forgot what is the disk "initialization" :) So I've initilized them! As GPT - since i didnt even recall what type of partitions were used on these disks! And then, then... OH SHI...!!!1 My drives became empty :(
So, after digging into I found that "initializing" generally should not damage data stored on a drive. In short, when initializing, Windows creates a new partition table + creates a strange 128Mb partition table entry. Ok, then I found that GPT partition table is bigger than good old MBR: 34 sectors for GPT VS 1 sector for MBR. This knowledge made me very depressive... This means the heading of TrueCrypt partition will be broken. Although after more investigations I've found that partitions by default for GPT and MBR are aligned by 1Mb, so the 1st partition started at the 63rd sector and thus wasnt damaged! Cool, the 1st 1.5Tb encrypted partition was restored in minutes using TestDisk utility :) The real problem was the 2nd encrypted partition - I didnt know where was it started exactly. To find partition Ive made an image of the drive using dd linux command. Then Ive created the following script:
#! /bin/bash
offset=1610612736000 # somewhere around 1.5Tb offset aligned by 1Mb
while [ $offset -le 1717986918400 ] # upper bound of search
do
losetup -fs /data/raw.img -o $offset # mount /dev/loop0 at offset in bytes
echo "MyPartitionPassword" | truecrypt --text -k "" --protect-hidden=no --mount /dev/loop0 /data/test # try mount a TrueCrypt volume
if [ $? -eq 0 ]; then
echo "FOUND $offset"
truecrypt --dismount /data/test
break
fi
losetup -d /dev/loop0 # unmount /dev/loop0 for the next iteration
offset=$(( $offset + 1048576 )) # next offset to check
done
And this script (running via SUDO) was quickly (in ~5 min of scanning) found the second partition! Note, script didnt stopped after finding at the right offset searching more and more posting error messages - this will affect LOOP devices from loop1 to loop7, but anyway loop0 has right entry point :)
So, what I've learned:
1. Do backup of TrueCrypt headers;
2. Do backup of partition table;
3. RAID1 is not a backup - setup if possible a backup even for RAID;
4. Dont do anything on disk with data - disk image is better (if free space allows that :) )
5. SATA drives via USB displayed incorrectly;
6. Remember what partition table do you use;
7. For RAID1: do anything first using only one of drives :)
So, after digging into I found that "initializing" generally should not damage data stored on a drive. In short, when initializing, Windows creates a new partition table + creates a strange 128Mb partition table entry. Ok, then I found that GPT partition table is bigger than good old MBR: 34 sectors for GPT VS 1 sector for MBR. This knowledge made me very depressive... This means the heading of TrueCrypt partition will be broken. Although after more investigations I've found that partitions by default for GPT and MBR are aligned by 1Mb, so the 1st partition started at the 63rd sector and thus wasnt damaged! Cool, the 1st 1.5Tb encrypted partition was restored in minutes using TestDisk utility :) The real problem was the 2nd encrypted partition - I didnt know where was it started exactly. To find partition Ive made an image of the drive using dd linux command. Then Ive created the following script:
#! /bin/bash
offset=1610612736000 # somewhere around 1.5Tb offset aligned by 1Mb
while [ $offset -le 1717986918400 ] # upper bound of search
do
losetup -fs /data/raw.img -o $offset # mount /dev/loop0 at offset in bytes
echo "MyPartitionPassword" | truecrypt --text -k "" --protect-hidden=no --mount /dev/loop0 /data/test # try mount a TrueCrypt volume
if [ $? -eq 0 ]; then
echo "FOUND $offset"
truecrypt --dismount /data/test
break
fi
losetup -d /dev/loop0 # unmount /dev/loop0 for the next iteration
offset=$(( $offset + 1048576 )) # next offset to check
done
And this script (running via SUDO) was quickly (in ~5 min of scanning) found the second partition! Note, script didnt stopped after finding at the right offset searching more and more posting error messages - this will affect LOOP devices from loop1 to loop7, but anyway loop0 has right entry point :)
So, what I've learned:
1. Do backup of TrueCrypt headers;
2. Do backup of partition table;
3. RAID1 is not a backup - setup if possible a backup even for RAID;
4. Dont do anything on disk with data - disk image is better (if free space allows that :) )
5. SATA drives via USB displayed incorrectly;
6. Remember what partition table do you use;
7. For RAID1: do anything first using only one of drives :)
