Answers: <p>Reading your usecase it seem that the solutions your are looking for is the <code>refresh state</code> of terraform</p>
  <ul>
  <li><a href="https://developer.hashicorp.com/terraform/cli/commands/refresh" rel="nofollow noreferrer">https://developer.hashicorp.com/terraform/cli/commands/refresh</a></li>
  </ul>
  <p>Allowing you to refresh your state from the current architecture running without applying any diff</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-11-02T14:59:37.403Z
Answers: thanks for that.  However, I'd also need to import the replica volume as while TF told EFS to make a replica, the replica and its access point are not the main volume which is listed in the tf state.  That volume will be destroyed and then the replica will take its place
Answers: Peter Kahn
Answers: CC BY-SA 4.0
Answers: 2023-11-02T14:45:25.867Z
Answers: 2023-11-02T14:45:25.867Z
Answers: Juub
Body: <p>How do I use EFS block replication for disaster recovery when the replica volume is unknown to terraform?   After breaking the replication/mirror I need to import the volume into the plan so it can become the new main with it's own replica.</p>
  <p>This seems really cumbersome.  Is this really the best way for a DR scenario?</p>
  <p><strong>Use case</strong>
  We have a Jenkins using an EFS volume and presently use datasync tasks to migrate data to the DR region.  However, datasync tasks are like rsync and sluggish as they walk the tree processing files. Whereas, EFS replication is block based and much faster.</p>
  <ol>
  <li>terraform creates region A volume + access and replication in region B + access</li>
  <li>At some point region A goes down</li>
  <li>We delete the replication from A -&gt; B transforming region B EFS volume to writable and our primary volume</li>
  <li>We create a replication from this volume back to region A</li>
  <li>Allow sync</li>
  <li>Delete replication making region A replica the main volume</li>
  </ol>
  <p><strong>Terraform sync issues</strong>
  After step 3 we've got a main volume in region B that terraform would need to know about as terraform should be making the replica in region A</p>
  <p>After step 6 we've got the same problem in region A</p>
  <p><strong>Questions</strong></p>
  <ul>
  <li>Can someone point to a good example of an automated end of end process?</li>
  <li>Is this a case of &quot;import the infra into tf state&quot; as an automated part of the DR process?</li>
  </ul>
  
Tags: <terraform><amazon-efs>
Title: Making AWS EFS Replication play nice with Terraform for disaster recovery
UserDisplayName: Peter Kahn
ThreadText: # Making AWS EFS Replication play nice with Terraform for disaster recovery
  
  (Asked by: username_0 on 2023-11-01)
  
  How do I use EFS block replication for disaster recovery when the replica volume is unknown to terraform? After breaking the replication/mirror I need to import the volume into the plan so it can become the new main with it's own replica.
  
  This seems really cumbersome. Is this really the best way for a DR scenario?
  
  **Use case**
  We have a Jenkins using an EFS volume and presently use datasync tasks to migrate data to the DR region. However, datasync tasks are like rsync and sluggish as they walk the tree processing files. Whereas, EFS replication is block based and much faster.
  
  1. terraform creates region A volume + access and replication in region B + access
  2. At some point region A goes down
  3. We delete the replication from A -> B transforming region B EFS volume to writable and our primary volume
  4. We create a replication from this volume back to region A
  5. Allow sync
  6. Delete replication making region A replica the main volume
  
  **Terraform sync issues**
  After step 3 we've got a main volume in region B that terraform would need to know about as terraform should be making the replica in region A
  
  After step 6 we've got the same problem in region A
  
  **Questions**
  
  * Can someone point to a good example of an automated end of end process?
  * Is this a case of "import the infra into tf state" as an automated part of the DR process?
  
  **Tags:** terraform, amazon-efs
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-11-02. Score: 0
  
  Reading your usecase it seem that the solutions your are looking for is the `refresh state` of terraform
  
  * <https://developer.hashicorp.com/terraform/cli/commands/refresh>
  
  Allowing you to refresh your state from the current architecture running without applying any diff
  
  > **Comments:**
  > **username_0**: thanks for that.  However, I'd also need to import the replica volume as while TF told EFS to make a replica, the replica and its access point are not the main volume which is listed in the tf state.  That volume will be destroyed and then the replica will take its place  
  
  ---
  
  