[Guide] Granular restore files in a DataCenter VMware VM backup set, or utilize the native virtual hard disk(s) stored in the backup to create a new VM and attach the disk to, in case the restore or mount functions in the DC UI do not work
Note: For an equivalent guide for Hyper-V backups, read the article here: [Guide] Granular restore files in a DataCenter Hyper-V VM backup set, or utilize the native virtual hard disk(s) stored in the backup to create a new VM and attach the disk to, in case the restore or mount functions in the DC UI do not work
This guide (which indicates it is for v9.x but basically works the same way in 7/8/9) would be useful to you if you have VMware VM backups produced (completed backups) by NovaStor DataCenter 7/8/9, stored to a GIR / Image Pool (no other Media Pool / Disk Pool type will work for this, nor would storing or cloning VM backups to tape work either), and you need to either granularly restore files and folders from the backup set, or you need to restore the entire VM to attach the native virtual hard disk(s) stored in the backup set produced by NovaStor DataCenter 7/8/9 software, because say for instance you lost your Command Server and you no longer have the Restore history / indexed backups to be able to browse through these VMs to be able to perform full VM restores or even perform Granular single file / folder restores of files in a VM backup, or be able to utilize the Mount function in DC UI, to mount a VM backup to utilize Windows Explorer to do granular restores of files that way, so say for instance you had to rebuild the machine that DataCenter Command Server was running on, and you don't even have a backup of the DataCenter database to utilize there so you have no backup history / restore / log records, then you can make use of the backup set files at rest on the target filesystem to restore a VM backup that is at rest on a GIR / Image Pool only (no other Media Pool / Disk Pool type will work for this), by browsing to the root folder where your DC backups were originally stored to for the destination path, corresponding to the log and pool.db file entries that each backup created by producing the DataCenter backup would have created, per each VM backup run, to allow you to be able to browse the contents of each VM backup by either mounting it with native VMware or Hyper-V mount virtual hard disk tools installed already in your OS where you are browsing the backup folder structure on, or by installing a freeware file extractor such as 7-Zip (used exclusively in this example), or you could utilize the native virtual hard disk files (.vmdk files) that the backup to a GIR / Image Pool produced when DC created the backup, by knowing where the .vmdk files are in the VM backup set and restoring the .vmdk files to the Datastore on your VMware ESXi server manually, by uploading the files to the Datastore manually, to be able to restore individual files after booting the new VM with those native VMware virtual hard disk .vmdk files attached as disks to the new VM. This guide will also work for those that no longer have their DataCenter produced backups stored to the original location, perhaps your backup folders were copied to a NAS later on. Note: In the example backup sets for our Virtual Dashboard produced VMware backup jobs, they used a destination folder of "C:\Backups\Virtual Dashboard" as the root folder, and then each VMware backup job that was created in the AVD had a sub-folder under that root folder containing the name of the VM in each case when creating the job originally, doing this during the job creation makes it easier to identify where each AVD produced VM backup is stored to, by looking at the folder structure in Windows Explorer, as to what named VM it is in the produced backup set folders, when you are attempting to locate a particular backup (VM name + date of backup). Each time a subsequent VM backup job is run for a single VM, it will create a new randomly named sub-folder under that named VM folder, in the example that is "C:\Backups\Virtual Dashboard\JF-Server2016Core\", and the date and time can be read by browsing to that folder structure, as each backup that was executed for that single VM just contains sub-folders per date that the job was run on, under that path. Not everyone names their destination path per AVD backup job this way to make it easier to know what folder is associated to what VM, although it would be recommended to do so, so in that case in the second half of this guide we show you how to know what folder in the backup set path equates to which named VM in the backup set (using the "Find in Files" search function in NotePad++).
DataCenter currently, as of 02/21/2023, has no way to Import previously completed VM backups, produced by any version of DataCenter so far released *, and after that be able to have those at rest and completed VM backups list as "Restore" index entries in the Restore section of the DC UI (in any version yet produced so, 7/8/9) to be able to Restore / Browse / Mount those imported VM backups, so in that case there are a few ways that you can still utilize the at rest backup set files to utilize this workaround (for a Windows VM machine backup), to browse the VMware .VMDK (virtual hard disk) file that the DataCenter 7/8/9 software would have produced as a completed backup to a GIR / Image Pool only (no other disk pool or storage pool type will work for this) using the freeware 7-Zip application installed in Windows on the machine you will be browsing the target backup location with, which you can do without renaming any of the backup set files, or you can simply manually associate that largest file in a produced VMware backup set (one completed run of a VM backup) to associate all of the virtual hard disks (which DC 7/8/9 if storing to a GIR / Image Pool stores as native .vmdk files it just names them with random filenames and doesn't append the .vmdk file extension for you to know that) in the backup set to attach those files (that you manually rename to contain the .vmdk file extension) to a new VM that you create in VMware vCenter or ESXi, to boot that new VM and restore files from it that way. *The ability to import VM backups (and other backup types for that matter) and list each backup as Restore index entries for those now imported backups to be able to restore them via the Restore section of the DC 9.x UI will be coming in a future version of DataCenter 9.x, but I have no estimate as to the version or date or that future release to be able to indicate that info here.
You should be able to utilize this workaround (for a Windows VM only) if you need to restore files from a VMware backup of a Windows VM that was produced by the Virtual Dashboard, to open the largest file(s) (which are the entire native .VMDK virtual hard disks), with this method there is no need to add the .VMDK file extension to the largest file, using 7-Zip for Windows to extract files and folders from the virtual disk files in the backup set (the largest files in the backup set are the .VMDK files). The examples here were browsing the largest backup file in the Virtual Dashboard produced VMware backup set, per VM backup, by right-clicking on that largest file and doing a Open with 7-Zip, or you can take that renamed, by first manually adding the .vmdk file extension to that largest file (in the original location or the copied location), and then upload the .vmdk file(s), to the vCenter or ESXi datastore to attach the .vmdk file(s) to a new VM there and boot the VM (where you can copy files from that booted VM) [Note: This first screenshot below shows the contents of a DataCenter 9.2.14 produced VMware backup log, for the Summary tab section of the log, but the contents of that section of the same VMware backup log produced by version 7 and 8 would look the same in this regards and in the context of this article in fact] [Note: Please open the image in a new browser tab to see the image full screen if the text is too small to read]:
After opening the largest file(s) in the VM backup set, which in this case will always correlate to a virtual hard disk file (in VMware that would be the .vmdk file but when DC produces a VMware backup set to a GIR / Image Pool it creates multiple random named files with no extensions on them), and depending on the disk makeup / structure in the original VM, you may have multiple of those files, one per virtual hard disk in the VMware VM, you then browse to the "disk" object to open it, in that case we have two disks in this Windows Server 2016 Core VM, but the first one seen after opening the largest file (a native virtual hard disk file which has a random filename and no file extension) shows at the top level after opening that file in 7-Zip as "0.ntfs" disk object, is just the small Boot / System Reserved Partition that is 500 MB, and the "1.ntfs" disk object is our C: drive in the Windows VM and our only large hard disk, after we double-click on the "1.ntfs" disk object in 7-Zip, we can then see the C: drive folder structure to be able to restore individual files or folders from the C: drive inside that Windows VM, and in that case our example detailed above, that corresponds to our single hard disk in the original VM, first renamed to contain the .vmdk file extension manually (which is not necessary to rename to be able to open it in 7-Zip but it makes it easier to tell what that file type is in the concept of this guide), that can be seen at the bottom right of the second screenshot below which shows the largest single file in the backup set opened in 7-Zip and already navigated to the "1.ntfs" disk object inside the .vmdk file below [Note: Please open the image in a new browser tab to see the image full screen if the text is too small to read]:
Note: You cannot utilize 7-Zip for Windows app to browse the largest file in the backup the same way if it is a Linux VM as compared to a Windows VM (that contains Windows File Systems like the above example uses which is NTFS disks), but they do have Linux tools to do this mount though, if his VM that he backed up is a Linux VM that is. The upload largest file to rename to .vmdk to datastore trick works to boot the VM in the same way though, to restore files from it once it boots up. I do not have a guide for how to do this for a Linux VM, but you can research how to mount a .VMDK file in Linux if you would like (directly from a separate Linux system of course).
Each VMware VM backup run of a particular VMware backup job will produce a new sub-directory under the original VM UUID "dir=" value, per each VM backup run of that same VM UUID that is executed and produced, and a sub-folder will be created for each separate virtual hard disk underneath that, so bear that in mind. When you are looking at the top level VM UUID "dir=" value folder structure in Windows Explorer, the Date column there will tell you what date each VM backup was performed on to give you a clue on which exact date a VM backup was produced and saved on, to correlate to the sub-folder name.
Note: For more help on using 7-Zip to extract files from a VMware .vmdk file, read this 3rd party article:
How to open a VMware .VMDK file using 7-Zip to browse the largest backup file(s) (read-only) and extract files and folders from it, here.