I made an image of my data partition on an external disk.

Immediately afterwards, I restored it to another partition, on another physical, internal disk, with a different drive letter.

The source data partition, the one I took an image from, shows as 257 GB of used space, under Windows Explorer Properties.

But the restored data partition only shows as 152 GB of used space.

However, when I display the top folders of both partitions side by side, all folders are there and all of them have the same size.

When I scan both partitions with Space Sniffer, they seem more or less similar, although there is a 0.1 GB difference between them.

Is all the data here ? Does Windows detect phantom data ?

And another problem, or possibly related fact.

On the target physical disk I used for restoration, I created a 6 GB, unallocated partition at the beginning. This was to neutralize some weak/bad sectors. The restored partition was immediately afterwards.

Seemingly as a result, Macrium would not let me select Windows 7 as an alignment for the restored partition. If I tried to, the unallocated partition disappeared from the map.

So I accepted the default setting for alignment, which says Windows XP, and seems inappropriate to me. Also, why is this the default, despite the fact I have a Windows 7 PC ?

Thank you for your detailed answer.

Point 1

So it's expected behaviour that a restore operation omits System Restore points and the Windows Search index database, because those can be recreated later, is that right ?

Would you know some program which would enable me to make a comparison, and see which files were omitted ?

Point 2

I'm not familiar with those notions. I checked with two partition programs, and both source and target partitions show the following information :

Bytes per sector : 512
Sectors per cluster : 8 (4096 bytes)
Sectors per file record : 2 (1024 bytes)
Sectors per index block : 8 (4096 bytes)

I'm not sure that's the information you need.

How can I restore Windows 7 alignment, and indeed, how can I check what the alignment is ?

Is it a problem to have an unallocated partition at the start of the disk ? Macrium seemed not to like it.

I can never seem to remember what it's called, but JP recommends a little utility where you can compare drives for what has changed.  You could mount the backup image file you restored as a virtual drive and compare its contents to the original drive, assuming it's still available.

+x

 

Clairvaux - 29 September 2020 10:45 PM

Thank you for your detailed answer.

Point 1

So it's expected behaviour that a restore operation omits System Restore points and the Windows Search index database, because those can be recreated later, is that right ?

Would you know some program which would enable me to make a comparison, and see which files were omitted ?

Point 2

I'm not familiar with those notions. I checked with two partition programs, and both source and target partitions show the following information :

Bytes per sector : 512
Sectors per cluster : 8 (4096 bytes)
Sectors per file record : 2 (1024 bytes)
Sectors per index block : 8 (4096 bytes)

I'm not sure that's the information you need.

How can I restore Windows 7 alignment, and indeed, how can I check what the alignment is ?

Is it a problem to have an unallocated partition at the start of the disk ? Macrium seemed not to like it.

The omissions are the result of the VSS snapshot not containing those items in the first place when the backup was captured, not anything particular to the restore operation or Reflect in general.  VSS is a Windows component, and applications can have "VSS writers", which are components that are designed to take certain actions with data on disk when they are notified that a VSS snapshot has been requested.  Those actions can include flushing data from memory to disk, ensuring data on disk is in a consistent state, or deleting data from the snapshot.  But yes, by default those items are excluded from VSS snapshots and therefore would not be present after restoring one of those backups.  Note that backups captured from the Rescue environment do not use VSS since VSS isn't needed in a context where the source disk is offline, and therefore those backups WOULD contain those items, and therefore a restore of that type of backup would still include that data.

I use WinMerge to compare contents.  Enable Tree View, and then for something like this you'd probably just want to use a "Size and Date Modified" compare, since a "Full Contents" compare that involves hashing every file would take a whole lot longer when comparing a large volume of data.  When you're in Tree View, you can then choose to show or hide certain categories, such as files that are the same, different, or unique to one side or the other.  Run it as Administrator if you want to compare the contents of a Windows OS partition, although even that might not give you visibility into the System Volume Information folder.

To check the physical sector layout, run the command, substituting the drive letter of any volume residing on the disk you want to check.  You want to check the "Bytes Per Physical Sector" field, not Bytes Per Sector or Bytes Per Cluster.



To check alignment, open Reflect and in the "Create a backup tab", click once on a partition you want to check.  Along the left edge, look at the Start Sector number.  If that number is evenly divisible by 8 -- meaning you get a whole number rather than a number with a decimal value after it -- then it uses Windows 7 alignment (since a disk that uses 4K sectors but emulates 512-byte sectors for compatibility has 8 logical sectors per physical sector).  If not, then it's using some other alignment.  In terms of fixing it, you'd either need to restore the partition again, specifying a new alignment, which would of course erase the current contents, or use a realignment utility, which can take quite a while to run.  The latter were launched alongside so-called "Advanced Format' drives that were designed in the way I described, because Windows XP defaulted to a sector layout that was not optimal for such drives.  The utility shifts the full contents of the partition(s) slightly so that no logical sectors have data that crosses physical sector boundaries, but again it can take a while.

There is absolutely nothing wrong with having unallocated space at the beginning of a disk, although I'm not sure what you mean that Reflect didn't like it, or why you wanted it in the first place.  You could always create a "placeholder" partition of the appropriate size there.

+x

 

jphughan - 29 September 2020 11:14 PM

+x

 

Clairvaux - 29 September 2020 10:45 PM

Thank you for your detailed answer.

Point 1

So it's expected behaviour that a restore operation omits System Restore points and the Windows Search index database, because those can be recreated later, is that right ?

