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.
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.
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.
I have fighting a situation where we have 7 year retention with a equal browse time of every single backup in the environment executed on the end of the month… this has lead to index mount point size breaking a 1/2TB in size and is becoming very unmanageable. I think I have convinced management that 7 years of browsing is stupid & prohibitive. Anything older than 90 days can be a saveset recovery with browse time limited.
Doing a mass prune of the browse time would be ideal. Say… browse time = 90 days or so. If I do a mass nsrmm -S -w “last week” from ssids older than 90 days, would that expire out all the old CFIs and free up space or am I approaching this in an entirely wrong direction?
Apologies for the slow reply – I had some comments erroneously tagged as spam.
To be honest, I’d recommend that you appropriately expand your index region – disk is cheap, after all, and the time taken to scan in old backups in order to be able to do file level recovery, or recover entire savesets and dig through them quickly outweighs the cost of storage.
That being said if you do decide to expunge old indices in order to do it right you’ll need to process each saveset individually – inspect its savetime by mminfo, do a date calculation and then update it with a new expiration date.
Alternatively if all you want to do is expunge all indices after a certain date, then generate a list of all the savesets older than X days (e.g., “mminfo -q “savetimeless than rather than greater than, since you’re comparing against seconds since 1970 at the back-end). Then once you’ve got that list you can simply do loop along the lines of:
for ssid in `ssid-list.txt`
do
nsrmm -y -w today $ssid
done
Which would set the browse time for specific saveset to today – the next day you’d be able to do an nsrim -X to fully expunge.
You could *try* setting the browse time to “yesterday”, but I’m fairly certain you can’t set it to a date in the past.