cancel
Showing results for 
Search instead for 
Did you mean: 

Restoring via XP Business Copy, while using mirror on primary site

Niksa_Francesch
Level 2

Hi,

situation we currently have is following:
Platform is Solaris 10 SPARC.

On production side we are using mirror within Veritas. Each half of mirror is on different XP24000 box, and while creating, expading, etc.. it's taken care that each half is based on enclosure.

We also use HP Business Copy on one storage to make a copy in time backup, which can also be made available on backup site.

To activate it on backup site it's done using 'vxdg -fC import <diskgroup>', and activationg volumes + mounting. Using -fC is required as disks were mounted on primary side, and when activating disk group, it cannot find other half of mirror (which is natural as there was mirror on production side, yet not on backup).

However, we have yet not tried proper recovery procedures in our scenario.

Has anyone some knowledge how we should make restore?

My main concern is this scenario: Primary site is working, we make a BC copy. However, after, for example, an upgrade is done, we need to revert to old copy.

We can resync backup to prouction - which means ONE half of copy is resynced from backup on primary site, but now is the tricky part:

If I just reactivate disk group, Veritas could see that 'production' one had newer timestamp than BC copy, and just resync mirror in that way that 'backup' we need to make as production is destroyed.

We need to be sure we can use backup copy, and make sure it will be primary copy when resyncing mirror.

 

I know it's a bit odd configuration, but this were business requirement we have.

If anyone has any ideas how to properly tackle this issues, would be most welcome :)

1 ACCEPTED SOLUTION

Accepted Solutions

Niksa_Francesch
Level 2

Hi,

after some testings, etc... seems that destroying on production side seems to be safest way to have consistent restore.

So basically what I do:

  • Have BC copy on another server. If it's mounted there or not, doesn't make a difference, except it's advisable to deport disk group before restore.
  • On production side destroy disk group. Disks will be shown only as initialized.
  • Use restore option with Business Copy, to get copy of disks on pruduction (example: pairresync -g dgtest -restore -IBC7)
  • On production server issue 'vxdisk scandisks' to re-discover those disks
  • Do 'vxdg import' on disk group, which will import BC disks *and* ones that held copy, but were marked as Initialized! Veritas seems to be smart in that way, as it automagically remembers where copy was.
  • After that just issue 'vxvol -g <diskgrp> -o bg startall' to get all volumes up, and have them resync in background
  • fsck/mount filesystem

This seems to be working well and reliable.

I must say I was a bit suprised that Veritas also automagically added disks from other box, that were just marked as 'Initialized', as they are supposed to be a mirror copy. That did reduce amount of work a *lot* - no need to fiddle with plexes manually.

View solution in original post

4 REPLIES 4

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Which VxVM version? What type of license key? If Enterprise License, you can use snapshots with diskgroup split and join.

Detailed steps in this FlashSnap manual: https://sort.symantec.com/public/documents/sf/5.0MP3/solaris/pdf/flashsnap_admin.pdf

Have a look at the section called 'Implementing off-host point-in-time copy solutions'.

MortenSeeberg
Level 6
Partner Accredited

I designet a similar environment to your setup once. Just one thing I need clarify: You got 3 copies in total? 1 set of LUNs in the primary XP, and 1 set in the secondary XP + a BC copy in the secondary XP.

 

So there are several options I can suggest:

1.  The option which Marianne is describing, which is basically stop using BC and zone in the 3rd copy to the server and use FlashSnap to snap of mirrors once in a while. Does require enterprise license (and you already paid for the HDS licenses and may already have this set up). Pro is that you can control everything from the production server, Con is that the backup LUNs controlled and available from the production server (which may not be what you want for security reasons).

If you want to continue using BC (which is also a great solution, especially if you got it scripted via CCI), then what you can do:

2. Do a "vxdg destroy" of the DG (2 primary copies) from the primary server (or whichever server you end up using after the failure) to clear the production site disks, before you reverse the BC mirror. If you are using a new server (due to the site failure) simply zone in the LUNs, import the DG and then destroy it before you reverse the BC.

3. If you have the option of mounting the BC copy on another server on the secondary site, run a script which remove the plex´es which are not accessible any more before you reverse sync the BC.

The price of #2 and #3 is that you need to do a full sync of the vxvm mirror after a recovery.

Obviously you need to test this! It doesn't have to be so difficult in the first try, just "borrow" 3 additional luns and setup a test disk group you can play around with until it works, then test it on the real production :)

 

Some other hints....

Remember to always suspend the BC after the reverse sync before you start doing any form of recovery/import on production, so in case anything goes wrong you have the BC copy to start the recovery over from.

Also depending on whether you have a database like Oracle or the like on these disks, remember to backup controlfiles + redo and archive logs before doing the reverse sync so that you dont loose any data. For people using Oracle I often suggest that people keep redo logs and archive logs in separate disk groups to avoid the confusion when restoring disks. If you use CCI I also recommend you create a CCI group per Veritas disk group.

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi,

 

For your first query you can use the following process. As you're not replicating all the disks in the diskgroup you'll need to remove the mirror (thats located on the non-replicated array) from the volume. As you might have noticed when you force import the disks a vxprint would show that some disks are missing/failed. Please note that after you run these commands the diskgroup will be modified, so if you sync back to PROD using the DR copy the changes will overwrite some of the disk in the group but not all. This could confuse vxvm. Bit of a tricky situation, if you want to keep the DR copy for use in case of a disaster don't perform these steps, but if you want to perform processing on the volume go ahead. Once you're done and turn on the replication again it will be over written.

 

https://sort.symantec.com/public/documents/sfha/5.1sp1/solaris/productguides/html/vxvm_admin/ch09s13.htm

 

For your second query you should be able to use the following process after you've sunchronized from DR to PROD.

 

https://sort.symantec.com/public/documents/sfha/5.1sp1/solaris/productguides/html/vxvm_tshoot/ch01s05.htm

 

This process allows you to choose the "good" plex when starting / recovering the volume. Please create a test volume using test luns using a similar setup to your production setup. Please test all of these thorouhgly before do it on production data. Its not a standard configuration so you need to understand what is happening and what the impacts are in either situation.

 

Niksa_Francesch
Level 2

Hi,

after some testings, etc... seems that destroying on production side seems to be safest way to have consistent restore.

So basically what I do:

  • Have BC copy on another server. If it's mounted there or not, doesn't make a difference, except it's advisable to deport disk group before restore.
  • On production side destroy disk group. Disks will be shown only as initialized.
  • Use restore option with Business Copy, to get copy of disks on pruduction (example: pairresync -g dgtest -restore -IBC7)
  • On production server issue 'vxdisk scandisks' to re-discover those disks
  • Do 'vxdg import' on disk group, which will import BC disks *and* ones that held copy, but were marked as Initialized! Veritas seems to be smart in that way, as it automagically remembers where copy was.
  • After that just issue 'vxvol -g <diskgrp> -o bg startall' to get all volumes up, and have them resync in background
  • fsck/mount filesystem

This seems to be working well and reliable.

I must say I was a bit suprised that Veritas also automagically added disks from other box, that were just marked as 'Initialized', as they are supposed to be a mirror copy. That did reduce amount of work a *lot* - no need to fiddle with plexes manually.