archive clone cloneid same for different SSID's!! 1

[nohandleisworking]

Hi,

Is this a possible nw 7.1.2 bug or a possible bug with adv_file from the NW DiskBackup option?

Background: Solaris 8 server running NetWorker 7.1.2 (just updated successfully last week from 7.1.0). Also started testing today of adv_file device to use for archiving directly to disk and then cloning from disk to tapes.

Regularly use scripts to automate nsrarchiving to a "Archive" type of pool of tapes. Then at end use an nsrclone command to clone copies of all savesets based on how many copies there are. i.e.
nsrclone -b "SomeArchiveClonePool" -S `mminfo -r "ssid" -q "pool=SomeArchivePool,copies<2"

In past when I archive to tape and then subsequestly clone savesets to an "archive clone" pool tape and then if I run an mminfo command on the different pools or tape volumes, I always got a unique cloneid number for every ssid number.

Today when I did testing of adv_file archiving and subsequent Cloning the disk archives to Tape pool, I got weird results. Everything was good and I could restore all savesets from the adv_file device volume and the clone tape copies, so everything seems to work, but an mminfo now shows that every cloneid on the tape is the exact same number. I got all the SAME cloneid's on the tape no matter what the unique ssid was. AND I even waited some time and made more little nsrarchives to adv_file volume and then did nsrclone copies later in day with same results. As long as the SSID was on the same tape the cloneid's were all same. If I cloned to a different pool with a different pool name and different tape - smae kind of results, a new cloneid is on other tape - but still same cloneid is listed with every single different SSID.

mminfo output, it shows SAME cloneid for all my saveset SSID's on a tape by tape basis.
This is repeatable and it doesn't exisit this way on any tapes i made before today. And I did make different "archive clone" pools and tried it on differen pools using different tapes.

when I did clone copies to second clone pool to test further, say "Full Archive Clone", it also had same results as first tape copy mminfo output...it uses a different Cloneid than the first tape from first clone pool, BUT it still uses the same CloneID (like 1056672394 ) on the tape for ALL SSID's:

#mminfo -r "ssid,cloneid,name,volume" -q "pool=Full Archive Clone"
ssid clone id name volume
458859621 1056672394 /stuff/file1 B00001L1
672976823 1056672394 /stuff/file2 B00001L1
[snip]

I have search the release doc's for 7.1.2 and the admin guide for 7.1.x and the error reports and the legato web and have found nothing about why the cloneid's are all the same number now.

if anyone knows, it would be appreciated since this is quite bizarre and new behavior and i am worried it may affect when i am ready to use nsrstage with ssid/cloneid option from disk to tape when disk gets too full.

 

[bertieuk]

Hi

I noticed this with my setup.....It would seem that the combination of ssid/clonid makes the entry unique.

I have assumed that when you clone, all clones within a group take the same same ID and I also assume that is why you cannot copy savesets multiple times.

I think this is the "Norm"

Si

 

[605]

The behaviour of the same cloneid for multiple save sets seems to be strange but it must not necessarily be wrong.

The cloneid is in fact nothing else but the UNIX standard time (counting in seconds from 01/01/1970). This is also represented by the mminfo parameter nsavetime.

So far i assumed that all NW save sets will be started (internally) in a way that they differ at least by one second. If you look up the save set info for and Advanced File Device you will notice that the same save set is in fact stored twice:
- the first instance resides one on the R/W device
- the second instance points to the associated RO device instance.

Although both instances have of course the same ssid, their clone id differ by exactly one second. The save set with the lower cloneid points to the RO device. As NW be default always tries to access the save set with the lowest cloneid, it will try to do it from there, freeing the RW drive which now can accept new backups. This is why you can simulteanously read and write to such device.

As you can not recover from a cloneid ONLY, it should not be a problem as long as the combination of ssid/cloneid still is unique.

 

[nohandleisworking]

Hi,
response to "605" - ok - i knew about the fact that adv_file makes two SSID's, one for the adv_file volume and one for adv_file (read-only) volume to allow simultaneous reads/writes. I didn't mention this b/c it's not relevant to the problem. An mminfo on the adv_file volume is fine and has a different unique SSID number and a different Unique Cloneid number so the problem is not there at all. I am only having a problem when I mminfo the actual "clone" tape.

As far as the timestamp of CLONEID's, I waited over ten minutes between trying subsequent "nsrarchives" to the adv_file, and then I made more "nsrclones" waited over 10 min. and then did more "nsrarchives" and then waited and did more "nsrclones". Surprisingly, "every" single CloneID on the tape no matter how long I waited between doing subsequent ones was the SAME on say tape #1. Then I tried cloning to a different pool with a different tape, say tape#2 and same thing happened. I did the Clones one by one this time, by simply just selecting an SSID from the adv_file and cloning that, waited and did it again 10 minutes later. SAME results, all CloneID's on tape#2 are exactly the same.

If you are saying this is usual then is there documentation about this somewhere because, it doesn't exist this way on any other of my hundreds of tapes before I upgraded to 7.1.2 and started cloning from disk to tape. Also, the reason why this is a problem is it changes how nsrstage would work.

When you nsrstage becasue you migrate off of old media you have a choice to do "nsrstage ssid/cloneid" so that you can specifically migrate a tape to new media without wiping out all instances of the saveset on other media. In the past when I did NSRstaging, I was used to seeing a unique cloneid next to every single SSID. If this is usual about having the same Cloneid, then it never happened before a couple days ago and I have hundreds of tapes that were made before yestrerday that are not that way. Also, as I said it would seem that NSRStage options would be affected now.

 

[bertieuk]

You may need to cut and paste the following out to notepad to bring it to a more readable format

ssid clone id date group volume lvl name browse retent
4041542797 1088758856 02/07/2004 London Full1 Full_Clone.001 full C:\ 01/08/2004 03/07/2005
4024765598 1088758856 02/07/2004 London Full1 Full_Clone.001 full D:\ 01/08/2004 03/07/2005
3991211196 1088758856 02/07/2004 London Full1 Full_Clone.001 full F:\ 01/08/2004 03/07/2005
4058320003 1088758856 02/07/2004 London Full1 Full_Clone.001 full SYSTEM DB:\ 01/08/2004 03/07/2005
3974434157 1088758856 02/07/2004 London Full1 Full_Clone.001 full SYSTEM FILES:\ 01/08/2004 03/07/2005
3957656943 1088758856 02/07/2004 London Full1 Full_Clone.001 full SYSTEM STATE:\ 01/08/2004 03/07/2005
4125428858 1088757772 02/07/2004 Derby Full2 Full_Clone.001 full C:\ 01/08/2004 03/07/2005
4007988384 1088756692 02/07/2004 Derby Full2 Full_Clone.001 full D:\ 01/08/2004 03/07/2005
4091874427 1088758312 02/07/2004 Derby Full2 Full_Clone.001 full SYSTEM DB:\ 01/08/2004 03/07/2005
4108651642 1088758312 02/07/2004 Derby Full2 Full_Clone.001 full SYSTEM FILES:\ 01/08/2004 03/07/2005
4075097211 1088756692 02/07/2004 Derby Full2 Full_Clone.001 full SYSTEM STATE:\ 01/08/2004 03/07/2005
3940881540 1088756692 02/07/2004 Networker Backup Full_Clone.001 full bootstrap 01/08/2004 03/07/2005
3655669304 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full bootstrap 01/08/2004 03/07/2005
3571784117 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full bootstrap 01/08/2004 03/07/2005
3420789342 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full bootstrap 01/08/2004 03/07/2005
4226092129 1088756692 02/07/2004 Networker Backup Full_Clone.001 full C:\ 01/08/2004 03/07/2005
4209314928 1088756692 02/07/2004 Networker Backup Full_Clone.001 full D:\ 01/08/2004 03/07/2005
3706000941 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kpro-client1 01/08/2004 03/07/2005
3638892970 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kpro-client1 01/08/2004 03/07/2005
3538229743 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kpro-client1 01/08/2004 03/07/2005
3471120979 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kpro-client1 01/08/2004 03/07/2005
3689223725 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kserv-backup 01/08/2004 03/07/2005
3605338538 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kserv-backup 01/08/2004 03/07/2005
3555006959 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kserv-backup 01/08/2004 03/07/2005
3454343763 1088758312 02/07/2004 Daily All Indexes Full_Clone.001 full index:2kserv-backup 01/08/2004 03/07/2005
3672446518 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:backup-server1 01/08/2004 03/07/2005
3588561331 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:backup-server1 01/08/2004 03/07/2005
3504675320 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:backup-server1 01/08/2004 03/07/2005
3437566556 1088758312 02/07/2004 Daily All Indexes Full_Clone.001 full index:backup-server1 01/08/2004 03/07/2005
3722778157 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:mc54321 01/08/2004 03/07/2005
3622115754 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:mc54321 01/08/2004 03/07/2005
3521452527 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:mc54321 01/08/2004 03/07/2005
3487898195 1088757772 02/07/2004 Daily All Indexes Full_Clone.001 full index:mc54321 01/08/2004 03/07/2005
4259646561 1088757772 02/07/2004 Networker Backup Full_Clone.001 full SYSTEM DB:\ 01/08/2004 03/07/2005
4276423777 1088757772 02/07/2004 Networker Backup Full_Clone.001 full SYSTEM FILES:\ 01/08/2004 03/07/2005
4242869345 1088757772 02/07/2004 Networker Backup Full_Clone.001 full SYSTEM STATE:\ 01/08/2004 03/07/2005
4175760502 1088758316 02/07/2004 London Full2 Full_Clone.001 full C:\ 01/08/2004 03/07/2005
4158983286 1088758856 02/07/2004 London Full2 Full_Clone.001 full SYSTEM DB:\ 01/08/2004 03/07/2005
4192537718 1088758856 02/07/2004 London Full2 Full_Clone.001 full SYSTEM FILES:\ 01/08/2004 03/07/2005
4142206070 1088758856 02/07/2004 London Full2 Full_Clone.001 full SYSTEM STATE:\ 01/08/2004 03/07/2005

There are many ssids but only two clone id used and these are created from the two groups I cloned. The ssid/cloneid makes the cloned saveset unique....even an original saveset will have a cloneid. I use the ssid/clonid to purge entries on my adv file volumes after two weeks.

It is Normal

Si

 

[nohandleisworking]

Hi all,

thanks for your output to confirm that other people also get the same cloenid. I just heard back from my Legato support... they are investigating it further. I sent them tons of tests and outputs. You see, they said although it is normal to have the same Cloneid when you do a batch job altogether, apparently is not normal to have all the same cloneid's when you wait between doing subsequent nsrclone's. I not only waited over ten minutes between each clone but ran more tests in which I archived and then did only one clone at a time waiting over 10 minutes between each one, and still the same cloneid.

 

[605]

As i usually just demo the meaning of the cloneids using a single save set, i was not aware that the cloneid for cloned/staged save sets does behave different.

To my knowledge, the value of the cloneid has never been described. So i made a brief test to figure out the real behaviour. I backed up 7 save sets in total which i then cloned in diffentent ways:
- by the savegroup's automatic clone fature
- using nsrsclone -S -f file
where 'file' represents a file with all backup ssids
- using nsrclone backup_volume


This is what i discovered:

***** NW 614 ******
- automatic cloning all cloneids are different
- manual save set cloning only 2 cloneids, 1 sec apart
- volume clone only 2 cloneids, 1 sec apart

***** NW 710 ******
- automatic cloning only 2 cloneids, 2 sec apart
- manual save set cloning only 1 cloneid for all ssets
- volume clone only 1 cloneid for all ssets

***** NW 712 ******
- automatic cloning only 1 cloneid for all ssets
- manual save set cloning only 1 cloneid for all ssets
- volume clone only 1 cloneid for all ssets


As you can see the meaning obviously changed a bit throughout the versions. But with respect to an upgrade from 710 to 712, the difference is minor.

However, this should not affect the real life operation. Do not keep in mind that using the cloneid is not possible - if ever used, it must be the combination of the ssid/cloneid which is in fact unique. So i would not consider this to be a problem.