2012-08-30 05:43 AM
After snapmirror break destination is converted to 64 bit. No the question is - is it supported to resync back from 32 bit source and continue 32 bit snapmirror? I tested it on simulator and it seems to work just fine. Which makes sense as it basically reverts destination to pre-64 bit state. But just to be sure - is it really supported?
I am currently facing situation when I need either incur serious downtime to convert source to 64 bit, or simply let it continue with 32 bit source. Of course I'd rather avoid downtime if at all possible.
Solved! SEE THE SOLUTION
2012-08-30 07:10 AM
There is no option to resysnc from 64 to 32 bit.
One step back, if the source aggregate exceeds its size by 18TB, 8.1.1 will automatically converts the volume and aggregate to 64-bit.
2012-08-30 08:24 AM
Yes, I did review this TR and I do not see this scenario described there. I'll try to clarify
1. I have 32 bit source s32 on 32 bit aggregate and destination d64 on 64 bit aggregate
2. snapmirror initialize -S s32 d64. This results in 32 bit volume d64 created
3. snapmirror break d64. This results in d64 converted to 64 bit
4. Now I want to be able to perform "snapmirror resync -S s32 d64" to continue relationship and avoid full reinit
As mentioned, I tested this (also via cascading) in 8.1.1 sim and it works (d64 reverts to 32 bit volume after resync), but I would love to have confirmation that it works as intended and is supported.
2012-08-30 10:04 PM
Customer has primary site with mix of 32 and 64 bit volumes and DR site. There is drill down procedure which involves breaking snapmirror, testing application on DR site and resuming (resync) snapmirror. Currently DR site undergoes hardware refresh (head swap, decommissioning of ESH2 shelves). It appears that the only space to relocate data from decommissioned shelves is on 64 bit aggregate. So I am looking for the least intrusive way to perform hardware refresh while minimizing changes to existing DR operational procedures.
Thank you for taking care of it!