3PAR Peer persistence and SAN mode backup

[lowlander]

Hi,

anyone is running a 3PAR peer persistence configuration in combination with Veeam. From HP point of view it is not allowed to present a disk to more than one operating system. These requirements came up after a new update of peer persistence, and are now listed in the HP SPOCK streams. Meaning that it wouldn't be allowed to connect a physical host to the 3PAR environment and do a backup based on [SAN] mode / storage integration with 3PAR ?!

How about the support from Veeam perspective. Is it allowed to make a backup of a disk that is within a peer persistence configuration, presenting this disk to a phyisical host that wil do [SAN] mode backup / restore ?

[foggy]

Could you please share any link where these requirements are outlined?

Basically, during backup from storage snapshot LUN is not presented to the proxy, but its copy from the snapshot is. I'm not sure how these restrictions could affect direct SAN, so would like to take a closer look at them.

[lowlander]

Hi Alexander,

it is listed in the General Support notes:

All host configurations represented in this matrix can be supported concurrently on a single pair of HP 3PAR StoreServ arrays. All volumes within an RC group must be exported to the same OS type.

GSN are available by the dropbox link:
https://www.dropbox.com/s/u8gichea6rob9 ... e.pdf?dl=0

[dellock6]

We have several customer using 3PAR in peer persistence together with Veeam, for example:
http://forums.veeam.com/vmware-vsphere- ... ce#p154189

Eric in particular is a skilled HP partner and he told me he deployed this combination several times.
So it's probably more an activity to be conducted with our alliance teams to have a better note in regards to Veeam accessing Peer Persitence volumes. Also because we just read data from those volumes, so I don't see how the windows-based Veeam proxy can harm any volume.

Thanks for the heads up!
Luca

[lowlander]

Hi Luca,

short follow-up on peer persistence. One of the "features" of peer persistence is protecting volumes in case of a failure by using a failsafe condition. Volumes in a peer persistence configuration are protected based on remote copy groups, where you have a primary volume on the source storage and a backup volume on the target storage where the primary volume is being replicated to the backup volume over FC or IP. When communication between the source storage with "a tie-breaker" and the target storage system is broken, the remote copy group will end in a failsafe condition, where IO to the primary volume is stopped, and wil continue on the backup volume. Replication will be stopped in this scenario.

I must admit, you should monitor your storage and recover from such a big failure condition adequate. However we would like to know how Veeam reacts on such a big failure condition in the remote copy group. Quite scary tot think of, if it turns out that Veeam is using the primary volume for performing a backup, resulting in data loss while changed data is handled by the backup volume.

So in short : Is Veeam aware of a failsafe condition, and how will this impact the backups that use storage integration with the 3PAR ?

Thanks !

[dellock6]

Thanks for the explanation, I don't think we are aware of the failsafe condition as for Veeam the peer persistence appears as one volume.
I believe it should be part of the failover process to also go and first disable any Veeam job pointing to the "wrong" site.