HDM 12 Suite

I am in negotiations process with the development team and depending on the resources required for this feature implementation it could be done in next update or in next major release. Still there are voices for leaving the exclude masks of Microsoft as they are. Because this really makes the image smaller, especially when these two keys in registry refer to MS snapshots that could be 1-2GB in size.

 

John, it is my mistake. Continues talks with developers shed some light on the way it is implemented. The files from FilesNotToBackup list will be ignored during backup with VSS in any case. It is hardcoded and the given flag in Layout.ini does not affect it. So please ignore my original post. I don't know if I will be able to push this implementation but I am trying to do that at the moment.

 

It seems to me you are saying that the boot menu should stay the same as it was before the backup. This is exactly what I want. I want that when I restore the image, it should restore the same boot menu that was there at the time of image creation.

Unfortunately, HDM 12 does not do that, when backup is created from within windows with VSS, upon restore, it overwrites the boot menu with the default windows 7 boot menu.

 

I do not know which files take up 1-2 GBs, but the files I am referring to under the FilesNotToSnapshot category are the *.ost files that hold hotmail emails in oultook and they are about 50 MB for each hotmail account. The *.obi file size is in KBs and the windows log file size is also in KB.

The above mentioned are the files that are useful, if there are files that are 1-2 GB in size and are not useful, then they can be safely excluded.

If other vendors have made a determination which files are useful among these files, and they only backup the useful files, then I think Paragon should be able to do something similar.

 

I cannot speak for others but I just checked and Macrium uses "Microsoft Software Shadow Copy provider 1.0". They appear to have found a way to not exclude these files from the backup, and Macrium's backup image size is comparable to Paragon's.

 

Interesting. I just made backup of system partition of XP machine and restored it back. The backup was taken in Windows using VSS and restored with restart in startup mode. The boot menu did not change and MBR comparison showed no difference.
Could you please shed some light on the way you find this difference out? Where and how do you notice the difference in Boot Menu?
Thanks in advance.

 

For sure, there is always a way out. And I think we can do the same. All depends on the management, if they consider it to be worth of implementing. As said earlier I am in contact with dev team and the issue along with product improvement requirement has been already reported.
We will see what we can do with it.

 

Thanks for looking into it.

 

Please, test it on a Windows 7 machine with a custom boot menu. I have a modified boot menu which gives me a choice to boot into either Windows or my recovery environment. See the image#2 in this tutorial for what I am talking about. When I restore with Paragon, the boot menu is gone and is replaced with a standard Windows 7 boot menu.

 

Explain to them that other imaging utilities backup the important files from these categories, so Paragon should do something similar. Let the Dev team test Macrium and Shadowprotect and see what they are doing in regards to these particular categories. Because otherwise, the restore is not an "exact back-in-time restore" as Paragon claims in its features.

 

Now I got it. Try to backup MBR standalone when you backup the partition. Then after you restore the partition backup perform restore of MBR (it is few KB in size). The boot menu will be restored. The problem is that we update the records of partitions in MBR and this causes rolling the MBR to standard MS status. There are thousands possible customizations of MBR so using Microsoft standard (clean) MBR after update was the solution. The requirement to let user select what to do with MBR is set to development team already.
So the workaround is taking separate backup of MBR.

 

Actually Exact backup-restore can be achieved with Sector per sector backup or backup from WinPE/Linux CD. But yes, I explained the issue so they have enough info. Thank you.

 

Interesting discussion. I suppose everybody likes "options", but I would respectfully suggest that, if your developers do decide to allow fiddling with the operating system's own parameters, the change process be made transparent to the end user and capable of being fully restored to the defaults.

 

Indeed interesting and I am perhaps a little bit more to the middle of the road regarding the points being made. I totally agree that changes should be transparent, ie, tell the users more about backup omissions such as the update history and the fact that a regular image does not mean "totally identical" and the reason(s) why.

On the other side of the coin, I noticed after doing a restore on a PC because of a new program having trouble, that Windows said the PC had never been updated which obviously was wrong. However, Windows Update knew that a wholesale updating was not required and if MS VSS default doesn't think this is a big deal, should I? How many images were restored with this problem that nobody even noticed and all was well in practical terms? Yes, there is certainly something to be said for getting it as right as possible especially when the user tends to expect it from this type of program.

Regarding the custom MBR issue, I always thought that was why we could put tick marks against the MBR Track 0 boxes when making an image. Even though my MBR is probably plain vanilla I always back it up just because it is small, easy to do and is there if I should need it.

I've been imaging long enough to know that the disk after a restored image is not likely a clone (in the real sense of the word) of the source disk. Paragon isn't the only imaging program that moves and adjusts things and it may be arguable that any image is never an image because as soon as you restore it and boot Windows things are not guaranteed to be "the image" anymore and the contents of the disk probably changed during the live-imaging process as well. If I was doing serious disk trouble-shooting or forensics then a complete sector copy of the partition on a static disk would be done not a regular image.

I totally agree with the call to Paragon to improve the situation; it should be done. I'm just saying the omissions caused by the VSS implementation are trivial when it comes to restoring an operational system.

 

I noticed that the WU was cleared on a restore but it doesn't cause any problems for me. I had problems with the W7 SP1 install, so for about a week or so, flip back/forth working on the SP1 install then create a new image at the end of a session and restore my straight W7. I did this 4 or 5 times.

 

Sorry was a little busy. Thank you for the clarification. Backing up the mbr separately is an option, but it would be better if Paragon restores the mbr that was present at the time of backup creation.

I did not have time earlier, but later this week I will check if the boot menu is overwritten only during the VSS backup creation or it is overwritten during the PHP backup creation as well.

 

Yes, a restored image is not totally identical but still it should have all the relevant logs, previously downloaded email etc.

So, now we have confirmed that only these trivial files were been excluded, so it is okay. This is all I wanted to know 3 years ago. I think it is high time Paragon should start taking the problems presented here on their official forums seriously. It appears they only take you seriously if you open a support ticket.

 

If given no choice during the image/restore process I would tend to agree. But I'd want the option, and would prefer it as-is as opposed to always writing the original MBR. Perhaps a nice little warning would be helpful for people who expect the MBR to be backed up with the system would be helpful though.

 

Having the MBR restored with every restore could seriously limit the program's flexibility in cases where the backed up MBR is not the one wanted for some reason such as restoring a second image to a dual-boot system or the MBR contains undesired code inserted by an application.

The Acronis way is good, the MBR is always imaged (at least if the active partition is imaged, maybe others too) but the restore is done only when the user specifies it.

 

I was referring to the default behavior. A better option would be if they can give this as a choice for the end user.

 

@Paragon MA

One last thing. Why does the backup job run with realtime priority when PHP is used as the hot processing technology? Is it a bug? Could the job be forced to normal priority? I have tried all external priority savers but they do not work with this particular problem.

 

Hello Raza0007,

this is known issue and frankly speaking PHP is going to be closed as a project. We are going to leave VSS as the only hot processing option.