{"id":8493,"date":"2019-11-13T18:31:22","date_gmt":"2019-11-13T08:31:22","guid":{"rendered":"https:\/\/nsrd.info\/blog\/?p=8493"},"modified":"2019-11-14T05:19:26","modified_gmt":"2019-11-13T19:19:26","slug":"basics-diving-into-networker-virtual-machine-backup-details","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2019\/11\/13\/basics-diving-into-networker-virtual-machine-backup-details\/","title":{"rendered":"Basics: Diving into NetWorker Virtual Machine Backup Details"},"content":{"rendered":"\n<p>When you perform an agent-based backup, mminfo will give you a saveset-by-saveset breakdown of what was protected. For filesystem backups, that&#8217;ll be a list of the different filesystems protected: \/, <strong>\/usr<\/strong>, <strong>\/home<\/strong>, etc., for Linux\/Unix, and <strong>C:\\<\/strong>, <strong>D:\\<\/strong>, etc., for Windows.<\/p>\n\n\n\n<p>For example, here&#8217;s a simple mminfo output for one of my lab clients, abydos:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[Wed Nov 13 19:07:27]\n [\u2022  ~  \u2022]\n root@orilla \n $ <strong>mminfo -q \"client=abydos,savetime&gt;=1 week ago,level=full\"<\/strong>\n  volume        client       date      size   level  name\n Backup.01      abydos.turbamentis.int 09\/11\/19 6314 MB full \/\n Backup.01      abydos.turbamentis.int 09\/11\/19 290 MB full \/boot\n Backup.01      abydos.turbamentis.int 09\/11\/19 2 KB full \/d\/data\n Backup.01      abydos.turbamentis.int 09\/11\/19 5025 KB full \/home\n BoostClone.002 abydos.turbamentis.int 09\/11\/19 6314 MB full \/\n BoostClone.002 abydos.turbamentis.int 09\/11\/19 290 MB full \/boot\n BoostClone.002 abydos.turbamentis.int 09\/11\/19 2 KB full \/d\/data\n BoostClone.002 abydos.turbamentis.int 09\/11\/19 5025 KB full \/home<\/pre>\n\n\n\n<p>So I can see straight away from the output that there were four filesystems on abydos when it got its last full backup: <strong>\/<\/strong>, <strong>\/boot<\/strong>, <strong>\/d\/data<\/strong> and <strong>\/home<\/strong>.<\/p>\n\n\n\n<p>But what about virtual machine backups \u2013&nbsp;proxy-based backups? <\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"900\" height=\"674\" src=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221.jpg\" alt=\"\" class=\"wp-image-7244\" srcset=\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221.jpg 900w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221-300x225.jpg 300w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221-768x575.jpg 768w, https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221-267x200.jpg 267w\" sizes=\"auto, (max-width: 900px) 100vw, 900px\" \/><figcaption>Digging deeper with mminfo for Virtual Machine Backups<\/figcaption><\/figure>\n\n\n\n<p>For those, the default output of mminfo focuses just on telling you the virtual machine was backed up. For example:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[Wed Nov 13 19:10:25]\n [\u2022  ~  \u2022]\n root@orilla \n $ <strong>mminfo -q \"savetime&gt;=3 days ago,level=full,pool=BoostBackup\"<\/strong>\n  volume        client       date      size   level  name\n BoostBackup.002 oaktier.turbamentis.int 11\/11\/19 157 GB full vm:500f1260-a7be-d5cf-0395-761e835a891b:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 12\/11\/19 157 GB full vm:500f1260-a7be-d5cf-0395-761e835a891b:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 11\/11\/19 16 GB full vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 12\/11\/19 16 GB full vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 11\/11\/19 83 GB full vm:500f6743-c531-f607-b47a-b00d26e67d4b:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 12\/11\/19 83 GB full vm:500f6743-c531-f607-b47a-b00d26e67d4b:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 11\/11\/19 574 GB full vm:500fe40e-5be3-28fc-5b57-881485c2a897:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 12\/11\/19 574 GB full vm:500fe40e-5be3-28fc-5b57-881485c2a897:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 11\/11\/19 33 GB full vm:5029e15e-3c9d-18be-a928-16e13839f169:oaktier.turbamentis.int\n BoostBackup.002 oaktier.turbamentis.int 12\/11\/19 33 GB full vm:5029e15e-3c9d-18be-a928-16e13839f169:oaktier.turbamentis.int<\/pre>\n\n\n\n<p>Now, getting the virtual machine ID like that isn&#8217;t particularly helpful, so you can adjust your mminfo query to get the virtual machine name using the &#8216;-k&#8217; option, thusly:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[Wed Nov 13 19:10:40]\n [\u2022  ~  \u2022]\n root@orilla \n $ <strong>mminfo -q \"savetime&gt;=3 days ago,level=full,pool=BoostBackup\" -k<\/strong>\n  volume        type   vm_name         date     time         size ssid      fl backup_size\n BoostBackup.002 Data Domain win01      11\/11\/19 02:00:12  157 GB 1606952444 cr 157 GB\n BoostBackup.002 Data Domain win01      12\/11\/19 02:00:11  157 GB 449410941 cr  157 GB\n BoostBackup.002 Data Domain vulcan     11\/11\/19 02:00:13   16 GB 1590175228 cr  16 GB\n BoostBackup.002 Data Domain vulcan     12\/11\/19 02:00:15   16 GB 382302077 cr   16 GB\n BoostBackup.002 Data Domain test01     11\/11\/19 02:00:11   83 GB 1623729660 cr  83 GB\n BoostBackup.002 Data Domain test01     12\/11\/19 02:00:14   83 GB 399079293 cr   83 GB\n BoostBackup.002 Data Domain andoria    11\/11\/19 02:00:14  574 GB 1573398012 cr 574 GB\n BoostBackup.002 Data Domain andoria    12\/11\/19 02:00:12  574 GB 432633725 cr  574 GB\n BoostBackup.002 Data Domain krell      11\/11\/19 02:00:15   33 GB 1556620796 cr  33 GB\n BoostBackup.002 Data Domain krell      12\/11\/19 02:00:13   33 GB 415856509 cr   33 GB<\/pre>\n\n\n\n<p>That makes it more readable, for sure \u2013&nbsp;but what if you want to know, using mminfo, what virtual disks were actually backed up? Well, for that, &#8216;-S&#8217; is your friend.<\/p>\n\n\n\n<p>The &#8220;mminfo -S&#8221; invocation allows you to drill down and see <em>a lot<\/em> 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 <a rel=\"noreferrer noopener\" aria-label=\"dependencies between PSS savesets (opens in a new tab)\" href=\"https:\/\/nsrd.info\/blog\/2019\/03\/20\/basics-determining-pss-saveset-dependencies\/\" target=\"_blank\"><strong>dependencies between PSS savesets<\/strong><\/a>.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>To give you an example, let&#8217;s first pick a saveset. Now, I could use the &#8216;-k&#8217; option in mminfo again, but the other way we can get the virtual machine name is to use a report option of <em>vmname<\/em>. So let&#8217;s start by finding my virtual machine backups generated in the last 3 days:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[Wed Nov 13 19:20:06]\n [\u2022  ~  \u2022]\n root@orilla \n $ <strong>mminfo -q \"pool=BoostBackup,level=full,savetime&gt;=3 days ago\" -r \"vmname,savetime,ssid\"<\/strong>\n  vm_name    date   ssid\n win01      11\/11\/19 1606952444\n win01      12\/11\/19 449410941\n vulcan     11\/11\/19 1590175228\n vulcan     12\/11\/19 382302077\n test01     11\/11\/19 1623729660\n test01     12\/11\/19 399079293\n andoria    11\/11\/19 1573398012\n andoria    12\/11\/19 432633725\n krell      11\/11\/19 1556620796\n krell      12\/11\/19 415856509<\/pre>\n\n\n\n<p><em>(In this case, in my lab, I usually only backup virtual machines to my DDVE, since it&#8217;s the free 0.5TB version. If someone wants to send me a DD9900 to use, I&#8217;ll gladly send all backups to that and even argue with my husband about where it&#8217;ll fit in our garage&#8230;)<\/em><\/p>\n\n\n\n<p>Now, let&#8217;s say I want to see more details about what was the virtual machine &#8216;vulcan&#8217; contained during the most recent backup. To do that, I&#8217;d run mminfo -S against the saveset generated on 12 November 2019, and that command and output would look like the following:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[Wed Nov 13 19:21:41]\n [\u2022  ~  \u2022]\n root@orilla \n<strong> $ mminfo -S -q \"ssid=382302077\"<\/strong>\n ssid=382302077 savetime=12\/11\/19 02:00:15 (1573484415) oaktier.turbamentis.int:vm:500f21cd-5865-dc0d-7fe5-9b93fad1a059:oaktier.turbamentis.int\n   level=full   sflags=vrF      size=17196675068  files=1          insert=12\/11\/19\n   create=12\/11\/19 complete=12\/11\/19 browse=12\/02\/20 23:59:59 retent=12\/02\/20 23:59:59\n   clientid=82880f28-00000004-5cc29a5e-5cc29a5d-00015000-9f778f56\n          **backup start time: 1573484415;\n               *backup_device: Data Domain;\n                 *backup_mode: VSS;\n          *policy action name: \"backup: 1573484412\", \"clone: 1573485492\";\n                 *policy name: \"VMware: 1573484412 1573485492\";\n        *policy workflow name: \"Virtual Machines: 1573484412\", \n                               \"Virtual Machines: 1573485492\";\n *policy_workflow_action_path: \/VMware\/Virtual Machines\/backup;\n <strong><em>             *proxy_hostname: hanko.turbamentis.int;<\/em><\/strong>\n *ss data domain backup cloneid: 1573484412;\n *ss data domain dedup statistics: \"v1:1573484412:17195263820:14789:10382\", \n                               \"v1:1573485492:17187582892:7905216:7674846\";\n              *SSID directory: Yes;\n<strong><em>            *vcenter_hostname: oaktier.turbamentis.int;\n             *vm_backup_level: incr;\n                     *vm_info: \\\n \"{\n   \\\"name\\\": \\\"vulcan\\\",\n   \\\"host-name\\\": \\\"\\\",\n   \\\"ip-address\\\": \\\"\\\",\n   \\\"template\\\": false,\n   \\\"moref-id\\\": \\\"vm-58\\\",\n   \\\"vcenter-name\\\": \\\"oaktier.turbamentis.int\\\",\n   \\\"path\\\": \\\"\/home\/kobol.turbamentis.int\/vulcan\\\",\n   \\\"moref-path\\\": \\\"\/datacenter-21\/domain-s26\/vm-58\\\",\n   \\\"vm-path\\\": \\\"\/home\/vulcan\\\",\n   \\\"moref-vm-path\\\": \\\"\/datacenter-21\/vm-58\\\",\n   \\\"datastore\\\": \\\"datastore2-samsung-ssd\\\",\n   \\\"datastore-moref\\\": \\\"datastore-31\\\",\n   \\\"os-identifier\\\": \\\"centos64Guest\\\",\n   \\\"os-name\\\": \\\"CentOS 4\/5 or later (64-bit)\\\",\n   \\\"version\\\": \\\"vmx-08\\\",\n   \\\"change-version\\\": \\\"2019-04-26T05:15:52.859306Z\\\",\n   \\\"esxi-moref\\\": \\\"host-28\\\",\n   \\\"esxi-name\\\": \\\"kobol.turbamentis.int\\\",\n   \\\"datacenter\\\": \\\"datacenter-21\\\",\n   \\\"compute-resource\\\": \\\"domain-s26\\\",\n   \\\"cluster-compute-resource\\\": \\\"\\\",\n   \\\"networks\\\": [\n     \\\"VM Network\\\"\n   ],\n   \\\"disks\\\": [\n     {\n       \\\"display-name\\\": \\\"Hard disk 1\\\",\n       \\\"datastore\\\": \\\"datastore2-samsung-ssd\\\",\n       \\\"datastore-moref\\\": \\\"datastore-31\\\",\n       \\\"disk-key\\\": 2000,\n       \\\"size-kb\\\": 16777216,\n       \\\"thin\\\": true,\n       \\\"disk_stats\\\": {\n         \\\"Statistics\\\": {\n           \\\"ProvisionedBytes\\\": 17179869184,\n           \\\"UsedBytes\\\": 7701463040,\n           \\\"ChangedBytes\\\": 0,\n           \\\"SecondsTaken\\\": 0\n         },\n         \\\"DDStatistics\\\": {\n           \\\"PreClientCompBytes\\\": 0,\n           \\\"PostClientCompBytes\\\": 0,\n           \\\"TotalSegments\\\": 0,\n           \\\"RedundantSegments\\\": 0\n         },\n         \\\"BaseFileName\\\": \\\"\\\"\n       }\n     }\n   ]\n }\";\n                     *vm_name: vulcan;\n                     *vm_uuid: 500f21cd-5865-dc0d-7fe5-9b93fad1a059;\n<\/em><\/strong>                        group: VMware_Virtual Machines;\n             saveset features: CLIENT_SAVETIME;\n   Clone #1: cloneid=1573484412  time=12\/11\/19 02:00:12    retent=12\/02\/20  flags=\n     frag@         0 volid=3497323266 file\/rec=       0\/0     rn=0 last=12\/11\/19\n   Clone #2: cloneid=1573485492  time=12\/11\/19 02:18:12    retent=12\/01\/20  flags=\n     frag@         0 volid=3679897583 file\/rec=       0\/0     rn=0 last=12\/11\/19<\/pre>\n\n\n\n<p>I&#8217;ve used <strong><em>bold\/italics<\/em><\/strong> in the output above to highlight the virtual-machine specific details produced by mminfo -S. You&#8217;ll see if you scan through that it tells us:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>What proxy was used to back it up<\/li><li>The vCenter it belonged to<\/li><li>Whether it was a full or incremental backup (a scheduled incremental is generated as a virtual synthetic full, though \u2013&nbsp;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)<\/li><li>A whole bunch of nitty-gritty VM details, including:<ul><li>What ESX server it was on, and its path<\/li><li>What network the VM was on<\/li><li>What the virtual machine type was<\/li><li>What version the virtual machine was<\/li><li>For each disk, details about virtual disk provisioning, size, etc.<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>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&#8217;ve wanted to Python first to tackle it, and I&#8217;m only just getting to that now), but if you&#8217;re not yet ready to dive into the REST API, you can see that it&#8217;s equally there for you using <strong>mminfo<\/strong>, too.<\/p>\n\n\n\n<p>So there you have it \u2013 how to pull detailed information from mminfo about virtual machine backups.<\/p>\n\n\n\n<p><strong><em>[Edit &#8211; 2019-11-14]<\/em><\/strong><\/p>\n\n\n\n<p><em>Per Uwe&#8217;s comments, the REST API doesn&#8217;t provide this level of detail at this point. Also, the disk details are limited to the first four disks \u2013\u00a0I suspect this will be explicitly related to a maximum record size within the media database.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>When you perform an agent-based backup, mminfo will give you a saveset-by-saveset breakdown of what was protected. For filesystem backups,&hellip;<\/p>\n","protected":false},"author":1,"featured_media":7244,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6,16,1357],"tags":[594],"class_list":["post-8493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-basics","category-networker","category-vproxy","tag-mminfo"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2018\/11\/img_0221.jpg","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-2cZ","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/8493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=8493"}],"version-history":[{"count":2,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/8493\/revisions"}],"predecessor-version":[{"id":8495,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/8493\/revisions\/8495"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media\/7244"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=8493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=8493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=8493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}