I may be overly cautious, but I would set copy 1's expiry date to "tomorrow"
rather than "now", so that I have time to fix things if I somehow mess with
the copy that I want to keep, rather than having everything vanish instantly
as would happen if I used -d 0.

bpexpdate -backupid <backupid> -copy 1 -d 01/09/2010

Then a bpimagelist to make sure the expiration date on each copy is they way
I want it.



On Fri, Jan 8, 2010 at 1:35 AM, Jeff Lightner <jlight...@water.com> wrote:

>   Typically we wouldn’t promote the duplicate (copy 2) to primary first.
> We’d simply set its retention:
>
>
>
> bpexpdate -backupid <backupID> -d infinity -copy 2
>
>
>
> Then for the original (copy 1) we’d set it to expire immediately:
>
>
>
> bpexpdate -backupid <backupID> -d 0 -copy 1
>
>
>
> We wouldn’t specify media at all as what we’re interested in is the images
> (which is what the backupid refers to) not the media.  Once all images on a
> given media are expired then the media itself expires automatically.
>
>
>  ------------------------------
>
> *From:* veritas-bu-boun...@mailman.eng.auburn.edu [mailto:
> veritas-bu-boun...@mailman.eng.auburn.edu] *On Behalf Of *BeDour, Wayne
> *Sent:* Thursday, January 07, 2010 9:22 AM
> *To:* veritas-bu@mailman.eng.auburn.edu
> *Subject:* [Veritas-bu] Duplication / expiring image question
>
>
>
> Our environment, NBU 6.5.4 running on HP-UX 11-31 with a Data Domain VTL
> and MSL6060 tape library.
>
> Our tape library wasn’t connected when we ran our yearly backups and now
> that it is, I’m in the process of duplicating the yearly backups from the
> VTL to tape to be moved offsite.  I am going through my process to insure I
> don’t miss any data in the move and only remove the original of the duplicated
> data.  I have duplicated what was backed from one policy and set the copy as
> primary.  In the example below, the original was backed up to D11233 and
> then duplicated to 000789.
>
> #
>
>  # bpimagelist  -d 01/02/2010 -sl dbn-pkg02-arch-bcv-yf
>
> IMAGE yos_sam1 0 0 8 yos_sam1_1262415605 dbn-pkg02-arch-bcv-dd 0 *NULL*
> root dbn-pkg02-arch-bcv-yf 0 8 1262415605 1296 1483167605 0 0 16501472 1826
> 2 2 0 dbn-pkg02-arch-bcv-dd_1262415605_FULL.f *NULL* *NULL* 0 2 0 0 0 *NULL*
> 0 0 0 0 0 0 0 *NULL* 0 0 0 *NULL* 438265 1 0 198706 0 0 *NULL* *NULL* 0 0
>
> HISTO -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
>
> FRAG 1 1 16501472 0 2 6 1 D11233 yos_sam1 65536 2 0 1 0 *NULL* 1483167605 0
> 65544 0 0 0 1 0 1262416901 0 *NULL*
>
> FRAG 2 1 16501472 0 2 14 1 000789 yos_sam1 65536 2 0 14 0 *NULL* 1483167605
> 0 65544 0 0 0 1 0 1262810326 0 *NULL*
>
>  #
>
> What I now need to do is expire the D11233 VTL tape and leave the 000789
> one alone.  After I RTFM I think the command below should do what I want but
> would like some verification before pulling the trigger:
>
> # bpexpdate  –backupid yos_sam1_1262415605  -m D11233  -d 0
>
> Can anyone see a problem with the above, will it only remove the images on
> D11233 for the backup id of yos_sam1_1262415605 and leave anything else
> alone?  Is there better way to do this?
>
> Thanks in advance….
>
> Wayne BeDour
>
> Unix System Administrator
>
> PH: 248-447-1739
>
> Internet: wbed...@lear.com
>
> **********************
> ** LEGAL DISCLAIMER **
> **********************
>
> This E-mail message and any attachments may contain
> legally privileged, confidential or proprietary
> information. If you are not the intended recipient(s),
> or the employee or agent responsible for delivery of
> this message to the intended recipient(s), you are
> hereby notified that any dissemination, distribution
> or copying of this E-mail message is strictly
> prohibited. If you have received this message in
> error, please immediately notify the sender and
> delete this E-mail message from your computer.
>
>
> Proud partner. Susan G. Komen for the Cure.
>
> *Please consider our environment before printing this e-mail or
> attachments.*
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you are
> not the intended recipient, any disclosure, copying, distribution, or use of
> the contents of this information is prohibited and may be unlawful. If you
> have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> ----------------------------------
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
_______________________________________________
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Reply via email to