Note: For an equivalent guide for Hyper-V backups, read the article here: [Guide] Extract files and folders from a Virtual Dashboard (AVD) Hyper-V backup set manually, in case import does not work
If you have VMware backups produced (completed backups) by the NovaBACKUP Virtual Dashboard (AVD) and you need to import them into another copy of NovaBACKUP Business Essentials (B.E.) software, say for instance you had to rebuild the machine that NovaBACKUP B.E. was running on, then you can make use of the Recover Previous (the function of the AVD that allows performing an Import of previous backups) function in the Virtual Dashboard (AVD), to import your previous backup sets into the AVD, by browsing to the root folder where your AVD backups were originally stored to for the destination path, and that should import the entries into the Virtual Dashboard (AVD) so that you can browse the VM by mounting it or restoring the VM backup to a VMware server via the AVD, to restore individual files after booting the VM. There is the chance that the Recover Previous (Import) function may not work for you, or for whatever reason the Mount or Restore function fails, you can utilize another manual extraction method which does not require the NovaBACKUP software to restore files from a VMware VM produced by the Virtual Dashboard. This guide will also work for those that no longer have their Virtual Dashboard 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++).
If you are trying to make use of the Recover Previous function in NovaBACKUP Business Essentials software, to import your old VMware backups that were produced by Virtual Dashboard in NovaBACKUP 19.x, to import the history of those previous VMware backups to be able to either mount or restore files from a VMware VM in that backup set, and the Recover Previous function is not working for you, like you get an error utilizing the function and so no backup sets are imported, you can utilize this workaround (for a Windows VM machine backup), to browse the VMware .VMDK (virtual hard disk) file that the Virtual Dashboard backup produced using 7-Zip, or you can always just associate that largest file in the backup set to associate all of the virtual hard disks in the backup set to attach those files (renamed to .VMDK) to a new VM that you create in VMware vCenter or ESXi, to boot that new VM and restore files from it that way.
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 he can take that renamed file and upload it to the vCenter or ESXi datastore to attach it to a new VM there and boot it:
After opening the largest file in the VM backup set, which in your case you may have multiple of those files, one per virtual hard disk in the VMware VM, you then browse to the "drive" object to open it, in that case we have two drives in this Windows Server 2016 Core VM, but the first one 0.ntfs is just the Boot Partition that is 500 MB, the 1.ntfs is our C: drive in the Windows VM and our only large hard disk, after we double-click on "1.ntfs" folder/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, seen here:
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).
In our above example, each VMware VM backup job utilized a destination path value that contained the name of the VM, which is something that you could do as it is part of the backup job creation when you are asked to set the destination path, the path could contain the name of the VM but you would have needed to do that as part of your original Virtual Dashboard created jobs, to contain the VM name in the destination folder, per backup job. In case when you created your Virtual Dashboard VMware VM backup jobs you did not name your destination folders for where each VM backup will be stored to utilize a folder name, that contained the name of each VM for where it stores to your Backup Folder + VM name, per job, and you don't know which folder inside the Virtual Dashboard folder structure that can be confusing to the eye if you don't name your folders to contain the VM name in each job, for the destination folder that each job utilizes, you can utilize a search in files function, such as the one in NotePad++, which contains a "Find in Files" search function that allows you to search an entire folder structure to find a search string inside files and folders, example of searching for a particular VM name, in my case "JF-Server2016Core" is searched for in my "C:\Backups\Virtual Dashboard" root folder, where backups live for multiple VMs, and the search results for that string are found inside the "Search results" window pane where the name of my VM I'm searching for is found 73 times in my Backups folder, to then give me the clue as to what actual path to navigate to via Windows Explorer to get to the largest virtual hard disk files (stored as VMware .VMDK virtual hard disk files natively but not named as such with that file extension), in this case the blue highlighted portion of the search results is my clue to know where this VM backup is currently stored:
Warning: If after clicking on 'Find All' function to start the search, NotePad++ prompts you to Open huge file warning 2GB+, then click the "No" button each time, as that is not necessary and will be insanely slow to search huge files for the VM name text string:
If I look further down in the Search results, I can see on Line 15 is the scsi0:0 disk and the actual name of the original .vmdk virtual hard disk file that was backed up is displayed, and on Line 24 I can read the "displayName" value of the original VM name to confirm the VM name exactly in the results, and on the right side of the screenshot I can see the date that backup was written to the destination storage location, as that same virtual hard disk .vmdk file found in the results, although when it was backed up as a VMware backup via AVD the file name is named in a seemingly random fashion and does not contain the .vmdk file extension in-tact:
Of course if you have multiple VM's named with the same name but with differences in between, like appended to the start or end, you of course will get more than one result for that one VM name search, you can use "Match whole word only" option in NotePad++ in that case if you would like to narrow down the result further. I look further down in the Search results, and after navigating to that path that is in the search results output, I can see the date that backup was written to the destination storage location, as that same virtual hard disk .vhd or .vhdx file to restore content from manually, by opening that file with 7-Zip or otherwise.
Each backup will produce a new sub-directory under the original, per new backup 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. The search in files function in NotePad++ can help you determine the VM name and looking at the file dates in Windows Explorer will tell you what date each VM backup was performed on.
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.