Backup Restoration after transferring EFS and Database to another AWS AccountID #6165
Replies: 1 comment 8 replies
-
I was able to eliminate the 502 Bad Gateway error. The problem was that the database that downloaded account "A" had no password (or any other). But HC still has problems:
How to website is loading (account "B") How to website is loading (account "A"). This it works: staging.mtkct.com-1689265375298.log |
Beta Was this translation helpful? Give feedback.
-
Description
I'm getting 502 Bad Gateway when trying to access Cloud Admin Hubs after creating a new stack using the backup restore option.
The scenario is: two AWS accounts (two AccountIDs), where, in one (we'll call it "A" account) there are several scenarios created (about 300), and the objective is to replicate all this environment, scenarios, etc., in another AWS account (another AccountID. Let's call it account "B"). In this account, the stack is named "test-001".
To Reproduce
Steps to reproduce the behavior:
Create a stack on account "B" with the same name as the stack on account "A". Eg: test-001
Transfer the file system (StorageEFS) of the "original" stack from account "A", which is populated (using DataSync), into the file system of the stack from account "B". After completing this step, if you access one of the EC2 stacks from account "B", you will see that the size of the /storage directory has increased to the same size as the file system from account "A". Use the
df -h
command to view the mount points.In account "A", create a DB snapshot of the stack that is populated. It has to be the same as the file system.
If your stack on account "B" is in a different region than the stack on account "A", copy the snapshot to the desired region. That is, if your stack in account "A" is in Oregon, but your desire is to lift Hubs Cloud in N. Virginia, copy the Database snapshot to Virginia before sharing it with account "B".
You will also need to create and share an AWS KMS key (on account "A") and share it with account "B".
NOTE: Do not choose an AWS managed KMS key. Create a new one.
Still on account "A", share the snapshot with account "B" informing your accountID.
In account "B", go to RDS > Snapshots: Shared with me.
Select the snapshot, click on Actions and Copy Snapshot. Set a name for the snapshot (which will be copied to your "B" account in the Manual tab) and enter the ARN of the KMS key you created in the account
Now that the snapshot is available on your "B" account, restore the Database from that snapshot. You can now use the AWS shared key from the KMS.
In the Connectivity settings, I selected the same stack options I created earlier (item 1).
Create a new secret for the DB you just created in AWS Secrets Manager > Secrets. It will be the ARN of this secret that you will use to populate the Restore From Secret Database ARN field in CloudFormation.
Now create a new snapshot of this new DB. It will be the name of this snapshot that you will use to fill in the "Restore From Database Snapshot Identifier" field in CloudFormation
Now, let's create a new stack in the "B" account, filling in the Mozilla Template Backup Restoration fields in CloudFormation.
If you don't have any other domains for this new stack, you will need to delete the previous stack (from the "B" account). In my case, as I have two more domains available, I was able to create the new one, keeping the previous stack active.
Campos de restauração de backup do formulário:
New stack "test-001-backup" (on account "B") was created without errors.
Expected behavior
Expected behavior
I expected that, when accessing this new environment, it would already be fully populated, with all the more than 300 scenarios that had been created in the production account (account "A") and everything working normally.
Hardware
Beta Was this translation helpful? Give feedback.
All reactions