Hi,  The SRDF failback will automatically copy all invalid tracks from the R2 back to the R1. The update command is not necessary; it is intended as an optional step to periodically copy tracks from R2 to R1 if you're running on the R2s for an extended period of time, so that you have fewer tracks to copy back during the final failback operation.  When a failback is initiated for each specified SRDF pair in a device group, the following occurs:  ◆ The target (R2) device is write disabled to its local hosts. ◆ Traffic is suspended on the SRDF links. ◆ If the target side is operational, and there are invalid remote (R2) tracks on the source side (and the force option is specified), the invalid R1 source tracks are marked to refresh from the target side. ◆ The invalid tracks on the source (R1) side are refreshed from the target R2 side. The track tables are merged between the R1 and R2 sides. ◆ Traffic is resumed on the SRDF links. ◆ The source (R1) device is read/write enabled to its local hosts.
Hello everyone,  I'm both new to Symmetrix/VMAX and new to this forum, so please try to not judge me much. [IMAGE]  According to EMC® Solutions Enabler Symmetrix® SRDF Family CLI 7.5 product guide (P/N 300-014-881, REV A01), it's possible to restore from a failed over state unless I misunderstand the SRDF Pair State Reference table.  Solutions Enabler V7.5.1.0 (Edit Level: 1655) and SRDF/A are used here.  There are steps I performed: 1. Query to understand current state # symrdf -g dg-rdf-1 -rdfa query  Device Group (DG) Name             : dg-rdf-1 DG's Type                          : RDF1 DG's Symmetrix ID                  : There was local SID    (Microcode Version: 5876)  RDFA Session Number                : 0 RDFA Cycle Number                  : 0 RDFA Session Status                : Inactive RDFA Consistency Exempt Devices    : No RDFA Minimum Cycle Time            : 00:00:15 RDFA Avg Cycle Time                : 00:00:00 Duration of Last cycle             : 00:00:00 RDFA Session Priority              : 33 Tracks not Committed to the R2 Side: 0 Time that R2 is behind R1          : 02:47:40 R2 Image Capture Time              : Tue May 14 12:17:27 2013 R2 Data is Consistent              : True RDFA R1 Side Percent Cache In Use  : 0 RDFA R2 Side Percent Cache In Use  : 0 R1 Side DSE Used Tracks            : 0 R2 Side DSE Used Tracks            : 0 R1 Side Shared Tracks              : 0 Transmit Idle Time                 : 00:00:00  Remote Symmetrix ID                : There was remote SID    (Microcode Version: 5876) RDF (RA) Group Number              :   1 (00)         Source (R1) View                 Target (R2) View     MODES --------------------------------    ------------------------ ----- ------------              ST                  LI      ST Standard      A                   N       A Logical       T  R1 Inv   R2 Inv  K       T  R1 Inv   R2 Inv       RDF Pair Device  Dev   E  Tracks   Tracks  S Dev   E  Tracks   Tracks MDACE STATE -------------------------------- -- ------------------------ ----- ------------  DEV001  0555 WD       0        0 NR 0555 RW      82        0 A..X. Failed Over DEV002  055A WD       0        0 NR 055A RW    5946        0 A..X. Failed Over   Total          -------- --------           -------- --------   Track(s)            0        0               6028        0   MB(s)             0.0      0.0              376.8      0.0  Legend for MODES:  M(ode of Operation)   : A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy D(omino)              : X = Enabled, . = Disabled A(daptive Copy)       : D = Disk Mode, W = WP Mode, . = ACp off C(onsistency State)   : X = Enabled, . = Disabled, M = Mixed, - = N/A (Consistency) E(xempt): X = Enabled, . = Disabled, M = Mixed, - = N/A  2. Try to perform a restore # symrdf -g dg-rdf-1 restore Execute an RDF 'Incremental Restore' operation for device group 'dg-rdf-1' (y/ ) ? y  An RDF 'Incremental Restore' operation execution is in progress for device group 'dg-rdf-1'. Please wait...  The device is not in a valid RDF state for this operation  3. Enabled consistency could be an obstacle, so let's disable it # symrdf -g dg-rdf-1 disable  Execute an RDF 'Disable' operation for device group 'dg-rdf-1' (y/ ) ? y  An RDF 'Disable' operation execution is in progress for device group 'dg-rdf-1'. Please wait...  The RDF 'Disable' operation successfully executed for device group 'dg-rdf-1'.  4. Let's try to restore one more time # symrdf -g dg-rdf-1 restore  Execute an RDF 'Incremental Restore' operation for device group 'dg-rdf-1' (y/ ) ? y  An RDF 'Incremental Restore' operation execution is in progress for device group 'dg-rdf-1'. Please wait...  The device is not in a valid RDF state for this operation  When it didn't help, I gave up and used symrdf -g dg-rdf-1 update to pull invalidated tracks from R2 into R1 and then symrdf -g dg-rdf-1 failback. I don't consider it as a good solution because there could always be invalidated tracks between update and failback operations, so we could easily lose them.  Any ideas how to fail back to be sure that no track is lost?
Unable to perform "symrdf restore" from a failed over state