When you perform an agent-based backup, mminfo will give you a saveset-by-saveset breakdown of what was protected. For filesystem backups, that’ll be a list of the different filesystems protected: /, /usr, /home, etc., for Linux/Unix, and C:\, D:\, etc., for Windows.
For example, here’s a simple mminfo output for one of my lab clients, abydos:
[Wed Nov 13 19:07:27] [• ~ •] root@orilla $ mminfo -q "client=abydos,savetime>=1 week ago,level=full" volume client date size level name Backup.01 abydos.turbamentis.int 09/11/19 6314 MB full / Backup.01 abydos.turbamentis.int 09/11/19 290 MB full /boot Backup.01 abydos.turbamentis.int 09/11/19 2 KB full /d/data Backup.01 abydos.turbamentis.int 09/11/19 5025 KB full /home BoostClone.002 abydos.turbamentis.int 09/11/19 6314 MB full / BoostClone.002 abydos.turbamentis.int 09/11/19 290 MB full /boot BoostClone.002 abydos.turbamentis.int 09/11/19 2 KB full /d/data BoostClone.002 abydos.turbamentis.int 09/11/19 5025 KB full /home
So I can see straight away from the output that there were four filesystems on abydos when it got its last full backup: /, /boot, /d/data and /home.
But what about virtual machine backups – proxy-based backups?
For those, the default output of mminfo focuses just on telling you the virtual machine was backed up. For example:
[Wed Nov 13 19:10:25] [• ~ •] root@orilla $ mminfo -q "savetime>=3 days ago,level=full,pool=BoostBackup" volume client date size level name BoostBackup.002 oaktier.turbamentis.int 11/11/19 157 GB full vm:500f1260-a7be-d5cf-0395-761e835a891b:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 12/11/19 157 GB full vm:500f1260-a7be-d5cf-0395-761e835a891b:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 11/11/19 16 GB full vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 12/11/19 16 GB full vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 11/11/19 83 GB full vm:500f6743-c531-f607-b47a-b00d26e67d4b:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 12/11/19 83 GB full vm:500f6743-c531-f607-b47a-b00d26e67d4b:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 11/11/19 574 GB full vm:500fe40e-5be3-28fc-5b57-881485c2a897:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 12/11/19 574 GB full vm:500fe40e-5be3-28fc-5b57-881485c2a897:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 11/11/19 33 GB full vm:5029e15e-3c9d-18be-a928-16e13839f169:oaktier.turbamentis.int BoostBackup.002 oaktier.turbamentis.int 12/11/19 33 GB full vm:5029e15e-3c9d-18be-a928-16e13839f169:oaktier.turbamentis.int
Now, getting the virtual machine ID like that isn’t particularly helpful, so you can adjust your mminfo query to get the virtual machine name using the ‘-k’ option, thusly:
[Wed Nov 13 19:10:40] [• ~ •] root@orilla $ mminfo -q "savetime>=3 days ago,level=full,pool=BoostBackup" -k volume type vm_name date time size ssid fl backup_size BoostBackup.002 Data Domain win01 11/11/19 02:00:12 157 GB 1606952444 cr 157 GB BoostBackup.002 Data Domain win01 12/11/19 02:00:11 157 GB 449410941 cr 157 GB BoostBackup.002 Data Domain vulcan 11/11/19 02:00:13 16 GB 1590175228 cr 16 GB BoostBackup.002 Data Domain vulcan 12/11/19 02:00:15 16 GB 382302077 cr 16 GB BoostBackup.002 Data Domain test01 11/11/19 02:00:11 83 GB 1623729660 cr 83 GB BoostBackup.002 Data Domain test01 12/11/19 02:00:14 83 GB 399079293 cr 83 GB BoostBackup.002 Data Domain andoria 11/11/19 02:00:14 574 GB 1573398012 cr 574 GB BoostBackup.002 Data Domain andoria 12/11/19 02:00:12 574 GB 432633725 cr 574 GB BoostBackup.002 Data Domain krell 11/11/19 02:00:15 33 GB 1556620796 cr 33 GB BoostBackup.002 Data Domain krell 12/11/19 02:00:13 33 GB 415856509 cr 33 GB
That makes it more readable, for sure – but what if you want to know, using mminfo, what virtual disks were actually backed up? Well, for that, ‘-S’ is your friend.
The “mminfo -S” invocation allows you to drill down and see a lot of additional details about a NetWorker backup. You may recall a blog article earlier in the year where I showed how to use mminfo -S to drill into dependencies between PSS savesets.
You can run mminfo -S against multiple savesets concurrently, but given the amount of information it produces, I usually prefer to run it against a single saveset.
To give you an example, let’s first pick a saveset. Now, I could use the ‘-k’ option in mminfo again, but the other way we can get the virtual machine name is to use a report option of vmname. So let’s start by finding my virtual machine backups generated in the last 3 days:
[Wed Nov 13 19:20:06] [• ~ •] root@orilla $ mminfo -q "pool=BoostBackup,level=full,savetime>=3 days ago" -r "vmname,savetime,ssid" vm_name date ssid win01 11/11/19 1606952444 win01 12/11/19 449410941 vulcan 11/11/19 1590175228 vulcan 12/11/19 382302077 test01 11/11/19 1623729660 test01 12/11/19 399079293 andoria 11/11/19 1573398012 andoria 12/11/19 432633725 krell 11/11/19 1556620796 krell 12/11/19 415856509
(In this case, in my lab, I usually only backup virtual machines to my DDVE, since it’s the free 0.5TB version. If someone wants to send me a DD9900 to use, I’ll gladly send all backups to that and even argue with my husband about where it’ll fit in our garage…)
Now, let’s say I want to see more details about what was the virtual machine ‘vulcan’ contained during the most recent backup. To do that, I’d run mminfo -S against the saveset generated on 12 November 2019, and that command and output would look like the following:
[Wed Nov 13 19:21:41]
[• ~ •]
root@orilla
$ mminfo -S -q "ssid=382302077"
ssid=382302077 savetime=12/11/19 02:00:15 (1573484415) oaktier.turbamentis.int:vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int
level=full sflags=vrF size=17196675068 files=1 insert=12/11/19
create=12/11/19 complete=12/11/19 browse=12/02/20 23:59:59 retent=12/02/20 23:59:59
clientid=82880f28-00000004-5cc29a5e-5cc29a5d-00015000-9f778f56
**backup start time: 1573484415;
*backup_device: Data Domain;
*backup_mode: VSS;
*policy action name: "backup: 1573484412", "clone: 1573485492";
*policy name: "VMware: 1573484412 1573485492";
*policy workflow name: "Virtual Machines: 1573484412",
"Virtual Machines: 1573485492";
*policy_workflow_action_path: /VMware/Virtual Machines/backup;
*proxy_hostname: hanko.turbamentis.int;
*ss data domain backup cloneid: 1573484412;
*ss data domain dedup statistics: "v1:1573484412:17195263820:14789:10382",
"v1:1573485492:17187582892:7905216:7674846";
*SSID directory: Yes;
*vcenter_hostname: oaktier.turbamentis.int;
*vm_backup_level: incr;
*vm_info: \
"{
\"name\": \"vulcan\",
\"host-name\": \"\",
\"ip-address\": \"\",
\"template\": false,
\"moref-id\": \"vm-58\",
\"vcenter-name\": \"oaktier.turbamentis.int\",
\"path\": \"/home/kobol.turbamentis.int/vulcan\",
\"moref-path\": \"/datacenter-21/domain-s26/vm-58\",
\"vm-path\": \"/home/vulcan\",
\"moref-vm-path\": \"/datacenter-21/vm-58\",
\"datastore\": \"datastore2-samsung-ssd\",
\"datastore-moref\": \"datastore-31\",
\"os-identifier\": \"centos64Guest\",
\"os-name\": \"CentOS 4/5 or later (64-bit)\",
\"version\": \"vmx-08\",
\"change-version\": \"2019-04-26T05:15:52.859306Z\",
\"esxi-moref\": \"host-28\",
\"esxi-name\": \"kobol.turbamentis.int\",
\"datacenter\": \"datacenter-21\",
\"compute-resource\": \"domain-s26\",
\"cluster-compute-resource\": \"\",
\"networks\": [
\"VM Network\"
],
\"disks\": [
{
\"display-name\": \"Hard disk 1\",
\"datastore\": \"datastore2-samsung-ssd\",
\"datastore-moref\": \"datastore-31\",
\"disk-key\": 2000,
\"size-kb\": 16777216,
\"thin\": true,
\"disk_stats\": {
\"Statistics\": {
\"ProvisionedBytes\": 17179869184,
\"UsedBytes\": 7701463040,
\"ChangedBytes\": 0,
\"SecondsTaken\": 0
},
\"DDStatistics\": {
\"PreClientCompBytes\": 0,
\"PostClientCompBytes\": 0,
\"TotalSegments\": 0,
\"RedundantSegments\": 0
},
\"BaseFileName\": \"\"
}
}
]
}";
*vm_name: vulcan;
*vm_uuid: 500f21cd-5865-dc0d-7fe5-9b93fad1a059;
group: VMware_Virtual Machines;
saveset features: CLIENT_SAVETIME;
Clone #1: cloneid=1573484412 time=12/11/19 02:00:12 retent=12/02/20 flags=
frag@ 0 volid=3497323266 file/rec= 0/0 rn=0 last=12/11/19
Clone #2: cloneid=1573485492 time=12/11/19 02:18:12 retent=12/01/20 flags=
frag@ 0 volid=3679897583 file/rec= 0/0 rn=0 last=12/11/19
I’ve used bold/italics in the output above to highlight the virtual-machine specific details produced by mminfo -S. You’ll see if you scan through that it tells us:
- What proxy was used to back it up
- The vCenter it belonged to
- Whether it was a full or incremental backup (a scheduled incremental is generated as a virtual synthetic full, though – but this helps us understand whether the entire VM was processed end-to-end, or whether it was just an incremental scan of the VM)
- A whole bunch of nitty-gritty VM details, including:
- What ESX server it was on, and its path
- What network the VM was on
- What the virtual machine type was
- What version the virtual machine was
- For each disk, details about virtual disk provisioning, size, etc.
As I understand it, you can get this sort of information via the REST API as well (deep-diving into the REST API has been a slow-burning project for me since I’ve wanted to Python first to tackle it, and I’m only just getting to that now), but if you’re not yet ready to dive into the REST API, you can see that it’s equally there for you using mminfo, too.
So there you have it – how to pull detailed information from mminfo about virtual machine backups.
[Edit – 2019-11-14]
Per Uwe’s comments, the REST API doesn’t provide this level of detail at this point. Also, the disk details are limited to the first four disks – I suspect this will be explicitly related to a maximum record size within the media database.
Hi Preston,
I have to disappoint you,
There are 2 problems with the VM-Backup-Informations you get from NetWorker.
1. The REST-API gets you only a portion of the mminfo information. For Example there is no Information about the Disk attributes “ProvisionedBytes” and “UsedBytes”. Al lot of other Attributes are also missing 🙁
2. But also the mminfo output is lacking information, if your VM has 4 or more Disks. If this is the case, the information is truncated and the output of the 4’th disk is only a part of it, the 5’th and more disks aren’t given 🙁
kind regards Uwe
Thanks, Uwe, I’ll update the article!
Hi Uwe,
could it be that you use an older NW version, not 19.1.1?
In my configuration, I do not see any difference in the parameters.
Best regards, Carsten
Hi Carsten,
no, I used 19.1.1
If you look at the disk information you will see the differences. I double checked it.
kind regards Uwe