19 replies to this topic

[sebus]

It is to carry on from this thread (which had the question answered)

 

Does anybody has any definitive knowledge of WHAT Volume Shadow Copy service "uses" to identify the disk that Shadow Copies exist for?

 

As proven one can now easily change with Clonedisk 2.3.7 DiskID & PartitionID making source disk/volume & destination disk/volume almost an identical clone

(that is NOT disk to disk process, which DOES work as expected, but requires volume to be taken offline, not ideal!)

 

Ofcourse MS approach is that it can not be done. I would love to prove them wrong.

 

I am sure there is somebody around that understands what "ingredients" are required for Shadow Copies to know if they belong to the connected disk

[erwan.l]

on a windows 7, running in vmware workstation, i was able to :

 

-"hot" add a new "physical" disk

-clone source volume to destination volume (on disk added in previous step)

-"hot" remove original disk

-change disk signature (mbr disk) onto new disk

-perform a disk offline/online to redect my volume

-at this stage, volume guid (and drive letter) was identical to original volume

-at this stage, i could see my volume shadows in shadowexplorer and in vssadmin list shadows but not in explorer.exe

-rebooted

-at this stage, i could see my volume shadows in explorer.exe attached to my new cloned volume/drive

 

some remarks :

-this is a windows client not a windows server (which may be tougher)

-this is mbr not gpt (which requires, as far as we know an extra step i.e the partitionid to be modified)

-rebooting is not ideal : it could be that my new disk needed to get back to the original disk slot or that a restart of service was needed

-i would need to reproduce this experiment a few times to ensure this consistent in this environement

[sebus]

VM Server 2012 R2 - running on Hyper-V 2019, vhdx source, vhds destination

As soon as source is removed from system when volume-to-volume finishes, all shadows that existed "disappear" (even the destination seems to be identical to source - same DiskID, PartitionID, size of disk & partition)

 

When source is hot plugged back, all shadows "come back"

 

Tested whole copy process 3 times (each time with completely re-created destination vhds disk in case)

[erwan.l]

i will try to download a windows 2012 r2 iso over the week end to test it there.

 

what do you get with vssadmin list shadows and shadowexplorer?

[sebus]

I get exactly the same, nothing

[erwan.l]

I installed a windows 2012 r2 in vmware workstation.

I attached a vmdk coming from my previous windows 7 installation and all shadow copies were there

Shadow copies are stored locally to this data drive so I guess it is an easy one.

 

 I will now wipe the entire data disk, recreate disk/partition, hence coming with a new volume guid and starting fresh.

I will generate a volume shadow.

Clone the volume to a new disk and see how it goes.

[erwan.l]

ok so on a fresh windows 2012 r2 standard in vmware workstation 11 and performing all disk/partition steps with clonedisk.

 

-disk #0 is the system disk

-"hot" add data disk #1 (mbr)

-create disk/partition (mbr), format (ntfs)

-assert that there are no volume shadows in explorer.exe (obviously) on E:

-create a volume shadow

-assert that this volume shadow appears in explorer.exe

-we are good to really start our test here

-"hot" add new second data disk #2

-create disk/partition (mbr), format (ntfs)

-volume (on disk #1) to volume (on disk #2) clone

-"hot" remove first data disk #1

-change disk signature on second disk to match original/first disk

-"hot" remove second data disk #2

-"hot" add second data disk (to redetect volume) - new disk also now occupies the same disk slot as original (i.e #1) and drive letter (E:)

-check volume guid (should be matching  original/first volume)

-assert that this volume shadow appears in explorer.exe

 

success !

 

vssadmin list shadows before/after

 

[sebus]

All my shadows point to a separate dedicated drive (not stored on drive that is shadowed)

 

I have done the same testing at least 6 times now, shadows disappear as soon as source disk is removed

 

My test involes volume-to-volume copy of 33.5Gb of data, and all that is done on GPT disk

[Wonko the Sane]

All my shadows point to a separate dedicated drive (not stored on drive that is shadowed)

 

I have done the same testing at least 6 times now, shadows disappear as soon as source disk is removed

That sounds like there is some sort of "watcher" service.

 

Let me get this clear, set aside the "cloning" part.

You have disk connected.

You have the shadow copy made.

You remove/disconnect the disk.

The shadow copy vanishes?

If you reconnect the same disk it remains missing or re-appears from nowhere?

 

Wonko

[sebus]

How many times do I need to state it?

 

Shadow copies are directed in settings to a separate dedicated DIFFERENT disk

 

DiskA = source

 

DiskB = destination

 

DiskX = storage of Shadow Copies

 

D2D DiskA -->DiskB = all good (disconnect DiskA, mount DiskB, all shadow copies on DiskX are fine)

V2V clone, DiskID/PartitionID change, disconnect diskA, leave only diskB = ALL Shadow Copies are gone (like in NOT visible or accessible on DiskX, but if I reconnect original diskA then yes, all shadow copies are visible/accesible again)

 

sebus

 

Now it only matters as "Nice to know", because in real life I did lose all the shadow copies while doing transition from Shared VHDX to VHDSet on Hyper-V 2016 (which is by MS design anyway, because the design is total ***)

[erwan.l]

I will test this week end with shadow volumes on a dedicated drive.

[Wonko the Sane]

How many times do I need to state it?

As many times as needed for the people trying and helping you  to understand the details.

 

 

 

... but if I reconnect original diskA then yes, all shadow copies are visible/accesible again)

 

So, the shadow copies do not vanish/are gone they become *somehow* hidden or however not anymore visible or "connected" to the volumes.

 

This could be something *external* to the actual "normal disk operation".

 

In a REAL (or forensic sound) disk clone - by definition - every single sector and byte of the source is identical on the target, or if you prefer, the source and target after cloning are indistinguishable at byte level.

 

There could well be a field *somewhere else* (outside the actual volumes) that represents a "specific for shadow volumes only" kind of ID/Signature.

 

The test I would make (with a small disk of course) would be that of making a full hex compare (or "diff") between:
1) the original
2) the D2D clone
3) the V2V "semi-clone" with the Disk and partition ID corrected by clonedisk

 

