# start notepad++ "C:\Windows\Start_BE_UTIL01_RDX_JOB.ps1" PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& "Īnd here is the PowerShell script to start the Backup Exec job called “23:10 UTIL01 RDX-Full”. rem start notepad++ "C:\Windows\Remove_BackupExec_IMG_Folders.cmd" I accept zero liability and responsibility if you use these scripts!!!** Use any tips, tricks, or scripts I post at your own risk. **NOTE – the following deletes data from your backup cartridges. This script in turn launches a PowerShell script that deletes all the IMGxxxxxx folders off the RDX drive except IMG folders that contain either ntds.dit or edb.chk. In the job’s Advanced Settings menu, I added a pre-run script that runs C:\Windows\Remove_BackupExec_IMG_Folders.cmd. I then create a new Veeam job that did active fulls to the RDX drive every night (with a restore points to keep of 1). In the end, I setup the RDX drive as a new rotated drive repository in Veeam (prior to this Veeam only backed up to the HPE StoreOnce). I also discovered (or at least in the environments that I’ve setup) that GRT enabled application backups (not VMs, but rather SQL, AD, Exchange) will also be in an IMG folder with either a file called ntds.dit or edb.chk, and sometimes both! In my case, my 2012R2 server has SQL and AD on it, so I want to be careful not to delete IMG folders that potentially contain my SQL and AD backups (which could screw Backup Exec up even more than normal when it uses that cartridge again for the 2012R2 server). So what do I do?Ī little PowerShell scripting to the rescue – that is what I am going do!Īfter going through a sampling of several RDX cartridges at several different client sites, I’ve determined that when Backup Exec runs with GRT enabled it dumps those backed up VMs in IMGxxxxxx folders on the root of the RDX drive (including the VMDKs). And finally, even though I’m dumping Backup Exec for my VMware backups, I still need to use Backup Exec to backup the 2012R2 physical instance to the same RDX cartridge that Veeam is going to use (atleast until Veeam releases their next project). And I certainly don’t want to have to log into the clients’ servers everyday to manually delete the old Backup Exec folders off the RDX (as they come up in rotation) so that there is enough room for the nightly Veeam backup.
I can’t just erase all these cartridges in one swoop and use them for Veeam backups. Oh – and many, many, many RDX cartridges that have months of rotated backups on them that are all three quarters full.
Several of my clients have single standalone ESXi hosts, an HPE StoreOnce appliance, a physical Windows Server 2012R2 with a RDX drive or two (for offline backups), and both Backup Exec and Veeam loaded on that Windows server. So now it’s time to fully embrace the move to Veeam, which I’ve been considering for some time (note of disclosure – I am also a certified Veeam VMCE – v7, v8, & v9) Today was the last straw with Backup Exec, their crappy bugs, and unreliable VMware backups. Technical support has been off-shored and 99.9% of the time, if I am lucky enough to finally reach someone in technical support on the phone, I can’t understand a damn word they say due to their thick accent and shitty VOIP lines crossing the Pacific Ocean. But it’s reliability has dropped to nothing over the past 6 or 7 years. Once upon a time, it was a great product – in fact it was the only product for backups that worked worth a damn. I’ve been selling, supporting, certified on and even using Backup Exec for our own internal backups since it was Conner Backup Exec for Windows NT 3.1, way back in 1993.
Ok – I’m completely done with Backup Exec when it comes to VMware.