networker + NAS backups

There are two things which could effect savesets remaining on a AFTD. One is when nsrim is run and the other the staging. As you have not mentioned staging I don't think this is relevant here.

nsrim -X usually runs once very 24 hours automatically, you can see the last time it was run by looking at the timestamp of a file in the Media Database directory (on windows this would be C:\Program Files\Legato\nsr\mm by default). called nsrim.prv. If it is running at a busy time for your server you can change the time by either touching the file or by manually running at a quiet time on the NetWorker server.

When nsrim -X runs it marks the savesets which are eligible for recycle and these are then removed from the AFTD volume. If there are savesets which are remaining on the volume for an extended time this could be due to several reasons: -

1. nsrim -X is not being run. It should run at least once every 24 hours as savegrp checks the file and if it is not present or is older than 23 hours nsrim will be initiated.

2. There is some type of dependency which is not allowing the savesets to be marked as recyclable (full for incremental backups etc). Perhaps a full backup failed which is not allowing the cycle to expire as expected? Full backups which are retained for 1 week will actually remain on the volume for nearly 2 as incremental backups which follow (usually retained for the same time period) will only expire after this time and when another full backup has been taken.

3. Retention time is not as expected - for some reason the client retention is set differently to that which you require.

You can check with mminfo selecting level,ssbrowse,ssretent flags (along with other which identify the savesets) this is usually more clear as to if a backup has failed (you will see the full/incr sequence vary) or what the retention time set on the savesets is.

Regards,

Bill Mason

regarding your first point .. i saw that it did run 24 hours ago..

i ran it again .. it did say that it will clear up somethings ..and i saw that some of the NAS will clean up things in the next NAS clean up cycle in a few hours ..

however i was reading networker documentation and  it stated (page 162 - administration guide):

Assigning multiple policies to a single client
Identical versions of a client and save set combination can have a different set of browse and
retention policies assigned for each different backup group to which it belongs. If you create
an identical Client resource with the same name and save set values, but assign it to a
different backup group, you can designate a different set of browse and retention policies.
The NetWorker server employs the Browse Policy and Retention Policy attributes that
correspond to the unique combination of the Client resource’s Name, Save Set, and Group
attributes.

How does one go about doing something like that ? because this is what i really need...

thanks

PS... how can i change the schedule of the nsrim - X ? .. or how can i change the time where it actually cleans up ? .. because the current time (as according to the file) is not very good..

Hello Bill,

some questions:

- are you sure that it is nsrim -X that is run every 24 hours? I thaught it was nsrim -M

-  please help me to find out, if a saveset is recyclable. The only flag I know of is 'E', which is not recyclable but "eligible for recycling".

  how can I check the state 'recyclable' on a saveset? Today I know only how to check it on a volume.

I did some tests in my lab, and it seems to me, that the 'E' flag mentioned above is enough for nsrim to recycle (remove from ftd and aftd volumes) a saveset and much more nsrim in this case does NOT check for dependend incr savesets. These incr savesets are left on the ftd because they are not eligible for recycling, but the level full is removed. Can you confirm?

Volumes become recyclable only after all dependend savesets are eligible for recycling, that works.

Thanx, Holger

OK, lets see if I can answer the questions raised: -

From Original Poster: -

1. Different retention times: All you need to do is copy the existing client definition and change the group, browse, retention attributes, then you will get a backup of the client for the same savesets but initiated by a different group than now. You can have as many client definitions as you like for the same client as long as its linked to a different group. Browse/retention policies can be different (it makes no sense to have the same linked to a different group) to suit the business need Remember the scheduling as you do not want both to run at the same time

2. To alter the time nsrim -X runs just touch the file or manually run it when you want it to run once - this should set the time on the nsrim.prv file and from then on as long as a group runs close to this time you should not see it shift. Its best to run at a quiet time on the NetWorker server as there can be a lot of updates made to the media database/Client file index. A good trick which a lot of people use is to so a backup of the NetWorker server (full or just a small file) which will then trigger savegroup to run the nsrim -X command going forward.

Holger: -

1. Strictly speaking yes, when it is invoked automatically it is nsrim -M which runs, however this is effectively nsrim -X running from nsrd (via savegrp). The end result is really the same apart from the logging and communication. This still sets the time on the nsrim.prv file for future runs/checks.

2. Within mminfo you can look at ssflags which tell you if a saveset is eligible to be recycled. If you look at a saveset which is passed its browse time before nsrim is run you will see the flags would usually be vF (valid, finished), afterwards you should see vrF (r=recoverable). Once retention time is passed and nsrim -X has run you will see flags reported as vrEF (E=eligible for recycling). This is effectively when we have a recyclable saveset, prior to ftd's and AFTD's we would have had to relabel the volume to "recycle", but with the newer devices this is not required as we housekeep in a different way (as we can free up the disk space on these devices, not possible on tape).

3. Once the saveset is eligible for recycling it can be removed, however if there is a dependency it will not be marked with the "E" flag as we cannot remove this until all the dependent savesets (usually incr) are passed their retention time. You may have more incremental backups dependent if the full backup failed than you expect relying on the full backup. Many people think this is a mistake on NetWorker's part and manually remove or relabel the volume as the retention time is passed - this then compromises the later backups which are relying on this full/differential. Inremental's are related to the last full backup and can only be recycled when a newer full backup is completed successfully. Are you sure you have no other full backups in your test environment which could explain the behaviour you are reporting? If the report of your testing is correct then I would raise a support case as incremental savesets should not have their dependent full removed, there is a check made to ensure the full remains available.

There was a bug in earlier NetWorker versions (prior to 7.4.4 I think form memory, but you do not say which version you tested on) where if staging/cloning was involved it could behave like you are reporting but there was a copy of the saveset still available, the original was removed.

Bill Mason