Backup Central

Is it possible that a numeric backup could still be browsable
(sumflags=cb) but none of the older instances of that save set? In other
words, the preceding incrementals are 'cr' and the previous full is
also 'cr'?

Under what circumstances could this occur? Seems like the numeric would
still require the previous full to rebuild the save set as it existed at
that time, assuming the numeric is still browsable? I know this is true
with incrementals, anyway. Thought so ...

George

--
George Sinclair
Voice: (301) 713-3284 x210
- 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. -


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

In regard to: [Networker] Can a numeric backup be the oldest browsable...:

Is it possible that a numeric backup could still be browsable (sumflags=cb)
but none of the older instances of that save set? In other words, the
preceding incrementals are 'cr' and the previous full is also 'cr'?

If you scanned just the numeric, yes.

I can't think of other "normal" conditions under which it could occur,
though.

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

I think you have a typo in your statement:

"In other words, the preceding incrementals are 'cr' and the previous full is also 'cr'?"
should obviously read:
"In other words, the preceding incrementals are 'cb' and the previous full is 'cr'?" - correct?

Yes, this is in fact possible. No idea why NW should do it on its own but in general, the status of each save set exists individually, of course.
You can verify that yourself: just delete the file index of a browseable full with "nsrmm -dP -S ssid_full" and check the SS status.

On 2012-04-19 16:17, bingo wrote:
I think you have a typo in your statement:

"In other words, the preceding incrementals are 'cr' and the previous full is also 'cr'?"
should obviously read:
"In other words, the preceding incrementals are 'cb' and the previous full is 'cr'?" - correct?
No typo. You have, say, a level 5 of /home, and it's listed with
sumflags of 'cb', but everything before that (all incrementals), going
back to the previous full are 'cr', and you'd expect that that full
would be 'cb' since recovering from the level 5 should require it
(assuming that the level 5 didn't capture everything, and nfiles
suggests that it didn't even come close), but that full is instead 'cr'.
I could see that the incrementals would be 'cr' since the 5 makes those
unnecessary but seems odd that the full would also be 'cr'.

Of course, all the instances of /home that are within the browse policy
(one month) are 'cb', 'vF' which is to be expected, but you have:

/home 2012-02-21 cr vrF full
/home 2012-02-22 cr vrF incr
....
/home 2012-03-13 cr vrF incr
/home 2012-03-14 cr vrF incr
/home 2012-03-15 cb vF 5
/home 2012-03-16 cb vF incr
/home 2012-03-17 cb vF incr
...
/home 2012-04-14 cb vF incr
/home 2012-04-15 cb vF 5
/home 2012-04-16 cb vF incr
/home 2012-04-17 cb vF incr
/home 2012-04-18 cb vF incr

Everything before 2012-03-15 is 'cr', 'vrF' including the full???

Yes, this is in fact possible. No idea why NW should do it on its own but in general, the status of each save set exists individually, of course.
You can verify that yourself: just delete the file index of a browseable full with "nsrmm -dP -S ssid_full" and check the SS status.
Yes, I follow that logic. I assume that the sumflags would change to
'cr' if it was 'cb' before, and the ssflags would change to 'vrF' if it
was 'vF' before. Just seems odd that NW would take any action on its own.

+----------------------------------------------------------------------
|This was sent by carsten_reinfeld < at > avus-cr.de via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


--
George Sinclair
Voice: (301) 713-3284 x210
- 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. -


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER