Ever need to adjust the browse/retention time for a saveset, but you’ve not been sure how to do so? Here’s how.
To change the browse or retention time, you’ll need to find out the saveset ID (SSID) of the given saveset. This can be done with mminfo.
For instance, say you had a backup done last night of a machine called ‘archon’ that has now been rebuilt, but you want to keep the old backup for much longer than normal – e.g., ten years instead of the normal 3.
First, to find out what you need to change, get a list of the SSIDs:
# mminfo -q "client=archon,savetime>=24 hours ago" -r name,ssid name ssid / 4036558666 /Volumes/TARDIS/Yojimbo 4019781450 /Volumes/Yu 4003004234
(If you’re confused about that savetime command, see my other post here.)
Now, for each of those SSIDs that are returned, we’ll run a nsrmm command to adjust the browse and retention time*.
The basic nsrmm command for adjusting the browse and retention time is:
# nsrmm -S ssid -w browse -e retent
or, for a single instance of a saveset:
# nsrmm -S ssid/cloneid -w browse -e retent
Where the ‘browse’ and ‘retent’ values can be either one of the two following:
- A literal date in US date format ** – e.g., “12/31/2019″ for 31 December 2019.
- A ‘fuzzy’ english worded date – e.g., “+10 years” for 10 years from today.
Note that (rather obviously), your browse time cannot exceed your retention time, and generally its recommended that you set browse time to retention time.
So in this case, you’d run for each SSID or SSID/CloneID you want to affect:
# nsrmm -S ssid -w "+10 years" -e "+10 years"
Which will look like the following, based on my mminfo output:
# nsrmm -S 4036558666 -w "+10 years" -e "+10 years" # nsrmm -S 4019781450 -w "+10 years" -e "+10 years" # nsrmm -S 4003004234 -w "+10 years" -e "+10 years"
It’s that simple.
–
* You can also do this against an instance of a saveset by using the SSID/Clone ID; to do that variant, request “-r name,ssid,cloneid”, then use the two numbers in the nsrmm command separated by a forward slash – ssid/cloneid.
** The restriction on US date format may have eased in 7.5. I’m going to do some additional playing around with locales sometime soonish.
Related posts:
- Manually Staging? Don’t forget the Clone ID! Something that continues to periodically come up is the need...
- Basics – NetWorker Data Lifecycle Within NetWorker, data (savesets) can go through several stages in...
- Basics – Need a different volume from pool … The scenario: A clone or stage operation has aborted (or...
Related posts brought to you by Yet Another Related Posts Plugin.
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.
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.
[...] 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 [...]
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
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.
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
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.
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.
(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.
[...] 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 [...]
[...] 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 [...]