Did Paragon Restore EVER work with Vista???

I just tried the free version of Paragon BU/Rec 10.0 to clone my Win7 install. It's on a 100GB partition, but only uses about 7GB.

I have three physical drives, and I just use the BIOS to pick which one to boot from. So the source partition was on one drive, the target on a second, and I'm running Paragon from the third. So there should be no problems with locking or whatever.

The backup went like a dream --- took just three minutes.

Tried restoring a few individual folders, the data seemed fine.

Then I tried to clone it to another drive. The target partition was 50GB. Smaller than the source, but way bigger than the data. Paragon didn't complain, about that, but I had serious problems.

First, even though I am doing a restore at the partition level, it was writing the files to the new partition one by one, so what took three minutes to back up took over 20 minutes to write back. Finally the progress bar hit 100%, and I was anxious to see if it worked.... but it kept writing. It went on for another ten minutes, then a Win7 error box popped up and said Paragon ended with an error, and I had the option of closing it, or looking for a solution online. I closed it.

I've read that the Winsxs folder is really a maze of links and mount points that makes it look a lot bigger than it really is, and I suspect that Paragon couldn't figure it out, and was writing stuff in a loop. But I'm not going to try to verify that, because there is a bigger problem.

I looked at the target partition and it seemed to have everything else right, so I tried booting from it just to see what would happen. Wouldn't boot, got "NTLDR missing."

That is not a Win7 message. Win7 looks for bootmgr, not ntldr. I thought a while, and remembered that I had wiped the target partition before all this, and I left it unformatted, so Paragon had to format it. And apparently, it formatted it the way XP does, not the way Win7 does. I looked at my bootsector with a hex editor, and sure enough, it was an XP bootsector.

So I formatted the target partition again from within Win7. I looked at it with the hex editor, and it had all the right bootmgr code. I started the restore again -- and Paragon says it's formatting the partition. I cancelled the restore, looked at the sector, and Paragon had reformatted it back to XP, even though it was already formatted for Win7, and otherwise empty.

So, OBVIOUSLY, this is never going to work for Win7. If it just copied the partition back the way it was, it would be fine, but it's not doing that -- it's formatting the partition, then copying the files back one by one. It takes ten times as long, fails after all that time, and destroys any chance of booting with Win7.

But my question is, what has been happening for the last five years? I've never used Vista, but it uses the bootmgr code, too, so Paragon would have broken any Vista partition just like it did my Windows partition. And this is a 2010 product, so what is going on?

Did Paragon ever work with Vista? If it did, why doesn't the free 2010 version know about bootmgr? Is the free version something they wrote in 2001 and that's why they are giving it away?

 

Microsoft installs (at least XP and Vista) have one tricky habit.

When there is a phisical partition on the disk, it creates the new partition as a logical one. So when you make an image copy of this partition, it won't work correctly.

I more or less had a simular problem. I do not recal correctly, but I think I used partition magic, to changed the logical partition to a phisical (and reduced te size of it for faster backup/restore processing).

Next I backed up this phisical partition again and after restore to another disk, opened the Paragon MBR repair option of the emerging disk. I remember I had to look for an OS and rename the partition labels (I do not remember whether i used paragon or parition wizzard free).

Although not precise check whether your OS partitons are phisical or logical and look for clues as described above.

Regards Kees

 

Hello brocks,

I have restored Paragon Images of Vista and 7 numerous times - perfectly - never had an issue.

Typically it takes a bit longer to restore the image than to create it - longer still , if the target partition is smaller than the source.

I never had it take 7 times as long - nothing like.

Did you ask it to restore all the files - as opposed to restoring it as an image?

That may explain why it took a while.

I have no idea why you ended up with an nt52 bootsector - if the source partition you imaged had an nt60 bootsectr.

It has never happened to me.

 

Actually I used Paragon's free PM to make the partitions on the target, because Win7 wastes about a MB of space when it makes partitions, plus it only allows three primaries instead of four. The target was the first primary (I assume that you mean "primary" when you say physical) partition on the disk, and was set as active. I verified all this with a sector editor.

At any rate, this had nothing to do with the partition table; it was formatting an existing partition, but with the wrong formatting code. Thanks anyway.

 

Thanks for your reply. Good to know that it worked for you, but I have to assume you were using the retail product. Have you ever tried the free 2010 version?

As for files versus partitions, I actually did mistakenly check the wrong box to restore all the files instead of the whole partition the first time I tried to use it, and as a result, I was not allowed to pick a partition to restore to --- when you restore by files or folders, you can only target a folder. In other words, the software makes it impossible to make the mistake you mentioned (unless you are totally clueless), which I consider a good safety feature.

So yes, I was restoring the partition image, not individual files. And yet, it showed during the restore that it was going a file at a time, and it literally ran ten times as long as the backup took before it died.

On the bright side, it didn't trash my MBR like TI did, which is why I'm looking for a new product.

 

I just tried tried to recreate your experience.

1. I imaged an o/s partition with B&R 10 Free ( 16gb partition - containing fresh install of 7 x64. There was 7.09gb used space excluding pagefile and hiberfile).

2. It took 7 mins - slow because the partition I stored the image on didn't have much free space.

3. I recreated the target partition and formatted as ntfs using PM 2010 Free.

4. Restored the image with B&R 10 Free - it took 5.08 mins - perfect restore - it did say data writing - it never said it was writing files back one at a time.

I had attempted to reproduce what you did by expanding to show the folders - but of course made sure the image was selected ( highlighted )before clicking Next.







I remain mystified - as far as I know - B&R10 Free does not contain any mechanism ( such as bootsect.exe) for creating bootsector code - how you got nt 52 bootsector code on there is baffling.

Please let us know if you find out the cause - it is fascinating.

 

Thanks very much for your response. I've already uninstalled it, but if you'll tell me how you took the snapshots and got them into your post, I'll reinstall it and try to show you what is going on with my PC. I am tech oriented but have been using XP until a few days ago, so if there's a built-in screen grabber or whatever in Win7, don't assume I know about it.

I really would like this to work, as the only demo I've tried that worked well for me is for a product that costs $80, and that's pretty steep for something I hope to use no more than a couple of times a year.

I think you must be mistaken about the bootsector code. I don't see why it would do a format as part of the process (and it explicitly said it was formatting in the progress log) if it were restoring files rather than a partition, and I don't see how I could end up with an XP bootsector if it invoked Win7's format, rather than its own. But I will be very glad to learn that I'm doing something wrong, and that this will work for me.

 

There is one called the snipping tool - just type snipping in start search box and it pops up.

Click the drop down arrow next to NEW - select rectangular - drag the cursor round the region - save as jpeg.

To get them into the post , click Go advanced,in the new window, click the arrow next to the paperclip. In the new " manage attachments" window browse to the pic , click upload. then browse to the next pic , click upload, etc. close the attachments window.

Insert the pics in the post by clicking the arrow next to the paperclip again.

Yes, Paragon will create a partition and format to either ntfs , or fat 32 for example. That is the filesystem - the bootsector code is something else - it can only be created by a special tool such as bootsect, I don't think Paragon has that, so it just rewrites the sectors it imaged - they will therefore be identical to the source - if those sectors contained nt60 bootsector code - so will the restored partition.

You can check the bootsector code by using Disk Investigator ( great freebie). Select a partition - the first sector - you can see in the shot the BOOTMGR message - look at the second arrow - there is also an NTLDR message.

Vista/7 bootsector code ( nt60 ) tries to load bootmgr first - if there is no bootmgr - it looks for ntldr.



Hope it helps

 

