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.
  • 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).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Basics – Changing saveset browse/retention times

Posted by Preston on 2009-02-16

Hi!

The text of this article has been moved, and can now be found at its permanent home, the NetWorker Information Hub. You can read it here.

Advertisements

10 Responses to “Basics – Changing saveset browse/retention times”

  1. michael said

    Thanks for the great blog.

    BTW, more information is available about the date formats used in NetWorker is well documented in the nsr_getdate man page (or section of the Command Reference).

    For instance you can use decade, year, quarter, month, fortnight, week, day, hour, minute, and second. as units.

    So instead of “10 years”, you could use “120 months” or even “260 fortnights”..

    Conceivably you could also use the keyword “now” if you wanted to expire a saveset now.

    • Preston said

      Hi Michael,

      Thanks for the feedback!

      Yes – there’s a variety of other options available when it comes to date specification – three words I often like are “now”, “yesterday” (more for mminfo) and “tomorrow” – e.g., if I’m doing some testing, I’ll just run save -e tomorrow, etc.

  2. […] would do a post on browse and retention of savesets but Preston beat me to it with this great post here which covers changing the browse and retention times on savesets….. so I would do something […]

  3. vijaysys said

    Hi

    Thanks for the wonderful article. Please let me know, if i get one LTO3 tape from a remote site, what should we do through NetWorker 7.4.4 on restoring of the entire contents of the tape on the Linux NetWorker server.

    Thanks always.

    Al

    • Preston said

      I’m assuming you’re referring to a remote site running another NetWorker server? If so, then assuming you’ve got pools configured on your “local” NetWorker server for the media written to by the “remote” NetWorker server, then all you can scan in the media (using the scanner command) from the remote site to the local site. You’ll likely also need to create client definitions for the clients at the remote site, replicating the client ID’s from the remote site too.

  4. vijaysys said

    Thanks for the idea. so,here pool refers to the “media pool” ? Also, when i get the media from the other site, Is it require to get the Client ID also ? Along with the media what are the other information should i get from the remote site ?

    Thanks

    • Preston said

      Yes, pool refers to the NetWorker media pool; if you want to easily facilitate recovery then yes, you should gather the client ID as well. Alternatively, if you only rarely want to recover, you may find that using scanner in combination with uasm is sufficient – though if you want to recover more than once or twice a year, a scanner/uasm solution perhaps should be avoided.

      If this is something you are intending to routinely do, you may want to script retrieval of client IDs; alternatively, if you’d prefer to avoid scripts, look up the IDATA Tools suite the company I work for produces. The next version, due out at the end of April ’09, includes options to very easily automatically generate reports on clients within the configuration, including the client ID for each client.

  5. ayadav said

    Finally, I got a chance to read your book. Concept wise very will explained. But I have still some doubts about NMO policy uniformity and save set bundling if you can explained..please.

    First let me explain my problem. Browse and retention policies are 1 week. I am doing RMAN level 0(full) on Sunday and level 1(incremental) rest of days. Backup cycle is 1week.

    First problem networker always stored my increamental backup as full and start recycling after 7 days. In fact as you explain in your book, 1st full backup should be retained untill 14 days (browse + backup cycle) passed. In my schedule cycle in netwoker,I defined Sun as FULL and rest of day as INCR. To me its look like because incremental save set marked as FULL and thats why networker start recycling them after 1 week even though these are incremental backup.

    I did tried to turned on NMO policy uniformity and save set bundling. Still no luck…

    Second question, what policy uniformity does? As per my understand, Policy uniformity ensures that incremental backups do not persist after the backups they depend on have expired. I have enabled the parameter NSR_INCR_EXPIRATION. But still 1st day full backup marked as recycle after 7 days. I am not sure whether this is right parameter to take care or I need to turn on save set bundling?

    Third question, what does save set bundling does? Can you please explin in simple words? NMO documents have not done a good job explaining these term or May be I am not not getting what they want to say.

    • Preston said

      (For the record, I don’t think the browse/retention time post is appropriate for these questions about RMAN backups.)

      My understanding is that without save set bundling, you won’t get correct dependency tracking on Oracle RMAN backups. These are always more challenging to organise dependency tracking for than the regular filesystem backups (or for that matter, some of other other ‘simpler’ modules.)

      Over the next month or two I plan to do a lot more testing with the Oracle module and get up to speed with the enhancements that have been made in more recent modules, i.e., going above and beyond just standard “fulls every day” style backups. Most of my customers stick with daily full backups due to the sizes of their individual Oracle databases, but it’s time I refreshed myself on the ins and outs of Oracle incremental and differential backups.

      So watch out for new entries coming in a few weeks (presuming I don’t get diverted) on those very topics.

      Cheers.

  6. […] 3 on the list is Basics – Changing saveset browse/retention times. As regularly as possible I try to check the search strings that have brought people to my blog (as […]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: