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
|