Hey, I just had a thought (rare for me). As I said in an earlier post, I don't use Win7's DiskManagement to make my partitions, because it wastes space. I'm using PM10Free now, but before I was using it, I would use XP's DM (I have half a dozen drives lying around, and my PC allows me to hot swap SATA drives, so I can plug in an XP install and boot from that whenever I want.

XP not only uses a different boot sector than Win7, it also writes a different MBR when it initializes a drive. From a few experiments I did last week, it seems that Win7 runs fine on a drive with an XP MBR, and vice versa, unless you are using BitLocker or something like that, so I saw no reason not to use XP's MBR.

You can see at a glance which type of MBR you have with a sector editor --- when you look at the MBR, XP's code ends well short of the partition table, so there are some rows of zeroes before the PT. In Win7, the code goes right up to the Disk Signature.

Anyway, the target drive had an XP MBR. And although my source drive was a Win7 partition, it was not the system partition at the time I imaged it, so Paragon probably thought it was just data.

Could Paragon have been trying to "help" me by looking at the MBR on the target drive, seeing it was from XP, and therefore formatting the partition with XP code?

I'll reinstall it, and rewrite the MBR of the target drive, and see what happens.

 

SIW2, thanks for the info - I will try to reinstall and do some test runs tomorrow. Also, in light of my last post above, can you tell me whether the image you took was of the current system drive, i.e. were you imaging the partition that you booted from? I'm thinking that since the image I took was of an install on a different physical drive than the one I booted from, that might explain the different results we got. Paragon might have different ways to handle system partitions than data partitions.

I just assumed I would get better results by NOT imaging the system while it was running, since it would have all kinds of locks on files.

 

No, I imaged another partition - it does contain an o/s , but is not the system partition - or the partition I was booted into at the time.

You're right about the XP mbr - any properly written mbr code ( ms seems to call it "disk code " now) should be capable of handing control to any o/s bootsector code.

If you aren't wanting all that TPM checking stuff - XP mbr should do just fine.

Here's a copy of 7 bootsect.exe ( rename to remove the .txt extension - it is a .zip ) rt click the .zip>Properties>Unblock>Apply>OK.

View attachment bootsect7600.zip.txt

Unzip it and pop the file in Windows\System 32. Open an elevated command , type : bootsect /help .You can write nt52 or nt60 bootsector and mbr ( disk code ) to any partition/drive.

If you are new to 7 - there is another command line app. bcdboot.exe. It should be in 7 System32 already - check it out.

bootsect and bcdboot work fine in Vista , too - just copy them into Vista system 32 ( actually they run from just about any location in vista/7 )

 

Well, I have never been so happy to be wrong.

I reinstalled BR10Free, and ran a new backup on the partition with a fresh Win7 install. 129GB total, 7GB data. Again, it took about 3 minutes.

This time I made sure that the target partition's drive had a Win7 MBR, and that the partition was larger than the source. I ran the restore, and it took a bit over two minutes. I didn't see any individual files, just the "writing" message.

I changed the Disk Signature to match the source drive (I use HxD, another great freeware product. It doesn't have much automation, but it does allow you to read and write to any part of a drive or memory, including the MBR), and set my BIOS to boot from the restored image. Instead of booting right up, I got a "windows loading files" message, and then some lines about windows attempting to repair the install. It did something for about a minute, then restarted itself, and it came right up!

So, cool. I figured the reason it worked this time was because of the changes I made from before (Win7 MBR and larger partition), so now I wanted to find out exactly why it didn't work before.

First I used HxD to copy an XP MBR onto the target drive. I booted from it again to make sure it worked, and again it came right up. I should mention that every time I booted windows from an image, the first thing I did was start up Disk Management to verify that the restored drive was the System, boot, page file, crash dump, active, primary, yada yada yada. It always was.

So I reformatted the target partition and ran the restore job again. Again, it took two minutes, and this time, it came right up without fixing itself. That didn't make sense, but I'm not complaining.

Next thing was to try a smaller partition. I deleted the target partition and created a 50GB partition in its place (using PM10Free). So it was less than half the size of the source (129GB), which is a really severe test, since Windows likes to put its mft in the middle of the partition.

I ran the restore job, and this time it went apesheet, spitting out a list of files it was skipping or replacing. I cancelled the job, and figured I had found the culprit.

EXCEPT, when it didn't work before, it was going through individual files, but they were on the same line, i.e. the text would change, but stay in the same place. This time, it was different - it wrote a new line for every file.

I tried to go back to look at the log, but I couldn't find it. The log page is not very intuitive. I figured I must have done something to accidentally delete the log, so I thought I'd run it again, and this time take a snapshot of the screen in case I still couldn't figure out how to save the log.

This time the restore ran normally, except that after it was done writing the data, it put out some messages that it had to fix the files. It spent another 3 or 4 minutes doing that, and announced it was done.

I booted from the restored image, and this time Windows said it recommended I let it run a chkdsk. I did, and it took a couple minutes to decide there were no errors, restarted, and Windows came right up again.

So I had tried everything to make it fail, and aside from one restore job that went nuts, it worked every time, and I never did get anything resembling what I saw that inspired me to make my original post in this thread. I had to reluctantly admit that I must have made a mistake in the BACKUP job by copying the root folder, rather than the partition, to get my earlier results. So I decided to do that again and verify that that was my problem.

And found that it was impossible. BR10Free doesn't allow you to back up individual files. The only choices are the whole disk, one or more partitions. And I definitely did not back up the whole disk, or more than one partition.

Bottom line, I cannot recreate the problem, I have no idea what went wrong the first time, and I have no idea what went wrong on that one restore job today. I can only conclude that I lost a bit or two when I downloaded the program. There is no MD5 hash on the download page, so if anyone can post what they get for an MD5 on the file (br_free_x64.msi), I would appreciate it.

SIW2, I can't thank you enough for taking the time to try out the free version, and post that it worked for you, which made me try it again. I was about ready to spend $80 on a product that would have been much less easy for me to use, because it can't restore to a smaller partition than the target, and my boot partitions are not all the same size. Now I have a free product that does exactly what I want (I have another free solution I like for file and folder backup). Hopefully a new download and install will end the occasional problems, but even if it doesn't, it's not a big deal to have to run a restore twice, when it takes less than five minutes.

Thanks again, and I hope this little essay helps somebody else.

 

Hi Brock,

I think what went on there is 7 relies on the Disk sig and partition id as part of the bcd entry.

When you restore the Paragon image, it automatically corrects for the partition id and disk sig at the moment the restore is done.

If you then change the Disk sig - the bcd entry will then be wrong. Startup repair fixes it.

Also, if 7 see two HD's with the same Disk sig - it changes the second one - again with consequences requiring startup repair to correct bcd.

If you restore Paragon to HD as is ( without changing the Disk Sig ) - it won't need startup repair.

Glad it is all working well for you, and thanks for the update.

 

This just keeps getting better and better.

The Disk Signature was the next thing I intended to test, and I just verified that you are correct; Paragon fixes it for you, so there is no need to do it myself, and in fact doing it myself causes problems. The reason I did it just by habit is that years ago, when I started cloning XP with TI, it caused all kinds of problems if the disk sig wasn't right. It's been a while, but I remember things like the system and boot partitions being on different drives, or the Windows drive being D: instead of C:. Manually changing the disk sig prevented those problems for me.

When I started fooling around with Win7 a couple weeks ago, the first time I tried cloning a drive, I got a "winload.exe missing" message, and the drive wouldn't boot. No attempt at repair; it just said to hit Ctl-Alt-Del. I changed the disk sig, and it booted after repairing itself. Googling around confirmed that a bad disk sig produces this very misleading message.

Since I didn't get that when I "fixed" my disk sig after a Paragon restore, I guess that whatever Paragon does with the boot files makes Win7 happy enough with the disk that it can repair it the rest of the way.

That is also probably why you said that is normal behavior for Windows -- because you use Paragon. But from my experience, the normal behavior for windows when you are not dealing with a Paragon-fixed disk, and you boot with two drives with the same disk sig (assuming you can boot at all), is to just keep one of them offline. If you mouse over it in Disk Manager, it says it is offline because of a disk sig collision.

Anyway, I changed the disk sig to a random string and reran the restore, and sure enough, it booted right up. That is great news for me, because not only will it save me a few minutes, but it will allow me to make my disk sigs permanent. When I get a new drive, I always start out by changing the disk sig to something I can recognize when I look at the MBR (e.g., my initials plus the drive size in GB plus a sequence number if it's the same size as another drive), but after cloning back and forth, they get mixed up. Now I can make them permanent.

Note that Windows DM changes the disk sig when you create partitions, which is another reason I don't use it for that. However, one thing it is good for is reordering the partition table. When you use Paragon's PM to create partitions, the partition table lists them in the order created, rather than the order on the disk. So if you have a new drive and create 3 partitions on it, they are in the partition table as 1 ,2, 3. But now if you delete the first one and then recreate it, they are in the partition table as 2, 3, 1. It doesn't matter to the PC, but it's a bit confusing if you are looking at the hex. But if you use Win7's DM to set partition 1 active, it reorders the table while it does it, so they are 1, 2, 3 again.

One other little glitch --- when it is doing the restore and fixing the boot files, it writes a message saying it is scanning all the drives for Windows installations. Apparently it tries to keep your current boot drive the primary, because the first time I booted after telling the BIOS to boot from the restored drive, it booted from the drive that was system when I ran the restore, rather than the restored drive. I reran the restore, and this time I disconnected the old boot drive before booting from the restored drive, and it worked. And after you've booted from it once, you can reconnect the other drives and it's fine.

One suggestion for Paragon, if anybody from there is reading this --- if you have big drives and a relatively small boot partition, you cant see anything useful about it when you are picking the target partition, so it would be easy to make a mistake. Here's what I saw:



If this worked, you can see that the first partitions on my drives, even though they are over 100GB, are not given enough space in the disk map to show the drive letter, or any other useful details. And since I have two drives of the same model, even that doesn't help. I have to use the size of the other partitions to make sure I'm targeting the right drive. Most people would not find the drive numbers helpful, and some utilities, including the tool I use to view and edit my MBRs (HxD), number the drives from 1 instead of from 0, so this could be a disaster waiting to happen. If you just had the drive letter pop up when you mouse over the partition, it would help tremendously.

If you're wondering what the big raw partitions are, they are actually data partitions encrypted with TrueCrypt. And it occurs to me that they might have contributed to my original problem. When TrueCrypt drives are mounted, many programs that show drives at a basic level, including Paragon's PM and BR, and including Windows Disk Manager, take forever to show the drives, instead of just a few seconds. Possible I had a drive mounted when I ran it the first time, and it screwed it up.

So that's my story. I'm now kicking myself for not trying this sooner, because Paragon was running a deal at Christmas to get the retail disk suite for $25, and I would be all over that now. But their free stuff is working so well for me now, that I can wait till next Christmas.

Thanks again for the help.