VMware Cloud Community
Bentech
Contributor
Contributor
Jump to solution

Disaster has struck...

All, our environment consists of 18 ESX host with shared NFS volumes across all.  The issue at hand here is work was being done on the NetApp and an IP, which I used to map the volumes, was lost as it was only in the running configuration.  In addition to this issue, SMVI backups were running when volumes were lost so all the snapshots are corrupt.  I have a script, seen below, that backs up all the VMX files, zips them up and keeps the last 7 days. Can someone please let me know if it is possible to take all the vmx files I have backed up and replace the ones pointing to the corrupt snaps via script?

Any help is appreciated.  I’d hate to remove and attach 3 disks from 375 guest machines to point to the base vmdk.

I must mention that I have borrowed code found in this community to piece together the below script.  I thank you all!

$folder = "c:\vmxbackup"
$vmxarchive = "c:\vmxbackup\archive"
Remove-Item $folder\*.vmx

Get-VM | `
  Get-View | `
  ForEach-Object {
      $vmxfile = $_.Config.Files.VmPathName
      $dsname = $vmxfile.split(" ")[0].Trim("[]")
      $ds = Get-Datastore -Name $dsname
      New-PSDrive -Name ds -PSProvider VimDatastore -Root '/' -Location $ds
      Copy-DatastoreItem -Item "ds:\$($vmxfile.split(']')[1].TrimStart(' '))" -Destination $folder
      Remove-PSDrive -Name ds
  }

# Zip VMX files and Archive keeping last 7 days

$filename = "vmxBackup-{0:yyyyMMdd-HHmm}.zip" -f (Get-Date)
dir $folder | Where-Object {$_.PSIsContainer -eq $false} | ForEach-Object {C:\"Program Files (x86)"\7-Zip\7z.exe a -mx9 -tzip $filename $_.FullName}
Move-Item "c:\Scripts\$filename" $vmxarchive
Remove-Item $folder\*.vmx
$archiveClean = get-item $vmxarchive\* -Force | Where-object {$_.Name -like "*.zip"} | Sort-Object -Property LastAccessTime -Descending
$archiveClean[7..($archiveClean.count-1)] | % {remove-item $_.fullname -force -ErrorAction SilentlyContinue}

0 Kudos
1 Solution

Accepted Solutions
mattboren
Expert
Expert
Jump to solution

Hello, Bentech-

This does not sound like a very exciting situation in which to be.  Below is something that should do what you are asking.  It will check the datastores in the vCenter(s) to which you are connected for .vmx files and copy a .vmx file of the same name from the given backup location to the corresponding datastore location.

Understand, this is doing nothing more than copying your backed-up .vmx files over the .vmx files that reside on the datastores (not to be negative, but I worry that if the .vmx files on the datastores are corrupt, the rest of the VMs' files there are potentially corrupt, too).

I would also, just to be safe, run your backup script once again before running this to copy over the .vmx files. That way, if the need were to arise, you can get things back to the state in which they currently are (don't want to make things worse).

## path to folder where unzipped "good" VMX files reside
$strSrcFolder = "C:\temp\vmxbackup"

## array of the VMX files on all datastores in connected vCenter(s)
$arrVMXFilesOnDatastores = dir vmstores:\ -Recurse -Include *vmx
## for each VMX file on the datastores, replace it with the corresponding "good" VMX file from the temp directory
$arrVMXFilesOnDatastores | %{     Copy-DatastoreItem -Item $strSrcFolder\$($_.Name) -Destination $_.FullName -WhatIf } ## end foreach-object

In order to really copy the files, remove the -WhatIf parameter.  It might be good to add the -Confirm:$false param (though my testing did not require it), and the -Force (if copies are failing to overwrite existing VMX files, possibly due to a lock). You could try just the first VMX file for starters by adding "[0]" to the "$arrVMXFilesOnDatastores | %{" line, making it "$arrVMXFilesOnDatastores[0] | %{".

This should be fine if there are no duplicate VM names in your vCenter.  If there are, this overwrites the VMX file from one or the other with the VMX from from the "other" VM of the same name.  But, surely no one has duplicate VM names ever, right?

Good luck.

View solution in original post

0 Kudos
2 Replies
mattboren
Expert
Expert
Jump to solution

Hello, Bentech-

This does not sound like a very exciting situation in which to be.  Below is something that should do what you are asking.  It will check the datastores in the vCenter(s) to which you are connected for .vmx files and copy a .vmx file of the same name from the given backup location to the corresponding datastore location.

Understand, this is doing nothing more than copying your backed-up .vmx files over the .vmx files that reside on the datastores (not to be negative, but I worry that if the .vmx files on the datastores are corrupt, the rest of the VMs' files there are potentially corrupt, too).

I would also, just to be safe, run your backup script once again before running this to copy over the .vmx files. That way, if the need were to arise, you can get things back to the state in which they currently are (don't want to make things worse).

## path to folder where unzipped "good" VMX files reside
$strSrcFolder = "C:\temp\vmxbackup"

## array of the VMX files on all datastores in connected vCenter(s)
$arrVMXFilesOnDatastores = dir vmstores:\ -Recurse -Include *vmx
## for each VMX file on the datastores, replace it with the corresponding "good" VMX file from the temp directory
$arrVMXFilesOnDatastores | %{     Copy-DatastoreItem -Item $strSrcFolder\$($_.Name) -Destination $_.FullName -WhatIf } ## end foreach-object

In order to really copy the files, remove the -WhatIf parameter.  It might be good to add the -Confirm:$false param (though my testing did not require it), and the -Force (if copies are failing to overwrite existing VMX files, possibly due to a lock). You could try just the first VMX file for starters by adding "[0]" to the "$arrVMXFilesOnDatastores | %{" line, making it "$arrVMXFilesOnDatastores[0] | %{".

This should be fine if there are no duplicate VM names in your vCenter.  If there are, this overwrites the VMX file from one or the other with the VMX from from the "other" VM of the same name.  But, surely no one has duplicate VM names ever, right?

Good luck.

0 Kudos
Bentech
Contributor
Contributor
Jump to solution

Matt, I can't thank you enough for helping me with this.  This IS the worst situation I've ever been in and I have been manually fixing the VM's nonstop.  I will definitely run the backup before any storage work is done and will also take your advice as to implement the script.

This is huge…  Thank you again,

Rob

0 Kudos