This is a status update, on experiments with Acronis.
In fact, Acronis has been causing some grief for people.
http://forum.acronis.com/forum/31741
Someone here, gives information on what it really takes to
remove the Acronis software. There are two problems. The
extent to which Acronis properly records things in Add/Remove
Programs. And the extent to which their uninstall code,
actually uninstalls things. It does a piss-poor job of
uninstalling.
http://www.wilderssecurity.com/showthread.php?t=316447&page=1
Removal could be considered to be three steps.
1) Find the Acronis product entry in Add/Remove Programs and
uninstall. This leaves a number of relatively benign services.
2) Use ATIH Cleanup.
http://download.acronis.com/ATIH_CleanUp_2012.exe
Now, doing that is largely pointless. On the one hand, it
makes the OS cosmetically cleaner. But it doesn't address
removal of the filter driver that intercepts disk calls.
Touching that can cause the OS to blue screen. The little
cleanup utility, if you look at the INF files, is a
cleanup in name only.
3) The Wilderssecurity thread, is an attempt by someone who
visited the Acronis forums, to help, got booted from the
forum, and sought to post the info elsewhere, to help end
users. Unfortunately, the info isn't in completely friendly
"
sevenforums.com" style recipe. While I have the backups
needed of my system, to attempt to do this, at the moment
I have no need to explore this. I didn't try to clean
any Acronis stuff from my system.
*******
OK, so why is this important ?
I decided to try to reproduce a data recovery effort on a 3TB
drive, using Acronis as a "naive customer". I was trying to
reproduce your problem.
It turns out, due to the un-hygienic nature of the Acronis approach,
I *already had* the Acronis filter driver in place! It appears
I must have installed, for evaluation, the Seagate DiscWizard at
some point in the past. I don't remember doing it, but the
fact I had the accursed filter driver already in my OS, proves
it.
So what happened this time ? This is what I tried.
1) Install 3TB disk.
2) Install Acronis TI OEM (a.k.a Western Digital tool for large disks)
This is effectively the same software as Seagate DiscWizard.
3) I can access the bottom 2.2TB. I cannot access the top 0.8TB.
No way, no how. It won't let me. And the old filter driver it
cannot remove or update, is the reason why!
So then the fun started. Before I began, I did a backup of my system.
I had a backup from a year ago, which I restored, and the Acronis
filter driver was in that one. So that was polluted. I had to go
back two years. Lucky I still had my 06-2011 backup image on
one of the disks in my spare disk pile.
I installed that, checked, and no Acronis filter driver. I
installed the Acronis OEM software, went to the Extended Capacity
Manager, and it worked! I could access the upper portion of the
disk, as two disks. The physical disk, and a virtual disk. And
these are all done, by the filter driver stuff.
Now, if you actually partition inside the Acronis tool, the Acronis
tool does partitions suitable for Windows 7, rather than WinXP.
Partition offset is "1 megabyte", suited to SSDs perhaps. If
I do the partitioning in WinXP itself, the offset is 63 sectors.
So anyway, this is the setup.
+------+----------------+-----------------------+
| MBR | 62 sectors gap | 2.2TB NTFS partition |
+------+----------------+-----------------------+
+------------------+------+-------------------+-------------------------+
| 262144 byte gap | MBR | ~1048576 byte gap | 746.5GB NTFS partition |
+------------------+------+-------------------+-------------------------+
That means, I actually used Windows Disk Management partitioning, for
the immediately visible 2.2TB portion. And used the Acronis Extended
Capacity Manager window, to place a partition on the second chunk.
I suppose I could have gone back, in Disk Management, and deleted and
re-made the partition for the 746.5GB chunk, but I decided to just
leave it. The first partition, is legacy DOS compatible "63 sector"
geometry, while the second is more in tune with Windows 7 "1 megabyte"
offset.
********
OK, so now I have a two-year old version of my system, with a
successful partitioning. I put a couple test files in the upper
portion, as a test.
Now, the question was, what would happen, if I lost access to the
upper portion. For example, if I were to go forward, to my 2013
operating system image, I'd lose access to the upper part.
It turns out, I was able to do data recovery for the upper portion
from Linux. You can do what I did, as long as there is storage
space on the lower partition, to hold a bitmap copy of the thing
labeled "746.5GB" in the above diagram. By using the "disk dump"
program known as "dd", I could make a copy of the upper partition,
then loopback mount it for later.
*******
If you don't want to install the entire Acronis TI OEM, you can just
do the driver portion.
(1,890,091 bytes)
http://kb.acronis.com/system/files/content/2013/01/38937/virtualdisksetup.zip
Unzipped, gives VirtualDiskSetup.msi .
I was able, by installing that on the clean system from 2011, to
regain access to both partitions. So that's another tool option,
if you wanted to try it (like, just after a clean system install
perhaps).
Note that it doesn't create an entry in Add/Remove, and
doesn't clean up after itself etc.
*******
Now, your situation, I think, is something like this.
+------+-----+-----------------------+------------------------+
| MBR | gap | 746GB NTFS partition | 1454GB NTFS partition |
+------+-----+-----------------------+------------------------+
+------+------+-------+-----------------------+
| gap | MBR | gap | 746GB NTFS partition |
+------+------+-------+-----------------------+
And I think you're telling me, the 1454GB one, has gone missing.
You cannot see it.
My guess is, this is related to the NVidia Southbridge, its RAID
capability, and the inclusion of space to store metadata, at the end
of the disk. The NVidia driver (MediaShield), probably wants to leave
space at the end, to store metadata, the day you decide to switch.
Now, perhaps you left the BIOS setting for the NVidia ports at
"RAID", then did JBOD (single disk installation). The NVidia driver
then makes the disk "a couple inches shorter" than it would normally
be. I'm going to redraw that as follows. NVidia makes room for
its metadata, at the peril of snipping off the end of your partition!
This happens, because normally you partition *after* the driver
is installed, and then your partition would be the proper length.
+------+-----+-----------------------+------------------------+--------+
| MBR | gap | 746GB NTFS partition | 1453GB NTFS partition |metadata|
+------+-----+-----------------------+------------------------+--------+
There is a lesson to be learned here. *Never* let the last partition,
touch the "right hand edge" of the disk! Leave a gap on the end, for
stupid stuff like this.
OK, now the info in the NTFS file system, says it is 1454GB long.
NVidia has snipped the end off the partition. The "cannot access block 15xxxxxx"
thing, is caused by an attempt to reach the end of the partition, an
end which is no longer accessible. You are requesting read access,
to a block which is past the end of the disk (as far as the NVidia
*driver* is concerned, not the disk drive itself - the driver is
responsible for messing this up).
Moving the disk to another controller, might change this.
Changing the setting in the BIOS might change it.
Your guy at the shop, would have to make a decision, while
installing the new motherboard, as to what mode to run
in. On page 44 of the N68C-GS FX PDF manual, I see
Onboard SATA Controller [Enabled]
SATA Operation Mode [IDE]
and I feel that would cause the least trouble. If I did that
on an Intel chipset, I could probably get the thing to boot,
even though there was no driver for the chipset, when the new
motherboard was put into place. I don't know exactly, how
I'd get the RAID driver in there, unless perhaps I did a
"repair install" of WinXP.
So anyway, your second partition might reappear, if:
1) Fresh OS (no Acronis).
2) SATA port with no need for a metadata section (IDE mode).
3) At this point, you have access to the first 2.2TB of storage.
4) Install VirtualDiskSetup.msi or use Acronis TI OEM (which
installs the same files), to put the filter driver in place.
Reboot. The upper (virtual) partition will now be visible.
All three partitions should work.
*******
Now, back to the data recovery tutorial.
The problem is, many disk access methods, won't let you go above
the 2.2TB mark. If you wanted to rescue the upper 746.5GB partition,
you could find a way of moving it down, and storing the
entire partition, as a "file". The "file" can be mounted in
Linux, using a loopback mount. You need sufficient space to
do this.
Since my bottom 2.2TB partition is empty, I can easily store
a single 800GB image file in it. Then, I can do a file "copy and
paste", from that mounted image, and store the 800GB of loose
files in the 2.2TB partition.
This is how I developed my picture of how the partitions
are laid out, by the Acronis stuff.
1) Use Windows tools, to determine the sizes of things. There
are several potential sizing tools. Everest Home Edition,
PTEDIT32 (for viewing the first MBR), and the port of "dd".
This is the info I recorded in my crib notes. I gathered
this information, while the thing was still working. And I
did that, to help me decode and verify things. The first
row, is the size of the disk, while the second line
is the size of the file system. Converting the second
numbers to hexidecimal was crucial, for reading the second
MBR by hand. It turned out, the bytes were in reverse order,
in my hex viewer.
801,569,243,136 = 0x5D50A000
2199020350464 (63???) 801,568,194,560 (1meg???) = 0x5D509800
2) Boot Ubuntu. I keep a pendrive with a recent Ubuntu on it.
A version of Ubuntu without Unity on it. Just nice regular
menus for the programs.
The 3TB drive, ends up on my system as /dev/sdd. Linux
does not "see" the upper 746.5GB partition, because there
is no Acronis filter driver for it.
3) The hexdump program, allows me to read the disk sectors.
In these two example commands, I was looking for the two
MBR sectors on the disk. The number 0x20000000000 hex,
is the 2.2TB thing. The number 40000 hex, is the offset
from that boundary, until I found the MBR. When I view
these on my Linux screen, I can see the MBR boot message
text, which is identical (it would be the boot sector
code that Acronis put there). Since I don't boot from this
disk, there is no Windows boot code. The last bytes of an
MBR has 0xAA55 in it, which is an additional check you've
found the MBR. So, the first command, uses no offset, and
reads the physical MBR at sector 0 offset. The second
command, goes to "2.2TB + 262144 offset", where I found
the MBR. I had to search a tiny bit, to find it.
sudo hexdump -C -n 512 /dev/sdd <--- MBR
sudo hexdump -C -s 0x20000040000 -n 512 /dev/sdd <--- MBR
While looking at the short dump from the second command, I see:
200000401b0 00 00 00 00 00 00 00 00 d1 1e 03 02 00 00 80 20 |............... |
200000401c0 21 00 07 fe ff ff 00 08 00 00 00 98 50 5d 00 00 |!...........P]..|
Offset 0x1BE, is where the 16 bytes of the partition definition
are stored. And 0x1BE + C = 0x1CA, is where the size of the
partition is stored. That's the "00 98 50 5d" part. Now, if you
glance up the screen, you can see the value is actually
0x5D509800 bytes or 801,568,194,560 bytes. That's the amount
of information I must capture from the top end of the disk,
to store an image of the partition in the lower 2.2TB blank
space. By comparing the numbers I was expecting to see,
with what showed up in the hex editor, I was able to figure
out I needed to reverse the byte order. So I'm pretty sure
I got the whole partition.
The next step, is verifying I'm looking at the NTFS headers.
The letters NTFS, fortunately appear in each one. The commands
I used to look at them were.
sudo hexdump -C -s 32256 -n 512 /dev/sdd <--- first partition
sudo hexdump -C -s 0x20000140000 -n 512 /dev/sdd <--- second partition
The 32256 decimal number, is 63*512 bytes or 63 sectors. Since
Disk Management prepared that partition, the offset is 63
sectors.
The 0x140000 hex offset, is the Acronis partitioning, and
Acronis offset leaving room for their metadata. I presume
somewhere in that 0x40000 section, Acronis stores some
info for their filter driver. I did not verify that.
The additional 0x100000 is the 1megabyte offset that
Windows 7 likes.
So both of those hexdump screens, show me an NTFS header.
The info I have in hand now, is I know the offset where the
second NTFS partition starts, I also know its length. Now,
it's time to transfer the entire upper partition, as a file.
Steps to transfer.
Using the Linux "factor" program, figure out what
block size might be used.
factor 801568194560 ==> 2**20 5 7 21841
I decide to use 262144 as a block size, as the offset
is measured in blocks rather than bytes. And I need
to ensure I can skip to the right location to start the
transfer.
Length is 801568194560 / 262144 = 3057740 blocks.
Skip 0x20000140000 but in blocks. If I convert
that number to decimal, using the Linux "calculator",
then divide by 262144, I get a skip of 8388613 blocks.
In Windows, my 2.2TB partition was called "GUMBY", and
the 746.5GB partition was called "POKEY". We're storing
an image of POKEY, in the NTFS GUMBY file system. This
is the command that does the transfer, at 120MB/sec. It
took around two hours, to complete the imaging of the
upper partition.
bs=262144 The block size I chose for "dd" program
skip=8388613 Start transferring from 0x20000140000 byte.
Converted the number to "blocks"
count=3057740 801568194560 / 262144 = number of blocks
to transfer.
The "dd" command is piped to the GNU Linux "cp" or copy
program. The "/proc/self/fd/0" means the same thing as
"stdin" - it's a way to fool "cp" to use the byte stream
from the "dd" program, as the "input file". The "--sparse"
option, says "for every sector which is completely zeros,
don't store the result on disk". This is a way of
making a sparse file. Since the disk is new, and the partitions
are mostly full of zeros, this saves a *lot* of space, and
makes the transfer operation run 4X faster (as a lot less
writes are needed).
sudo dd if=/dev/sdd bs=262144 skip=8388613 count=3057740 | cp --sparse=always /proc/self/fd/0 /media/GUMBY/pokey.dd
The actual output file is /media/GUMBY/pokey.dd .
If I view that file in Windows at the moment, it reports:
http://imageshack.us/a/img818/7466/pokeysize.gif
Size: 746GB
Size on disk: 216MB
Since any zeroed portions of the partition are not written
out in this case, the operation used very little of the
lower 2.2TB partition. This only works, if you know the
partition is mostly zeroed.
http://en.wikipedia.org/wiki/Sparse_file
If you wanted no sparse file to be created, then the "dd"
command would have looked like this. I started doing this,
but stopped it after a couple hours, because it was just
taking too long. This would take exactly 746GB of storage
space, as no zeroed sectors are removed.
sudo dd if=/dev/sdd of=/media/GUMBY/pokey.dd bs=262144 skip=8388613 count=3057740
Now, in Linux, I make a mount point for my new bitmap image.
sudo mkdir /media/POKEY
sudo mount -t ntfs -o loop /media/GUMBY/pokey.dd /media/POKEY
Magically, the POKEY window opens, and I can do a copy and
paste file transfer, to start recovering the files from
POKEY partition. The 746GB file is now mounted as a file
system. I don't want to attempt to write to it, as
that would not be very efficient. But it's still
fully functional.
So that's how I can do data recovery, on an Acronis
setup, where the top partition is no longer visible.
This doesn't help you, because I suspect the end of your
1454GB partition, has had a few sectors snipped off the
end, by the NVidia RAID-ready MediaShield driver.
+------+-----+-----------------------+------------------------+--------+
| MBR | gap | 746GB NTFS partition | 1453GB NTFS partition |metadata|
+------+-----+-----------------------+------------------------+--------+
It's possible, that by switching over to Linux, the
1454GB would be visible there, and you could do
data recovery without any nonsense at all. That
would be something to investigate. Just boot
into Linux and have a look.
It's only if you want to do data recovery *above* 2.2TB,
that the "dd" command can oblige. Being a block level
command, it does not know or care about the 32 bit
limit on sector addresses. That's how I can roam above
2.2TB and grab a bitmap copy of the partition up
there.
And the above techniques can all be done on the same
disk, if there is space. If your disk was chock
full, this approach would be a non-starter. To do data
recover on a chock-full disk, you really need to buy
another disk.
HTH,
Paul