Hyper-V disks 'last modified' ages ago

[localzuk]

I'm just looking into our backups and have noticed something odd - probably because I don't understand something.

 

Some of our servers (the low IO ones, like the KMS server and the DHCP server) have a last modified date on the vhdx files of sometime back in September. The high IO ones are basically up to date, modification-wise.

 

This means that our backups of those servers are seriously out of date - a restoration would return the server to its state at that modification date.

 

To give a little explanation of our setup:

 

We use 2 Windows 2012 nodes as our Hyper-V boxes, and a third as our storage server. The hyper-v guests are accessed via a 10GbE connection, from SMB3.0 shares.

 

To backup, we use BackupAssist 7.1, which supports this setup.

 

So, why are the low IO systems not writing to disk? How can we solve this?

[ZeroHour]

Any snapshots?

Also when you shut one down and wait 30 seconds does the time update then?

[localzuk]

Yeah. If I shut down it does writes to disk. Same if I run a snapshot.

 

Hadn't used snapshots yet, but until I can figure out a proper fix, I'll be running them before I leave on a Friday for now.

[ZeroHour]

I *think* when you make a snapshot the original vhd doenst change (and would no longer be modified) as any subsequent changes are written to a fresh file. When you delete the snapshot and shut down the vm the changes are then merged back into the original vhd file.

I just wondered if you had any saved snapshots which meant disk changes were going to the next file.

[Bruce123]

I *think* when you make a snapshot the original vhd doenst change (and would no longer be modified) as any subsequent changes are written to a fresh file. When you delete the snapshot and shut down the vm the changes are then merged back into the original vhd file.

I just wondered if you had any saved snapshots which meant disk changes were going to the next file.

 

That was my thoughts exactly, and running low disc IO servers in snapshot mode makes more sense (rather than on high IO servers) as the snapshot file won't get too big.

 

Bruce.

[DMcCoy]

The file is changing, but the last modified date won't update until it is closed again, when the VM is rebooted or powered off. That's how windows uses the modified date for all other types of files.

[localzuk]

The file is changing, but the last modified date won't update until it is closed again, when the VM is rebooted or powered off. That's how windows uses the modified date for all other types of files.

 

Then why did my restore from a backup on Friday return that server to September some time?

[DMcCoy]

Then why did my restore from a backup on Friday return that server to September some time?

 

No idea, so I've been poking around.

 

I've just had a look at my Hyper-v 2012 box at home, and most of the disks are changing the modified time, but not all, even when changing the contents. On older versions the modified time often was not updated, although this may have changed now I am using ReFS.

 

It was however updated to when the backup started a vss snapshot of the machine, but the built in 2012 backup saves the state of the machine, taking it offline for a couple of minutes. Are you using ntfs or ReFS for the vhdx files? Was the entire system state reverted when you restored, I assume it's a single vhd?

 

I would suggest you look at vssadmin list shadows to see what shadow copies are still around in case the backup software is copying an old one if the creation doesn't work successfully.

[glennda]

Then why did my restore from a backup on Friday return that server to September some time?

 

I'm fairly sure it is because the timestamp is when a file (in this case VHD) is fully written to and disconnected from. So when the server shutdowns the VHD is completely written too and left alone. While the server is running the VHD is constantly open and written too therefore the last time its written too is so far behind.

 

In terms on why the backup is like this is because when it is restoring the file it is restoring it to is last known data and this happens to include a time stamp of potentially a long long time before the backup was taken. As during the backup the file isn't fully closed etc.

 

The same with Snapshots, VM snapshots are totally different to Storage Snapshots in that the primary disk is frozen and a new disk created that any modifcations are written too, hence the reason snapshots should not be left open as they can potentially if left open long enough grow to a huge size and fill up the disk (i mean I have seen a snapshot for a 40GB drive be over 100gb)