1 vs. 2 should show NO differences wnatsoever.

1 vs. 3 (or 2 vs. 3) might show something different

 

Wonko

[sebus]

In 3 above, when doing V2V the source & destination will be completely different.

 

Shadow Copies are block differential backup copy, so most likely that is why.

 

That looks interesting - Forensic Explorer

[Wonko the Sane]

In 3 above, when doing V2V the source & destination will be completely different.

 

Shadow Copies are block differential backup copy, so most likely that is why.

 

That looks interesting - Forensic Explorer

Wait a minute.

 

V2V can be made in four ways:

1) Forensic sound copy (just like the "real clone" in D2D, an exact byte level copy of the extents from the very first byte/sector to the very last byte sector)

2) filesystem based copy (not really V2V, more like copy and paste)

3) midways, skipping BOTH unindexed files in the filesystem and sectors that are all zeroes
4) midways, skipping only zeroed sectors (this may be actually a Forensic sound copy as well, since the target is normally in good practice all zeroes anyway)

 

If you do #1 or #4 the result (target) is identical to the source.

If you do #2 or #3 the result (target) is NOT identical to the source, this may be the case at hand.

 

BUT I am not too convinced.

 

Let's say (another thought experiment) that you have a Disk with a single volume on it.

You have your nice Shadow copy of it.

Then you physically detach the disk, mount it on another machine, delete a number of files and run a defrag on the volume.

 

What happens when you reconnect the disk to the original PC?

It is clear that at block level the volume inside the disk is different, but the shadow copy should still be visible/valid/etc. 

 

   

Wonko

[erwan.l]

Stating the obvious (or already known) but just to be sure : CloneDisk does a byte to byte copy independently of the user selecting a disk or a volume, i.e it copies first byte to last byte of the selected item.

 

The only difference (stating the obvious again) between a disk and a volume (from a imaging perspective) will be that the volume image will not include the disk "header".

"Header" being a generic (possibly incorrect) word for bytes between offset 0 and starting offset (minus 1) of the first partition.

 

What would be interesting would be to compare original disk versus new disk where a volume has been cloned and where disk signature and partition id has been updated.

The difference should be minimal.

Worse case scenario, only the bytes between sector 0 and partition 1 starting offset should be different.

Best case scenario : no byte should be different.

[erwan.l]

ok... about to redo the experiment this time following Sebus environement :

 

-windows 2012 r2

-all gpt

-shadow volumes kept on a dedicated drive (F: - "VSC" drive).

 

E: "DATA1" is my "original" data drive.

About to clone it onto G: "DATA2", disconnect DATA1, "update" DATA2 header.

 

[erwan.l]

Similar to post #7 but this time using GPT disks and storing my volume shadow copies on a distinc/dedicated drive :

 

Cloning volume onto another volume, disconnecting "original" disk, updating "replacement" disk with previous disk signature and partition id, I do not lose my volume shadows in the process.

 

As far as I am concerned (i.e in my virtual lab), keeping the disk signature and partition id  (and I believe the disk slot) does the trick : i.e i can clone a volume and keep its volume shadows.

 

Result.

Original DATA1  has been disconnected.

DATA2 "became" the new DATA1.

 

[sebus]

Lucky you. Not what I seen doing the same numerous times, but it does not matter any more to me really, I lost the lot anyway (it is all on backups in case anybody wants anything back)

I am not going to test it again. I can only clone 33Gb of test data that many times...

 

It "might" depend on amount of data etc, I really do not know

[sebus]

Worse case scenario, only the bytes between sector 0 and partition 1 starting offset should be different.

Best case scenario : no byte should be different.

 

That is definitely not so. Source dynamic vhdx, 127Gb, actual data 33Gb, size of the vhdx on disk 33Gb, v2v clone (destination same dymanic 127Gb vhdx) makes 126.9Gb vhdx on disk (and reported (inspection) as 126.6Gb)

That will he hugely different

[sebus]

Being me, I gave it one more shot. Fully updates VM OS (just in case)

 

Setup some shadow copies

That is before whole operation (just after V2V happened, CD still running below)

 

 

Then removed the source, moved "slot" of destination, renamed DiskID/PartitionID of destination.

 

All gone (same as every other test I performed)

 

 

There is nothing more I can think of

 

sebus