Welcome! » Log In » Create A New Profile

Some more questions on indexes

Posted by George Sinclair - NOAA Federal 
George Sinclair - NOAA Federal
Some more questions on indexes
September 29, 2017 04:59PM
Some more questions here on indexes because I'm not 100% confident that
I have this right, even after reading the sundry man pages.

1. When you run:

nsrck -L7 -t date client

we're not saying that it makes the index look solely the way it did as
of that time since you'd obviously lose any data added since then. We're
instead saying that
everything that was in the index as of that time will now be merged into
the current index, unless it's already in there, in which case it's
skipped? Is this correct?

2. For the following schedule: Sun=full, Mon-Sat=incr.

since incremental backups of indexes are really level 9s, then we'd
expect that each subsequent incremental would be >= to the previous
level 9, assuming
nothing was removed in the interim; or if so, that it was less than what
was added. That right?

3. So if my *entire* index goes away, and I run these two commands after
the Saturday backup:

nsrck -L7 -t Sunday_date client
nsrck -L7 -t Saturday_date client

then would this yield the same result as if I had only run this command? :

nsrck -L7 -t Saturday_date client

In other words, -L7 does not recover just what was added on that day
like a save set recover for a non-index save set, correct? It must also
go back to the
previous full. So if the full from Sunday was on volume 1, and the 9
from Saturday was on volume 2 then it will read from both and reassemble
everything
the way it looked following Saturday's backup.

Clearly, however, if I only ran this:

nsrck -L7 -t Sunday_date client

then I would only have what existed as of Sunday (the previous full),
and this would not be up to date. I would still need to run an nsrck -L7
for Saturday in order
to merge in everything that the level 9 from Saturday captured, right?

4. If you need to completely recover an index, and you don't have a
directory entry (e.g. /nsr/index/client_name), but at least one NSR
client resource still exists,
then is it necessary to 1. simply create the empty directory before
running nsrck -L7, 2. first run nsrck with some other level in order to
create the
index header, or 3. the creation of the directory will happen
automatically with -L7, as necessary?

5. You cannot recover solely what was backed up in the index from a
level 9 without NetWorker also reading through the previous full since
1. the level 9 is
dependent on the full, and 2. it has no way of knowing that there might
not be something on that full that your current index is missing. Is
that true?

So in theory, the only way to do something like that, wherein you want
to avoid it reading through the full because you know there's nothing in
there
that you don't already have in the index, would be to use scanner and
uasm somehow, but this is not a supported method for index recovery,
correct?
Maybe? Hmm ...

George

--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Dag Nygren
Re: Some more questions on indexes
September 29, 2017 11:59PM
On Friday 29 September 2017 19:25:47 you wrote:
> Some more questions here on indexes because I'm not 100% confident that
> I have this right, even after reading the sundry man pages.
>
> 1. When you run:
>
> nsrck -L7 -t date client
>
> we're not saying that it makes the index look solely the way it did as
> of that time since you'd obviously lose any data added since then. We're
> instead saying that
> everything that was in the index as of that time will now be merged into
> the current index, unless it's already in there, in which case it's
> skipped? Is this correct?

That's correct.

> 2. For the following schedule: Sun=full, Mon-Sat=incr.
>
> since incremental backups of indexes are really level 9s, then we'd
> expect that each subsequent incremental would be >= to the previous
> level 9, assuming
> nothing was removed in the interim; or if so, that it was less than what
> was added. That right?

Yep. It is a deifferential backup.

> 3. So if my *entire* index goes away, and I run these two commands after
> the Saturday backup:
>
> nsrck -L7 -t Sunday_date client
> nsrck -L7 -t Saturday_date client
>
> then would this yield the same result as if I had only run this command? :
>
> nsrck -L7 -t Saturday_date client
>
> In other words, -L7 does not recover just what was added on that day
> like a save set recover for a non-index save set, correct? It must also
> go back to the
> previous full. So if the full from Sunday was on volume 1, and the 9
> from Saturday was on volume 2 then it will read from both and reassemble
> everything
> the way it looked following Saturday's backup.
>
> Clearly, however, if I only ran this:
>
> nsrck -L7 -t Sunday_date client
>
> then I would only have what existed as of Sunday (the previous full),
> and this would not be up to date. I would still need to run an nsrck -L7
> for Saturday in order
> to merge in everything that the level 9 from Saturday captured, right?

Not really. nsrck -L7 takes care of this for you and will execute both
recovers in the latter case. So you do not need to worry about
levels - Just time of recovery.

> 4. If you need to completely recover an index, and you don't have a
> directory entry (e.g. /nsr/index/client_name), but at least one NSR
> client resource still exists,
> then is it necessary to 1. simply create the empty directory before
> running nsrck -L7, 2. first run nsrck with some other level in order to
> create the
> index header, or 3. the creation of the directory will happen
> automatically with -L7, as necessary?

The recover done by nsrck -L7 will recreate everything needed for you.

> 5. You cannot recover solely what was backed up in the index from a
> level 9 without NetWorker also reading through the previous full since
> 1. the level 9 is
> dependent on the full, and 2. it has no way of knowing that there might
> not be something on that full that your current index is missing. Is
> that true?

Not only reading through - Also recovering.

> So in theory, the only way to do something like that, wherein you want
> to avoid it reading through the full because you know there's nothing in
> there
> that you don't already have in the index, would be to use scanner and
> uasm somehow, but this is not a supported method for index recovery,
> correct?

Maybe. At least in the early days you could do a standard
saveset recover of the backup level9 saveset and just nsrck -L6
to recreate the pointer and header info, but I think he will tell
you today at the recover stage that you are supposed to use nsrck -L7 ...
Scanner -i of the saveset will of course enter the info though.


Best
Dag


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Dag Nygren
Re: Some more questions on indexes
September 30, 2017 12:59AM
The only gotcha's with nsrck -L7 I have ran in to are:

1. The size of the index directory will if the saveset is old enough
grow quite a lot as everything that was in the then is merged with
the current contents.

2. There was for a long time a bug in the process where the recovered
saveset index info would almost immediately be cleaned out again by nsrim
if it had passed it's retention/browse time. The cure was changing
the browse and/or retention time _before_ doing the nsrck -L7.
The way it is supposed to work is that the browse time should
auto-extend to "<the original browse policy> + <index recover time>"
and that should take care of the problem. But as I said this didn't
happen. And I am not sure it is fixed/changed even now...

Best
Dag


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Re: Some more questions on indexes
October 02, 2017 10:00AM
On 2017-09-30 03:06, Dag Nygren wrote:
> The only gotcha's with nsrck -L7 I have ran in to are:
>
> 1. The size of the index directory will if the saveset is old enough
> grow quite a lot as everything that was in the then is merged with
> the current contents.
Got it.
>
> 2. There was for a long time a bug in the process where the recovered
> saveset index info would almost immediately be cleaned out again by nsrim
> if it had passed it's retention/browse time. The cure was changing
> the browse and/or retention time _before_ doing the nsrck -L7.
I've seen a similar problem in the past when cloning expired save sets
wherein it was necessary to
first change the clone retention time (clretent) to some time in the
future, and then change the mode (nsrmm)
to notrecyclable. It must be done in that order. Otherwise, the cloning
would fail. They fixed that issue in a
later release, however. At least I think they did?

> The way it is supposed to work is that the browse time should
> auto-extend to "<the original browse policy> + <index recover time>"
> and that should take care of the problem. But as I said this didn't
> happen. And I am not sure it is fixed/changed even now...
I don't see any indication in the man page for nsrck that nsrim will be
run, but it does mention the converse wherein
nsrim will automatically invoke nsrck -L 3. So if /nsr/mm/nsrim.prv is
more than 23 hours old then we'd expect nsrim
to get invoked when the next group completes. That being the case, the
merged entries would go away, assuming
they were old enough, if I understand you correctly.

1. However, let's say you did whatever you needed to do with the new
index (following the merge) while nsrim.prv
is still a ways off from hitting the witching hour. In this case then I
guess you'd be fine regardless. That sound correct?

2. Alternatively, assuming the index save set is old enough, if you're
going to need those merged entries after nsrim's
next run then you'd have to first change the browse time or the
retention time on the index save set as you said.

Or (and I'm kinda unsure here) are you *instead* saying that you'd have
to first change the browse or retention time
on the save set(s) that you want to browse whose contents will become
browsable following the merge (nsrck -L7)
of the old index?

3. The man page for nsrmm with the -w browse time option mentions that
the browse time cannot be changed once the save set
becomes recoverable.

So is the trick here to 1. first change the clone retention time (nsrmm
-S ssid/cloneid -e tomorrow) to a suitable time in the
future (say 'tomorrow') that will allow enough time and then 2. make the
save set not recyclable (nsrmm -o notrecyclable -S ssid/cloneid)
so you can subsequently 3. change the browse time (nsrmm -S ssid/cloneid
-w tomorrow).  All three steps?

Do I change both browse time and retention time or just one or the other?


The idea of changing the clone retention time (clretent) instead of the
retention time (ssretent; not mentioned in the nsrmm man page)
is a bit unintuitive, but I always forget that every save set is a clone
of itself and also has a clone id, thus changing the clretent time
does change the ssretent (ssexp). I believe?

George

> Best
> Dag
>


--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Re: Some more questions on indexes
October 03, 2017 07:59PM
On 2017-09-30 03:06, Dag Nygren wrote:
> The only gotcha's with nsrck -L7 I have ran in to are:
>
> 1. The size of the index directory will if the saveset is old enough
> grow quite a lot as everything that was in the then is merged with
> the current contents.
>
> 2. There was for a long time a bug in the process where the recovered
> saveset index info would almost immediately be cleaned out again by nsrim
> if it had passed it's retention/browse time. The cure was changing
> the browse and/or retention time _before_ doing the nsrck -L7.
> The way it is supposed to work is that the browse time should
> auto-extend to "<the original browse policy> + <index recover time>"
> and that should take care of the problem. But as I said this didn't
> happen. And I am not sure it is fixed/changed even now...

Okay, after thinking about this for a while and doing some more research
on this, I think
I was misunderstanding several key points.

A. The index is never browsable, only recoverable or possibly
recyclable, so you're
not going to change the browse time of an index. That makes no sense.

B. When 'nsrck -L7' runs -- and I guess this wasn't obvious but should
have been --
it will change the status of any save set from recoverable to browsable
whose
contents are being restored to the index for the given date/time. The
man page
for nsrck says this under Level 7:

" ... This option allows browsing of save sets that have passed their
browse policy and are still recoverable.
       The save sets referred to by the recovered index will be marked
as browsable. ..."

it's that second sentence that I didn't notice. I was initially thinking
that restoring the index was an operation
unto itself, solely dedicated to the index, and didn't have any effect
on the media database. I guess I was
thinking that something else would do that instead. But clearly, though,
it would have to affect the media database
as it's illogical to have entries in the client file index if the
corresponding save set(s) in the media database is still
marked as recoverable and not browsable. Okay, that clears that up.

C. There's no command to just make a save set browsable. Only 'nsrck
-L7' or 'scanner -i' will do that, not
simply nsrmm with some magic option.

D. If a save set is recyclable then its status must first be changed to
recoverable, prior to running nsrck, by first
changing the retention time of the save set (nsrmm -e) and next making
it not recyclable (nsrmm -o notrecyclable),
in that order. If this is is not done first, then nsrck will not be able
to restore that save set's contents to the
index since the save set's status will not be recoverable. I guess it
would just ignore any such save sets in that
time frame, and only restore (merge in) the contents for save sets
wherein their status is recoverable, assuming
they're within the specified date/time provided to the nsrck -L7 command.

E. I'm unclear on what the browse time will become following 'nsrck
-L7'. The browse time is always less than the
retention time, and you can't change the browse time until the save set
is browsable, but that won't happen until
after the nsrck. So if the recovered information doesn't get assigned a
new browse time equal to the configured
browse time (let's say one month) plus the date/time of the index
recovery then what would it get set to? Maybe
the time of the recovery?

In this case, as long as you could do what you needed to before the next
run of nsrim (23 hours) you'd be fine;
otherwise, you'd have to change the browse time (nsrmm -w) to some time
that was far enough in the future
to complete the task, but it could not exceed the retention time.

But if the browse time isn't auto-extended, and you can't change browse
time unless it's browsable then how
is changing the retention time before running nsrck going to help?

> Best
> Dag
>


--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Interesting observation with an index
October 13, 2017 01:59PM
I recently tested (may have done this in the past?) using scanner with
uasm to recover the contents
of an index save set, not a data save set. I first ran it for the full
and then for a later level 9 as:

scanner -f file_number -S ssid /dev/device | uasm -rv -iN
-m/path_source=/path_dest

This added the contents to the existing index.

After doing this, I then ran 'nsrinfo client' and compared before/after.
No differences. Also,
running 'nsinfo -t nsavetime client' returned 0 objects found for the
older times, although
newer times for browsable save sets still worked. However, I then ran
nsrck -L1. No luck.
Next, I ran nsrck -L2, and now the 'nsrinfo -t' command was able to
return listings for save sets
marked recoverable in the media database as long as their times were
covered by the index entries
recovered from scanner. In fact, I looped through all the recoverable
save sets that the index covered,
and it generated output for all of them.

However, if I run `recover -c client`, and I attempt to change the
browse time to any of
those older times (even using the nsavetime), I get the error:

cannot browse file_system as of `date'

None of the values works. Next, if I exit the recover utility, and I run
the 'nsrinfo -t' command
then if fails on all the values that it previously worked on. If I then
run 'nsrck -L2' again then
nsrinfo works again, just like before, but never for browsing the index
via recover. So the L2
is kind of an on/off switch. Of course, running -L3 or above removes all
the entries added from
scanner; perhaps no surprise since there's no corresponding browsable
save sets in the media
database; their status is still (r)ecoverable.

Anyway, the respective data save sets remain recoverable in the media
database and did not
change to browsable. I'm guessing that's why the index will not allow me
to browse those
times even though 'nsrinfo -t' will?

Does `nsrinfo client` simply loop through all the browsable save sets
and queries the respective information
from the client index? Or does it instead read the CFI but simply
ignores any times that are outside the browse time?

I did try shutting down the server, removing the index (nsrck -RY), and
restarting, so I basically started with an
empty index (a copy of the old one was first safely stored away). I then
repeated the above steps, thinking that
maybe if all the CFI had was older stuff then maybe it just might work?
Nope. The behavior was the same.

I also experimented with the '-iY' option with the scanner command.
Nothing mattered.

So even if the index has the information, until the corresponding save
sets are changed to (b)rowsable, browsable recovery won't work,
and the only way to make those save sets browsable is to use the
'scanner -i' or 'nsrck -L7' options, just like we've always been told.

Would there be a way to fool it?  Any tricks?

Anyway, this was just an experiment. Any thoughts?

--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Dag Nygren
Re: Interesting observation with an index
October 14, 2017 01:59AM
On Friday 13 October 2017 16:39:43 you wrote:
> I recently tested (may have done this in the past?) using scanner with
> uasm to recover the contents
> of an index save set, not a data save set. I first ran it for the full
> and then for a later level 9 as:
>
> scanner -f file_number -S ssid /dev/device | uasm -rv -iN
> -m/path_source=/path_dest

> Would there be a way to fool it? Any tricks?

Just a thought...

Did you make sure that the client-id of the old savesets
are the same as the current one?

Best
Dag


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Re: Interesting observation with an index
October 15, 2017 05:59PM
On 2017-10-14 04:33, Dag Nygren wrote:
> On Friday 13 October 2017 16:39:43 you wrote:
>> I recently tested (may have done this in the past?) using scanner with
>> uasm to recover the contents
>> of an index save set, not a data save set. I first ran it for the full
>> and then for a later level 9 as:
>>
>> scanner -f file_number -S ssid /dev/device | uasm -rv -iN
>> -m/path_source=/path_dest
>> Would there be a way to fool it? Any tricks?
> Just a thought...
>
> Did you make sure that the client-id of the old savesets
> are the same as the current one?
Yes. They're identical.

But one thing that I've not tried is to see what happens if I increase
the browse policy
of the client, say, maybe to a year or whatever it would take to cover a
time that old,
maybe a little extra for cushion.

*If* that works, I wonder it if it would be necessary to do it before I
run scanner, or if I
could do it after, maybe as long as it's done before I run recover?

It's not a big deal to test it, but as you know with tests, there's so
many possibilities and only so much time.

Also, I wonder if it would be necessary to increase the retention time
of the affected data save set?
It's not set to expire for about three months. The index will also
expire in three months.

However, *if* increasing the browse policy is necessary then given that
the browse time
cannot exceed the retention time, then as long as the browse time
changes to at least
a future date of a few days from now then that would be more than
sufficient for my test.


BTW In your other reply, when you said:

>> 2. There was for a long time a bug in the process where the recovered

>> saveset index info would almost immediately be cleaned out again by nsrim
>> if it had passed it's retention/browse time. The cure was changing
>> the browse and/or retention time _before_ doing the nsrck -L7.
>> The way it is supposed to work is that the browse time should
>> auto-extend to "<the original browse policy> + <index recover time>"
>> and that should take care of the problem. But as I said this didn't
>> happen. And I am not sure it is fixed/changed even now..."

I'm unclear on how you can change the browse time before you run nsrck
-L7 if the save set
is not browsable? Are you instead saying that you'd increase the browse
policy for the client accordingly?
And then change it back once you recovered your data?

Also, why would increasing the retention time matter if it's not set to
expire before you
could complete the recovery? Would it only be applicable if it was?

Thanks,

George

>
> Best
> Dag


--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Dag Nygren
Re: Interesting observation with an index
October 15, 2017 11:59PM
On Sunday 15 October 2017 20:04:52 you wrote:
> On 2017-10-14 04:33, Dag Nygren wrote:

> But one thing that I've not tried is to see what happens if I increase
> the browse policy
> of the client, say, maybe to a year or whatever it would take to cover a
> time that old,
> maybe a little extra for cushion.

Don't think that will work...

Browse policy is supposed to be used only once
during the saveset life and that is to
create the browse time in the media database
when the saveset is backed up.

> >> 2. There was for a long time a bug in the process where the recovered
>
> >> saveset index info would almost immediately be cleaned out again by nsrim
> >> if it had passed it's retention/browse time. The cure was changing
> >> the browse and/or retention time _before_ doing the nsrck -L7.
> >> The way it is supposed to work is that the browse time should
> >> auto-extend to "<the original browse policy> + <index recover time>"
> >> and that should take care of the problem. But as I said this didn't
> >> happen. And I am not sure it is fixed/changed even now..."
>
> I'm unclear on how you can change the browse time before you run nsrck
> -L7 if the save set
> is not browsable? Are you instead saying that you'd increase the browse
> policy for the client accordingly?
> And then change it back once you recovered your data?

No, I did mean browse time. But to get that done you will
of course also need to increase the retention time if it is
shorter than the current time (save set recyclable)


Best
Dag


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Re: Interesting observation with an index
October 16, 2017 01:04PM
On 2017-10-16 02:34, Dag Nygren wrote:
> On Sunday 15 October 2017 20:04:52 you wrote:
>> On 2017-10-14 04:33, Dag Nygren wrote:
>> But one thing that I've not tried is to see what happens if I increase
>> the browse policy
>> of the client, say, maybe to a year or whatever it would take to cover a
>> time that old,
>> maybe a little extra for cushion.
> Don't think that will work...
>
> Browse policy is supposed to be used only once
> during the saveset life and that is to
> create the browse time in the media database
> when the saveset is backed up.
Right, I agree, but I'll give it the old college try.
>>>> 2. There was for a long time a bug in the process where the recovered
>>>> saveset index info would almost immediately be cleaned out again by nsrim
>>>> if it had passed it's retention/browse time. The cure was changing
>>>> the browse and/or retention time _before_ doing the nsrck -L7.
>>>> The way it is supposed to work is that the browse time should
>>>> auto-extend to "<the original browse policy> + <index recover time>"
>>>> and that should take care of the problem. But as I said this didn't
>>>> happen. And I am not sure it is fixed/changed even now..."
>> I'm unclear on how you can change the browse time before you run nsrck
>> -L7 if the save set
>> is not browsable? Are you instead saying that you'd increase the browse
>> policy for the client accordingly?
>> And then change it back once you recovered your data?
> No, I did mean browse time. But to get that done you will
> of course also need to increase the retention time if it is
> shorter than the current time (save set recyclable)
But I still don't understand how you do that. The man page for nsrmm
states (-w option)
"that once the save set becomes recoverable, the browse time may not be
changed."
I thought this was only possible once the save set *is* browsable in
which case you wouldn't
be running nsrck -L7. You could, however, change the browse time after.

So what command are you running (before nsrck -L7) to accomplish this?

Also, where you say: "you will of course also need to increase the
retention time if it is shorter than the current time (save set
recyclable) ",
what current time? If my save set has a status of recoverable, a save
time of 2017-01-12, browse time is 2017-02-13 and retention time is
2018-01-13
then what current time are you referring to?

Thanks,

George

>
> Best
> Dag


--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Dag Nygren
Re: Interesting observation with an index
October 17, 2017 02:59AM
On Monday 16 October 2017 15:13:16 you wrote:

> > Browse policy is supposed to be used only once
> > during the saveset life and that is to
> > create the browse time in the media database
> > when the saveset is backed up.
> Right, I agree, but I'll give it the old college try.

Do that! And please tell us how it worked out!

> > No, I did mean browse time. But to get that done you will
> > of course also need to increase the retention time if it is
> > shorter than the current time (save set recyclable)
> But I still don't understand how you do that. The man page for nsrmm
> states (-w option)
> "that once the save set becomes recoverable, the browse time may not be
> changed."
> I thought this was only possible once the save set *is* browsable in
> which case you wouldn't
> be running nsrck -L7. You could, however, change the browse time after.
>
> So what command are you running (before nsrck -L7) to accomplish this?

I have definitely been using nsrmm -e for this. It will warn you,
but still do the change. It will not change the status of the saveset, though.

But please try that out too, as my experience with this is
a bit aged! Some 3-4 years ago...


> Also, where you say: "you will of course also need to increase the
> retention time if it is shorter than the current time (save set
> recyclable) ",
> what current time? If my save set has a status of recoverable, a save
> time of 2017-01-12, browse time is 2017-02-13 and retention time is
> 2018-01-13
> then what current time are you referring to?

Here I was thinking recyclable savesets. Sorry.
And changing the retention time beyond current time
will make that recoverable again.

Good luck!
Dag


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
George Sinclair - NOAA Federal
Re: Interesting observation with an index
October 17, 2017 10:59AM
On 2017-10-17 05:19, Dag Nygren wrote:
> On Monday 16 October 2017 15:13:16 you wrote:
>
>>> Browse policy is supposed to be used only once
>>> during the saveset life and that is to
>>> create the browse time in the media database
>>> when the saveset is backed up.
>> Right, I agree, but I'll give it the old college try.
> Do that! And please tell us how it worked out!
Probably an utter waste of time (Ha), but there's always the remote
possibility that there could
be some fountain of youth underlying the software that's not documented.
It's not too long to test, anyway.
>>> No, I did mean browse time. But to get that done you will
>>> of course also need to increase the retention time if it is
>>> shorter than the current time (save set recyclable)
>> But I still don't understand how you do that. The man page for nsrmm
>> states (-w option)
>> "that once the save set becomes recoverable, the browse time may not be
>> changed."
>> I thought this was only possible once the save set *is* browsable in
>> which case you wouldn't
>> be running nsrck -L7. You could, however, change the browse time after.
>>
>> So what command are you running (before nsrck -L7) to accomplish this?
> I have definitely been using nsrmm -e for this. It will warn you,
> but still do the change. It will not change the status of the saveset, though.
>
> But please try that out too, as my experience with this is
> a bit aged! Some 3-4 years ago...
Ah, I was wondering how the '-e' option was going to, or even could,
work in this case. Interesting. We'll see.

You know -- and this may not have anything to do with what we've been
talking about, but I vaguely remember,
way, long ago, some weird deal wherein one needed to increase the browse
policy in order to accommodate older,
recovered index entries. Maybe I'm remembering incorrectly, or I might
have that confused with something else.

>
>> Also, where you say: "you will of course also need to increase the
>> retention time if it is shorter than the current time (save set
>> recyclable) ",
>> what current time? If my save set has a status of recoverable, a save
>> time of 2017-01-12, browse time is 2017-02-13 and retention time is
>> 2018-01-13
>> then what current time are you referring to?
> Here I was thinking recyclable savesets. Sorry.
> And changing the retention time beyond current time
> will make that recoverable again.
Right. That was also how I used to clone expired save sets wherein I had
to first change the retention time and
then make them not recyclable, using nsrmm for both operations. I don't
recall the order, but one had to be
done before the other, and you had to do both.

Thanks, Dag :)

> Good luck!
> Dag


--
George Sinclair
Voice: (301) 713-4921
- The preceding message is personal and does not reflect any official or unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login