DR EVA4000 Replication site on Tru64

[Girdharilal]

Hi
We have EVA5000 at primary & EVA4000 at DR site. we are replicating data from primary site to DR site. At primary site, we had one vdisk1(300GB) on eva5000 and it is presented to the Tru64 5.1B OS. Inside the Tru64 OS, on the physical disk , we have created three logical volume each 100GB.

My concern is that once the vdisk1 from HQ replicated to DR site as vdisk1 and presented to DR server. question is that what about my logical partition which was created on primary site. Is eva4000 will keep logical partition information? If it will not retain info then how to get logical partition info from HQ server.

regards
Girdhari

[Mark Poeschl_2]

What are you using to create your logical volumes? If they're standard OS partitions with AdvFS filesystems on them, then your AdvFS domain information will not be replicated to the DR server. You would have to get the information from /etc/fdmns to the DR server separately.

If, on the other hand you're using something like LSM which keeps all its metadata in the private region of the disk your partitioning information should be available to the DR server. I've never actually tried this, but in theory I think it should work.

[Víctor Cespón]

All the replication is done in 1 MB blocks. The replication algorithm does not know what operating system is using the vdisks or how it creates the data structures. The EVA keeps flag bits on each 1 MB block, if any data is modified on it, it's copied to the other side.
This block can contain file, directory or partition data, it does not matter.

[Orrin]

Hi Girdhari,

Once replication is stopped and the disk is presented to the DR host.

You have to scan for the disk and then do a vgimport, to get the disk in, it will have all teh lv information intact, but you wiill have to recreate the directory structure to mount the different lv's.

Hope this helps.

O

[Girdharilal]

Dear all,

We are using standard OS partitions with AdvFs file system. Please let me know the step how to replicate/create or backup/restore domain information to DR site server and same hard disk partition size to DR site which are currently their in HQ server.

regards
Girdhari

[Rob Leadbeater]

Hi,

On the source server, you'll need to grab a coy of the disk label, then restore that on the destination server.

So something like:

Source:
# disklabel -r dskX > disklabel.txt

Destination
# disklabel -Rr -t advfs dskY disklabel.txt

where X and Y are the relevant disk devices.

You will then need to recreate the file structure and symbolic links under /etc/fdmns/ to point to the relevant partitions. Do an:

# cd /etc/fdmns
# ls -lR

to see what you need to create.

Hope this helps,

Regards,

Rob

[Girdharilal]

Hi Rob,

thnx for your help. I can see the replicated vdisk01 from primary eva5000 to DR storage eva4000. I can see DR vdisk01 property on EVA4000 and found that it is read only copy.

I still have not copied label from source server disk to destination server disk because of read only.

Now, my worry is that when have tried to suspend replication and found that disk is still in read only. Is there any way to get vdisk01 on DR EVA on read-write mode without remove source vdisk01 from DR group?

Second: If I remove source vdisk01 from DR group then replication will break then i can change data on DR vdisk01 on server.

Question: later on, if i add source vdisk01 in DR group back then what will happen on destination vdisk01. Is it overwrite existing data on vdisk01 on DR server or will continue resume whatever it has changed since you broke replication.

Regards
Girdhari

[Ivan Ferreira]

We have this DR solution in my company. A few comments:

>>> On the source server, you'll need to grab a coy of the disk label, then restore that on the destination server.

Not true. You don't need to copy/restore the disk label. The label will be on the destination vdisk.

>>> You will then need to recreate the file structure and symbolic links under /etc/fdmns/ to point to the relevant partitions. Do an:

True. You need to create the directory structure and point to the right device special file.


>>> I can see DR vdisk01 property on EVA4000 and found that it is read only copy.

Yes. It's a read only copy and will remain in that way until you perform a "failover".

>>> Now, my worry is that when have tried to suspend replication and found that disk is still in read only.

You need to "failover" DR Group.

>>> Second: If I remove source vdisk01 from DR group then replication will break then i can change data on DR vdisk01 on server.

If you delete the DR Group, you have the option to "Not delete the destination vdisk". In that case, once the DR Group is deleted, you can change the vdisk from read only to read write.

>> Question: later on, if i add source vdisk01 in DR group back then what will happen on destination vdisk01. Is it overwrite existing data on vdisk01 on DR server or will continue resume whatever it has changed since you broke replication.

You have to delete the destination vdisk a create a full new copy.

[Girdharilal]

Hi Ivan,

Again thx for your reply.

In a DR fail over situation, your source becomes destination and destination becomes source.
Suppose, after DR fail over , you found that some data or oracle data is corrupted on DR Vdisk . In that, it will replicate from your destination to source since you have DR fail over. What about my original data which was at Primary Site.

Secondly: Is this steps are correct for domain/file structure.

suppose you have four partition a, b, e,g and take e.g of a partition

#mkdir /etc/fdmns/account
#cd /etc/fdmns/account
#ln -s /dev/disk/dsk22a
#mkfset account data1
#mount -t advfs -o dual account#data1 /data1

regards
Girdhari

[Ivan Ferreira]

>>> In a DR fail over situation, your source becomes destination and destination becomes source.
Suppose, after DR fail over , you found that some data or oracle data is corrupted on DR Vdisk . In that, it will replicate from your destination to source since you have DR fail over.

That is correct.

>>> What about my original data which was at Primary Site.

Will be also corrupt. You have the choices to:

- Delete de DR Group without deleting the destination vdisk instead of a failover.

- Perform a failover followed by a suspend, ensure data integrity, then resume. But if the data is corrupt right after the failover, then it was corrupt before, so, for data corruption, you need another plan, like DataGuard.

>>> suppose you have four partition a, b, e,g and take e.g of a partition

#mkdir /etc/fdmns/account
#cd /etc/fdmns/account
#ln -s /dev/disk/dsk22a

Correct so far. If dsk22 is the correct disk.

#mkfset account data1

You do NOT have to run mkfset. Once the directory structure is created, you will be able to display and mount all filesets.

#mount -t advfs -o dual account#data1 /data1

You only have to specify -o dual if the same server can access the original and copy vdisks.

BTW, I see in your profile "I have assigned points to 0 of 16 responses to my questions."

Please take a time and assign points to the answers you get. Please review this link for help:

http://forums1.itrc.hp.com/service/forums/helptips.do?#28