Backup VMDK's and datastore items with powercli writable volumes

[dgrinnell]

Hey Guys,

I have been looking for a solution that is a bit more flexible then the App Vol Backup utility and would allow me to build a scheduled automated task that backs up my writeable VMDK's and Metadata that go along with them and I figured why not kick this out to the community and see what we can come up with.

So here's my current logical process of what I'm going to be writing.

Writable: Logical Process

Couple Options here

run copy operation, whichever produced errors w/ lock due to attachment write to log (txt file), this log is used to identify which copy operations to run again which are the ones NOT in this log of the file.

Now the second thing is we need to get rid of vmdk's on the backup datastore because they cant be overwritten. Run a delete all operations on backup vmdks except whats in list (preserving the latest VMDK for the users still logged in and have their writable attached), so delete all vmdk (no need to delete metadata i can be overwritten) except whats in list, then run copy again, Do a get content run copy and excluded copy for all in the list that are "locked".

Challenges:

on Copy operation disk is locked due to being mounted

Metadata + Writable VMDK exists in backup dir which will cause backup to fail and don't want to do revisions because most recent is the best resource to backup due to customizations

Writables:  Biggest Challenge is user being logged on (writable attached makes VMDK locked and non-copyable) & cant overwrite so need to build in mechanism to remove and rewrite only if its not mounted

Script Logic

1. powercli Copy Operations ( if better lock checking is available im all ears)
2. Error handle "cant copy since vmdk is locked" due to "attachment" or User logged in
3. Use Locked VMDK Log and delete all backed up VMDK's in backup datastore that were NOT in that file ( this frees up and potential VMDK already exist conflicts, since we want that latest VMDK for the Writable Profile no need to create revisioning, just need latest Writable VMDK)
4. Rerun Copy Operation, but this time skip VMDK's in Locked Error Log , create text file of backed up VMDK's
5. Create two files for Email notification upon completion, Still Attached Writables (error log) , Backed up VMDK's
6. Metadata files are overwritten so can be included at the end of the script

If anyone can tackle any part of this or has any input that would be GREAT! I am starting the work today, but I will keep an eye on this post and hopefully, we can build a nice scalable writable backup solution.

Thanks!

[LucD]

I'm afraid I have no experience with the tool, but have you also asked in the Comments section of the Fling?

[dgrinnell]

Hey Lucd,

Yeah, it's a great utility and it essentially offers an "on demand" option to build a backup vm and attach the VMDK's that are the users app vols and then a third party backup solution like veeam can backup that VM.

The only issue on that is it's on demand and not a scheduled task and if a users VMDK is attached its locked, which really is not the utilities fault and they do have a pre and post script that will detach the VMDK, but that could be disruptive and I think i will use it to get my backups off site to a backup solution, but ideally, i wanted something i can build and set it and forget it and if we know this was backing up lets say weekly we could base our policies on that. That's what i did with my app stacks which are much easier to copy due to they dont get locked and the meta data copy i just used copy-datastoreitem and psdrives.

I did post my questions on the fling and will have to see what they say back, so im thinking if i can get these backed up to another datastore (which ones are not attached) i can then have a copy/backup of these vmdks and metadata.

thanks !!

[dgrinnell]

Hey Lucd,

I am trying to do a copy on a vmdk that is locked and if it error's out due to lock, do you know how to out-file that error after the copy, this way i could identify the "attaced" vmdk's.

Here's what i have so far on the error part to identify the locked / attached vmdk's.

$hdd = Get-Datastore datastore0* | Get-HardDisk | where {$_.filename -eq "[datastore01] cloudvolumes/writable/horizon_vdi.vmdk"}

copy-harddisk -HardDisk $hdd -DestinationPath "[AV-BACKUPS] writable-backups/"

So if the writable is mounted it errors w/ a lock, can i use that error and kick that out to a file? At that point on the next copy run i could skip the vmdk's that are in that file.

Error Example:

copy-harddisk :     Copy-HardDisk        The operation for the entity "VAV-BACKUPS" failed with the following message: "Unable to access file [datastore01]

cloudvolumes/writable/horizon_vdi.vmdk since it is locked" 

thanks!

[dgrinnell]

Here is what i have so far.

Get-Datastore source_datast* | Get-HardDisk | out-file c:\source-writables.txt

$writables = get-content c:\source-writables.txt

$hdd = Get-Datastore source_datast* | Get-HardDisk

foreach ($writable in $writables){

Try

{

copy-harddisk -HardDisk $hdd -DestinationPath "[AV-BACKUPS] writable-backups/"

}

catch

[VMware.VimAutomation.ViCore.Types.V1.ErrorHandling.FileLocked]{

write-host "locked"}

{

catch

[VMware.VimAutomation.ViCore.Types.V1.ErrorHandling.FileAlreadyExists]{

Write-Output "Already Exists"}

}

}

The two errors i get are "locked" and "already exists",  so i am trying to catch those errors.

thanks

[LucD]

See my replies on the other thread PowerCLI Error Handling

[dgrinnell]

Thanks LucD,

By adding a -force into the copy-harddisk that overwrote the existing vmdk on the backup datastore! Huge! ha

thanks again!

Just need to output Lock errors to identify users writable disk missed and this is solid!

thanks !

[dgrinnell · Accepted solution]

Hey Guys,

After some great suggestions from LucD​ to keep it simple essentially and some time i was able to come up with an automated solution to backup writable volumes and same logic can be applied to app stack which are far easier to backup due to no locks.

1. Locked (attached / logged in users) on errror will log to a file

2. Destination backed up VMDK's will be overwritten with a force - Thanks LucD​ for that one.

Check it out:

#Modules to import

Import-Module VMware.VimAutomation.Core

Import-Module VMware.VimAutomation.Common

#vCenter

$VC = vCenter01

connect-viserver $VC

#variables

$hdd01 = Get-Datastore writable-volume-ds-01* | Get-HardDisk

Copy-HardDisk -HardDisk $hdd01 -Force -DestinationPath "[AV-BACKUPS] writable-backups/" 1>> C:\scripts\logs\Successful-Writable-Backup.txt 2>> C:\scripts\logs\Attached-Writables.txt 3>> C:\scripts\logs\Writables-warnings.txt

#Metadata Backup

$datastoreFROM = Get-Datastore writable-volume-ds-01

$datastoreTO = Get-Datastore AV-BACKUPS

New-PSDrive -Location $datastoreFROM -Name ds0 -PSProvider VimDatastore -Root "\"

New-PSDrive -Location $datastoreTO -Name ds1 -PSProvider VimDatastore -Root "\"

Set-Location ds0:\

Set-Location ds1:\

#make sure to include CD or it wont be able to remove ds1

cd c:\

#Copy operation to back up all meta data to destination

Copy-DatastoreItem -Item ds0:\cloudvolumes\writable\*.vmdk.metadata -Destination ds1:\writable-backups\

Remove-psdrive "ds0","ds1"