Looks like it was my "oops" that made it still not work.

Thanks to everyone.


Peter Viertel wrote:

Well it's all worth reviewing in 7.4.1 - I know there was a bit of a

redesign in 7.3, so maybe they fixed that bit up...

In my 7.2 system I do cloning in 1 hour chunks with a call to nsrstage
-C and a 1 minute sleep in between...   Not perfect, but it gets the job
done.

BTW;  [RW cloneid] == [RO cloneid] + 1          -   if that helps...
cloneid's are actually the unixtime when the clone record was created,
that may be useful to know also.

-----Original Message-----

From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Brian O'Neill

Sent: Friday, 1 February 2008 10:25 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU

Subject: Re: [Networker] Cloning/migrating from AFTD with multiple clones - first clone gets removed from DB

Thanks - very good info to chew on here.

I know if I used the RW ssid/cloneid, it did the cloning session from the RW device, which is not ideal since it would block other backups. However, if I need to use the RO ssid/cloneid to do the staging, I'll have to save the RW ids as well, and as you say use nsrmm instead of nsrstage it seems.

I was not aware of nsrstage having issues if there is a write session. That kind of blows the reason for doing the clone off the RO volume.

By the way, this is on 7.4.1


Peter Viertel wrote:

As you have discovered nsrmm -d -S {ssid} deletes all the

clones... Not

useful..

Nsrmm -d -S {ssid/cloneid} works fine, but the trick

here is that

there are two cloneids for the aftd version - the RW

device, and the RO

device... The big secret here is to delete just the RW

cloneid, not the

RO one... When the process is finished deleting all the

savesets you

follow it up either by running 'nsrstage -C -V {volume}'

or  ' nsrmm -X

-V {volume}.RO' to reclaim the diskspace.

There is a difference between using nsrstage -C   and nsrim -x...

Nsrstage does not work if theres an active write session on

that volume,

but on the other hand it can work when the volume has had

all of it's

savesets deleted.    Nsrim -X  works even when there's writing

happening, but does nothing if you've just removed the last

saveset...

Neither can reclaim space while a read is happening however...

It may seem tempting to try deleting both the aftd cloneids

- it will

let you, but then you will never get your disk space back unless you
relabel the volume...

This all relates to versions up to 7.2.2. so far 7.3.3

appears to

have the same behaviour, although I'm hoping they've fixed the

reclaiming of disk space while cloning...

A big caveat here!   Just because you have copies>2   does not mean

they're all GOOD copies.. You should take care not to

delete the disk

copy until you are sure the tape based ones are complete   - i check
clflags is blank on the tape clone before deleting.

-----Original Message-----

From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Brian O'Neill

Sent: Friday, 1 February 2008 8:53 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU

Subject: Re: [Networker] Cloning/migrating from AFTD with multiple clones - first clone gets removed from DB

Eric Poulin wrote:

Hello Brian,

I believe you are speaking of "nsrstage" instead of "nsrclone".

Actually I meant "nsrstage" instead of "nsrmigrate" - the latter was one of my script names... :)

I actually DID do as you suggest, as I said - I used ssid/cloneid pairs for my list. When I had issues with that (not the same issues) I tried ssid only. I tried switching back, and it didn't work - but I may just have found an "OOPS" in my code from when I tried something, and I may have generated a list with both just the ssids AND the ssid/cloneid pairs.

I'll know tomorrow when I've got something to migrate... :)

-Brian

To sign off this list, send email to listserv AT listserv.temple DOT edu and type "signoff networker" in the body of the email. Please write to networker-request AT listserv.temple DOT edu if you have any problems with this list. You can access the archives at http://listserv.temple.edu/archives/networker.html or

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

NOTICE

This e-mail and any attachments are confidential and may

contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. To sign off this list, send email to listserv AT listserv.temple DOT edu and type "signoff networker" in the body of the email. Please write to networker-request AT listserv.temple DOT edu if you have any problems with this list. You can access the archives at http://listserv.temple.edu/archives/networker.html or

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

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER