NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).

  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
«
»

Basics – mminfo, savetime and greater than/less than

Posted by Preston on 2009-02-01

Hi!

The text of this article should be read over at the NetWorker Information Hub.

This entry was posted on 2009-02-01 at 10:03 and is filed under NetWorker, Scripting. Tagged: , , . You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

4 Responses to “Basics – mminfo, savetime and greater than/less than”

  1. Top 5 Reflections « NetWorker Blog said

    2009-07-17 at 08:22

    […] 4 was Basics – mminfo, savetime and greater than/less than. Now, I’m not going to pretend that every person who visited that article was looking for […]

  2. Brett said

    2009-11-25 at 08:48

    Great blog. Lots of good technical networker info. Thanks!
    Where is “ago” as in “2 weeks ago” documented? I certainly didn’t see it in nsr_getdate(3).
    I believe nsr_getdate mentions relative time is [number] unit.

    There also seems to be a difference in the below queries
    mminfo -q “pool=pool1, savetime<4 week"
    mminfo -q "pool=pool1, savetime<4 week ago"

    • Preston said

      2009-11-25 at 09:02

      Hi Brett,

      It’s certainly referenced in the mminfo documentation; if you check that, you’ll notice it used multiple times in the examples given.

      As to the discrepancy you encountered – I’d been using “ago” for so long now that I’ve not run the alternative for years.

      Doing a few basic tests, it appears to me that “savetime<X week" actually gets ignored by NetWorker. E.g., here's what I got from:

      [root@nox ~]# mminfo -q “pool=Staging,savetime<3 week" -otR | head -5
 volume        client       date      size   level  name
Staging-01.RO  nox              11/25/2009 38 MB 9  index:archon
Staging-01     nox              11/25/2009 38 MB 9  index:archon
Staging-03.RO  archon    11/25/2009   4  B    incr  /Volumes/TARDIS/Yojimbo
Staging-03     archon    11/25/2009   4  B    incr  /Volumes/TARDIS/Yojimbo

      That’s clearly (as of the time I write this reply) from today. However, if I run it with the “3 weeks ago”, I get what I should get:

      [root@nox ~]# mminfo -q “pool=Staging,savetime<3 weeks ago" -otR | head -5
 volume        client       date      size   level  name
Staging-01.RO  loki      11/04/2009 497 KB    incr  /
Staging-01     loki      11/04/2009 497 KB    incr  /
Staging-01.RO  loki      11/04/2009   4  B    incr  /boot
Staging-01     loki      11/04/2009   4  B    incr  /boot

      So it looks to me that we have an instance of mminfo interpreting “3 week ago” differently to what we’d expect (I.e., it’s coming back as “now”, somehow), but “3 weeks ago” is the correct invocation.

      Cheers,

      Preston.

  3. Brett said

    2009-11-25 at 11:40

    Hi Preston!
    From some testing I did, it looks like “3 week” will be converted to a time 3 weeks in the future of the current time while “3 week ago” will be converted to a time 3 weeks in the past of the current time.
    I still think “ago” should be documented in the nsr_getdate(3) man page. A couple of examples in the mminfo(1m) man page isn’t documentation. Even the mminfo man page says time attributes are specified in nsr_getdate(3)

    Regards,

    brett

Sorry, the comment form is closed at this time.

«
»