{"id":7983,"date":"2019-03-20T11:20:12","date_gmt":"2019-03-20T01:20:12","guid":{"rendered":"https:\/\/nsrd.info\/blog\/?p=7983"},"modified":"2019-03-20T11:20:20","modified_gmt":"2019-03-20T01:20:20","slug":"basics-determining-pss-saveset-dependencies","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2019\/03\/20\/basics-determining-pss-saveset-dependencies\/","title":{"rendered":"Basics \u2013\u00a0Determining PSS Saveset Dependencies"},"content":{"rendered":"\n

A question I’ve been asked a few times is “how do we use mminfo to determine dependencies between PSS savesets?”<\/em><\/p>\n\n\n\n

When we do a Parallel Save Stream (PSS) saveset, NetWorker breaks down the saveset into multiple streams and names them using the old method used back in NetWorker v5.x\/etc. days for continuation savesets. Back in those days, NetWorker used a cut-off limit of 2GB when writing a saveset, so if you needed to backup a 5GB filesystem called ‘\/home’, you’d get saveset names of:<\/p>\n\n\n\n

\/home
<1>\/home
<2>\/home
<\/pre>\n\n\n\n
Now, we don’t need to do those continuation savesets any more, so the nomenclature gets used for identifying PSS savesets. If you go to recover from a PSS backup, NetWorker automatically uses the various PSS savesets that were generated, and it handles recycling them appropriately \u2013 i.e., it doesn’t think that \/home and <1>\/home are different savesets, as such.<\/p>\n\n\n\n
But how?<\/p>\n\n\n\n
\"\"
Taking a closer look at PSS details using mminfo<\/strong><\/figcaption><\/figure>\n\n\n\n
My first thought when I was asked this was that given we were using continuation saveset nomenclature, it would be as easy as chaining via a “pssid” option in mminfo. However, that’s not the case, so I did some more digging and found out how we get this information out of mminfo. (Thanks, Matt, Kumar, Pavan!)<\/p>\n\n\n\n
So, let’s start with an example of a PSS backup I generate in my lab of a saveset, “\/Volumes\/Documents\/Alteran<\/strong>” on the host rama<\/strong>.<\/p>\n\n\n\n
$ mminfo -q \"client=rama.turbamentis.int,name=\/Volumes\/Alteran\/Documents,level=full,savetime>=3 weeks ago\"<\/strong>
  volume        client       date      size   level  name
 Backup.03      rama.turbamentis.int 03\/03\/19 515 GB full \/Volumes\/Alteran\/Documents
<\/pre>\n\n\n\n
That’s our starting point. The next thing is to work out what the saveset ID is so we can do a bit more digging, so our query becomes:<\/p>\n\n\n\n
$ mminfo -q \"client=rama.turbamentis.int,name=\/Volumes\/Alteran\/Documents,level=full,savetime>=3 weeks ago\" -r ssid<\/strong>
 3178921591
<\/pre>\n\n\n\n
The saveset ID helps here because we’re going to use the “super verbose mode” option in mminfo, -S. Now you’ll note I’m deliberately querying based on the core saveset name. This is effectively the ‘parent’ for the saveset. So, my new query based on saveset ID and focusing on the super verbose output is:<\/p>\n\n\n\n
$ mminfo -S -q \"ssid=3178921591\"<\/strong>
 ssid=3178921591 savetime=03\/03\/19 00:00:35 (1551531635) rama.turbamentis.int:\/Volumes\/Alteran\/Documents
   level=full   sflags=vF       size=528098212924 files=10282      insert=03\/03\/19
   create=03\/03\/19 complete=03\/03\/19 browse=03\/04\/19 23:59:59 retent=03\/04\/19 23:59:59
   clientid=c7237fcb-00000004-58eb5ef3-58eb5ef2-00375000-9f778f56
           *backup start time: 1551531632;
     *mbs anchor saveset time: 1551531632;
              *mbs dependents: \\
 4d303631-00000006-be7a7e75-5c7a7e75-01435000-9f778f56, 
 0142dba6-00000006-bf7a7e75-5c7a7e75-01425000-9f778f56, 
 5d1f8601-00000006-c07a7e75-5c7a7e75-01415000-9f778f56;<\/em>
         *policy action jobid: 1729123;
          *policy action name: \"backup: 1551531635\";
                 *policy name: \"Platinum: 1551531635\";
        *policy workflow name: \"Documents: 1551531635\";
                        group: Platinum_Documents;
             saveset features: CLIENT_SAVETIME;
   Clone #1: cloneid=1551531635  time=03\/03\/19 00:00:35    retent=03\/04\/19  flags=
     frag@         0 volid=3844106399 file\/rec=       0\/0     rn=0 last=03\/03\/19
<\/pre>\n\n\n\n
I’ve italicised the output you want to look for in this scenario: you’ll see a section of the output called “mbs dependents” – these are the <x>Name savesets that are associated with the core saveset we queries from. If you’re not familiar with that lengthy hexadecimal string format, it’s what we refer to as the “long SSID”; in actual fact, you can get the long SSID for any saveset just by giving a length attribute to the ssid output field:<\/p>\n\n\n\n
$ mminfo -q \"client=rama.turbamentis.int,name=\/Volumes\/Alteran\/Documents,level=full,savetime>=3 weeks ago\" -r \"ssid,ssid(53)\"<\/strong>
  ssid      ssid
 3178921591 79eeaeec-00000006-bd7a7e77-5c7a7e77-01445000-9f778f56
<\/pre>\n\n\n\n
The long SSID is useful not only in this case for us to do the tracing of dependent saveset sections, but also if you’re using an advanced file type device, you’ll actually find<\/em> the saveset on disk using that filename.<\/p>\n\n\n\n
You can also query based on the long SSID as well, so in this case now I’ve got the details of the ‘mbs dependents’, I can query any one of those to find out their specific details as follows:<\/p>\n\n\n\n
$ mminfo -S -q \"ssid=4d303631-00000006-be7a7e75-5c7a7e75-01435000-9f778f56\"<\/strong>
 ssid=3195698805 savetime=03\/03\/19 00:00:34 (1551531634) rama.turbamentis.int:<3>\/Volumes\/Alteran\/Documents
   level=full   sflags=vF       size=554835612580 files=3896       insert=03\/03\/19
   create=03\/03\/19 complete=03\/03\/19 browse=03\/04\/19 23:59:59 retent=03\/04\/19 23:59:59
   clientid=c7237fcb-00000004-58eb5ef3-58eb5ef2-00375000-9f778f56
           *backup start time: 1551531632;
              *mbs dependents: \/Volumes\/Alteran\/Documents;
         *policy action jobid: 1729123;
          *policy action name: \"backup: 1551531632\";
                 *policy name: \"Platinum: 1551531632\";
        *policy workflow name: \"Documents: 1551531632\";
                        group: Platinum_Documents;
             saveset features: CLIENT_SAVETIME;
   Clone #1: cloneid=1551531632  time=03\/03\/19 00:00:32    retent=03\/04\/19  flags=
     frag@         0 volid=3844106399 file\/rec=       0\/0     rn=0 last=03\/03\/19
<\/pre>\n\n\n\n
You’ll notice in this output, as a child<\/em> PSS entry, the mbs dependents<\/em> simply gives the parent saveset name.<\/p>\n\n\n\n
So, how can you use this in scripting? Well below, you’ll find a very<\/em> rough and ready Perl script that builds a view of the dependent details for a PSS saveset. I can guarantee the following is not<\/em><\/strong> in this script:<\/p>\n\n\n\n
  • Any form of error checking<\/li>
  • Handling Windows saveset names<\/li>
  • Handling different pools<\/li><\/ul>\n\n\n\n
    The script has to be run on the NetWorker backup server at the moment, using the arguments “-c clientName” and “-n savesetName” where the saveset name is obviously the name of the base PSS saveset. So in this case, running for my client of “rama<\/strong>” and a saveset name of “\/Volumes\/Alteran\/Documents<\/strong>“, I got output such as the following:<\/p>\n\n\n\n
    $ .\/pss-dependents.pl -c rama -n \/Volumes\/Alteran\/Documents<\/strong>
     rama:\/Volumes\/Alteran\/Documents @ 03\/02\/19
         Level = full, Size = 508 GB, SSID = 3528823916
             3545601131 <3>\/Volumes\/Alteran\/Documents (533 GB)
             3579155563 <2>\/Volumes\/Alteran\/Documents (568 GB)
             3562378347 <1>\/Volumes\/Alteran\/Documents (548 GB)

     rama:\/Volumes\/Alteran\/Documents @ 17\/02\/19
         Level = 1, Size = 4  B, SSID = 896010610
             929565040 <3>\/Volumes\/Alteran\/Documents (4  B)
             946342256 <2>\/Volumes\/Alteran\/Documents (4  B)
             912787824 <1>\/Volumes\/Alteran\/Documents (4  B)

     rama:\/Volumes\/Alteran\/Documents @ 18\/02\/19
         Level = incr, Size = 105 MB, SSID = 3765000946
             3781778159 <3>\/Volumes\/Alteran\/Documents (119 MB)
             3798555375 <2>\/Volumes\/Alteran\/Documents (115 MB)
             3815332591 <1>\/Volumes\/Alteran\/Documents (106 MB)

     rama:\/Volumes\/Alteran\/Documents @ 19\/02\/19
         Level = incr, Size = 4  B, SSID = 2339023986
             2355801200 <3>\/Volumes\/Alteran\/Documents (4  B)
             2372578416 <2>\/Volumes\/Alteran\/Documents (4  B)
             2389355632 <1>\/Volumes\/Alteran\/Documents (4  B)

     rama:\/Volumes\/Alteran\/Documents @ 20\/02\/19
         Level = incr, Size = 4  B, SSID = 913047026
             963378672 <3>\/Volumes\/Alteran\/Documents (4  B)
             946601456 <2>\/Volumes\/Alteran\/Documents (4  B)
             929824240 <1>\/Volumes\/Alteran\/Documents (4  B)<\/pre>\n\n\n\n
    (Abridged, there was a chunk more output.)<\/p>\n\n\n\n
    The output is sorted by nsavetime<\/em> for the core PSS saveset name, so you’ll get a rough view of the chaining of the saveset by dependencies. <\/p>\n\n\n\n
    $ cat pss-dependents.pl | awk '{gsub(\"\\t\",\"    \");print}' -<\/strong>
     #!\/usr\/bin\/perl -w
     
     use strict;
     use Getopt::Std;

     my %opts;
     my $client = \"none\";
     my $name = \"none\";
     if (getopts('c:n:',\\%opts)) {
         if (defined($opts{c})) {
             $client = $opts{c};
         } else {
             die \"You must supply a client name (-c client)\\n\";
         }
         if (defined($opts{n})) {
             $name = $opts{n};
         } else {
             die \"You must supply a saveset name (-n name)\\n\";
         }
     }

     my %ssids = ();
     my $mminfo = \"mminfo -q \\\"client=$client,name=$name\\\" -r ssid,nsavetime,savetime,level,sumsize -xc,\";
     if (open(MMI,\"$mminfo 2>&1 |\")) {
         while (<MMI>) {
             my $line = $_;
             next if ($line =~ \/ssid\/);
             chomp $line;
             my ($ssid,$nsavetime,$savetime,$level,$sumsize) = (split(\/\\,\/,$line))[0,1,2,3,4];
             $ssids{$nsavetime}{ssid} = $ssid;
             $ssids{$nsavetime}{level} = $level;
             $ssids{$nsavetime}{savetime} = $savetime;
             $ssids{$nsavetime}{sumsize} = $sumsize;
         }
         close(MMI);
     }

     foreach my $nsavetime (sort {$a <=> $b} keys %ssids) {
         my $savetime = $ssids{$nsavetime}{savetime};
         my $level = $ssids{$nsavetime}{level};
         my $ssid = $ssids{$nsavetime}{ssid};
         my $sumsize = $ssids{$nsavetime}{sumsize};
         print \"$client:$name @ $savetime\\n\";
         print \"\\tLevel = $level, Size = $sumsize, SSID = $ssid\\n\";

         my $mminfoVerbose = \"mminfo -q \\\"ssid=$ssid\\\" -S\";
         $\/ = \";\\n\";
         my @dependents = ();
         if (open(MMI,\"$mminfoVerbose 2>&1 |\")) {
             while (<MMI>) {
                 my $line = $_;
                 chomp $line;
                 if ($line =~ \/^\\s+\\*mbs dependents:\\s\\\\\\n(.*)$\/s) {
                     my $deps = $1;
                     @dependents = split(\/\\,\\s*\/,$deps);
                     #foreach my $dep (@dependents) {
                     #    print \"\\t$dep\\n\";
                     #}
                 }
             }
             close(MMI);
         }
         $\/ = \"\\n\";
         foreach my $dep (@dependents) {
             if (open(MMI,\"mminfo -q \\\"ssid=$dep\\\" -r ssid,name,sumsize -xc, 2>&1 |\")) {
                 while (<MMI>) {
                     my $line = $_;
                     chomp $line;
                     next if ($line =~ \/ssid\/);
                     my ($dSSID,$dName,$dSumsize) = (split(\/\\,\/,$line))[0,1,2];
                     print \"\\t\\t$dSSID $dName ($dSumsize)\\n\";
                 }
                 close(MMI);
             }
         }
         print \"\\n\";
     }
     
    <\/pre>\n\n\n\n
    So there you have it \u2013 pulling out details from NetWorker for the parallel savesets created in a PSS operation.<\/p>\n","protected":false},"excerpt":{"rendered":"
    A question I’ve been asked a few times is “how do we use mminfo to determine dependencies between PSS savesets?”…<\/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],"tags":[594,1249,1192],"class_list":["post-7983","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-basics","category-networker","tag-mminfo","tag-networker","tag-pss"],"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-24L","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7983","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=7983"}],"version-history":[{"count":5,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7983\/revisions"}],"predecessor-version":[{"id":7988,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/7983\/revisions\/7988"}],"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=7983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=7983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=7983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}