Would you know some program which would enable me to make a comparison, and see which files were omitted ?

Point 2

I'm not familiar with those notions. I checked with two partition programs, and both source and target partitions show the following information :

Bytes per sector : 512
Sectors per cluster : 8 (4096 bytes)
Sectors per file record : 2 (1024 bytes)
Sectors per index block : 8 (4096 bytes)

I'm not sure that's the information you need.

How can I restore Windows 7 alignment, and indeed, how can I check what the alignment is ?

Is it a problem to have an unallocated partition at the start of the disk ? Macrium seemed not to like it.

The omissions are the result of the VSS snapshot not containing those items in the first place when the backup was captured, not anything particular to the restore operation or Reflect in general.  VSS is a Windows component, and applications can have "VSS writers", which are components that are designed to take certain actions with data on disk when they are notified that a VSS snapshot has been requested.  Those actions can include flushing data from memory to disk, ensuring data on disk is in a consistent state, or deleting data from the snapshot.  But yes, by default those items are excluded from VSS snapshots and therefore would not be present after restoring one of those backups.  Note that backups captured from the Rescue environment do not use VSS since VSS isn't needed in a context where the source disk is offline, and therefore those backups WOULD contain those items, and therefore a restore of that type of backup would still include that data.

I use WinMerge to compare contents.  Enable Tree View, and then for something like this you'd probably just want to use a "Size and Date Modified" compare, since a "Full Contents" compare that involves hashing every file would take a whole lot longer when comparing a large volume of data.  When you're in Tree View, you can then choose to show or hide certain categories, such as files that are the same, different, or unique to one side or the other.  Run it as Administrator if you want to compare the contents of a Windows OS partition, although even that might not give you visibility into the System Volume Information folder.

To check the physical sector layout, run the command, substituting the drive letter of any volume residing on the disk you want to check.  You want to check the "Bytes Per Physical Sector" field, not Bytes Per Sector or Bytes Per Cluster.

fsutil fsinfo ntfsinfo c:

To check alignment, open Reflect and in the "Create a backup tab", click once on a partition you want to check.  Along the left edge, look at the Start Sector number.  If that number is evenly divisible by 8 -- meaning you get a whole number rather than a number with a decimal value after it -- then it uses Windows 7 alignment (since a disk that uses 4K sectors but emulates 512-byte sectors for compatibility has 8 logical sectors per physical sector).  If not, then it's using some other alignment.  In terms of fixing it, you'd either need to restore the partition again, specifying a new alignment, which would of course erase the current contents, or use a realignment utility, which can take quite a while to run.  The latter were launched alongside so-called "Advanced Format' drives that were designed in the way I described, because Windows XP defaulted to a sector layout that was not optimal for such drives.  The utility shifts the full contents of the partition(s) slightly so that no logical sectors have data that crosses physical sector boundaries, but again it can take a while.

There is absolutely nothing wrong with having unallocated space at the beginning of a disk, although I'm not sure what you mean that Reflect didn't like it, or why you wanted it in the first place.  You could always create a "placeholder" partition of the appropriate size there.

Thank you for this very useful information. Reporting on measurements :

Bytes Per Physical Sector = 512 for both partitions (so, what is the conclusion, here ?).

Start Sector number : divisible by 8 for the original partition, not divisible by 8 for the restored partition.

This confirms that the restored partition received the XP alignment.

So I made a new restore, and this time, I was able to set the Windows 7 alignment.

The things I did differently are :

I formatted the small unallocated partition at the beginning of the target disk. It now has a drive letter.

I deleted the existing partition on the target disk, before dragging the saved partition between partition n°1 and partition n°3.

The first time, I dragged the saved partition over the existing one, thinking that it would be overwritten.

Since I got no error message, I assumed this was the natural thing to do.

It's at that point that I was offered only two options : either do this, and accept the XP alignment, or force the Windows 7 alignment, and see partition n°1 (unallocated) disappear.

Looking back, I realize how confusing and unconventional Macrium's interface is. There are actionable elements all over the place, and you never know which one to use.

I image everyday, but I very rarely restore.

The reason I made the 6 GB dummy partition at the beginning of the disk, is to prevent access to a recurring bad sector.

I assumed (maybe wrongly) that this was the reason why Macrium would regularly fail while doing full images, while incrementals would still be (usually) possible.

If you use the drag and drop method to drag a partition out of the Source section on top of an existing partition in the Destination section, then you are essentially saying, "Overwrite the contents of the Destination partition with the contents of this Source partition."  In that case, the partition itself stays, in terms of both size and "offset" (position on disk).  So if you want to restore a partition to a new position on disk, you should not drag it onto an existing partition.  But by choosing to delete the existing partition and dragging the Source partition into now-unallocated space, you can "stage" a restore that will not maintain aspects of the existing partition on the destination.

But if your disk is reporting 512 bytes per physical sector, then the alignment doesn't make a difference from a performance standpoint because each 4K file system cluster will always occupy 8x 512-byte physical sectors.  The reason alignment matters for disks with 4K physical sectors is because you want a 4K file system cluster to exist purely within a 4K physical sector, so that you only need to ask the drive to read (or write) one sector in order to access or modify the contents of a file system cluster.  On a disk that isn't properly aligned, a 4K file system cluster might exist as 3K worth of one physical sector and 1K worth of the next physical sector.  In that case, the OS has to issue read or write commands for two sectors every time it wants to read or write a single file system cluster.