Embedded Files
JSD AWS CloudFormation RDS PostgreSQL Upgrade
JSD AWS CloudFormation RDS PostgreSQL Upgrade
JSD AWS CloudFormation RDS PostgreSQL Change Storage Encryption
JSD AWS CloudFormation RDS PostgreSQL Change Storage Encryption
JSD AWS CloudFormation VPC CIDR Block Update
JSD AWS CloudFormation VPC CIDR Block Update
These steps cover migration of JSD from one CloudFormation Stack to another. This is useful in the following scenarios...
To upgrade/change the underlying database (i.e. install the new database version as part of a new Stack and import the data from the old Stack into it). I have tested this process for: an upgrade of RDS PostgreSQL from 9 to 11, a move from unencrypted database storage to encrypted database storage.
To change the CIDR blocks allocated to a VPC. This is useful if you want to set up a VPN and the existing CIDR blocks clash with those in the other network.
This process is the same irrespective of whether the new Stack creates a new VPC in the same account as the original Stack or a new VPC in a different account
First install the target JSD Stack being sure to make the necessary parameter changes. If you are creating a new VPC in an existing account you should change the ASI Identifier and the VPC CIDR blocks.
DO NOT CHANGE THE JIRA VERSION.
Follow the JSD AWS upgrade instructions as a separate step after the migration is complete if necessary.If you plan to use the same DNS entry to access the new ASI Stack once migration is complete, make sure you enter the same "Existing DNS Name" parameter value (this will cause JSD to complain until DNS is updated but these warnings will not prevent completion of the steps below.
STOP WHEN YOU GET TO THIS PAGE...
You could use the "import your data" link later on (but be careful about email settings). If you are not doing a direct swap then it is safest to close this screen at this point.
Configure ssh so that you can easily connect to a Jira node in the source and target Stacks. Your config file in ~/.ssh should look something like this...
Host 11.11.11.11
ForwardAgent yes
User ec2-user
Host 10.10.10.10
ProxyCommand ssh -A ec2-user@11.11.11.11 -W %h:%p
User ec2-user
Host 22.22.22.22
ForwardAgent yes
User ec2-user
Host 20.20.20.20
ProxyCommand ssh -A ec2-user@22.22.22.22 -W %h:%p
User ec2-user
Where 11.11.11.11 is the external IP of the Source Bastion
Where 10.10.10.10 is the internal IP of the Source Jira Node
Where 11.11.11.11 is the external IP of the Source Bastion
Where 22.22.22.22 is the external IP of the Target Bastion
Where 20.20.20.20 is the internal IP of the Target Jira Node
Where 22.22.22.22 is the external IP of the Target Bastion
Backup the Source Database & Attachments/Avatars
Backup the Source Database & Attachments/Avatars
NOTE: To ensure the backup is consistent and complete you should prevent users from updating the system. If the system is updated after the backup starts data could be lost.
In the source JSD application...
Administration (cog) - System - Import & Export - Backup System
Enter an arbitrary filename and click Backup
This will create a zip file in /media/atl/jira/shared/export/ on the Jira node (this is an EFS filesystem so it should be visible from any Jira node)
With your ssh environment setup for the source ASI Stack...
ssh $sourceIPaddress
sudo su - root
cp /media/atl/jira/shared/export/backupfilename.zip /tmp
chmod uog+r /tmp/backupfilename.zip
zip -r /tmp/datafilename.zip /media/atl/jira/shared/data/*
exit
exit
scp $sourceIPaddress:/tmp/backupfilename.zip .
scp $sourceIPaddress:/tmp/datafilename.zip .
# Establish ssh connection to source Jira server
# Switch user to 'root'
# Copy the Jira backup to /tmp
# Enable ec2-user to be able to scp it
# Backup Attachments/Avatars
# exit root
# exit
# Copy the backup to your local machine
# Copy the Attachments backup to local machine
Restore the Target Database & Attachments/Avatars
Restore the Target Database & Attachments/Avatars
With your ssh environment setup for the target ASI Stack...
ssh $targetIPaddress
sudo su - root
service jira stop
Un-comment the following line in /bin/setenv.sh...
DISABLE_NOTIFICATIONS=" -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true"service jira start
With your ssh environment setup for the target ASI Stack...
scp backupfilename.zip $targetIPaddress:/tmp
scp datafilename.zip $targetIPaddress:/tmp
ssh $targetIPaddress
sudo su - root
unzip /tmp/datafilename.zip -d /
chown -R jira:jira /media/atl/jira/shared/data
cp /tmp/backupfilename.zip /media/atl/jira/shared/import
rm /tmp/datafilename.zip /tmp/backupfilename.zip
exit
exit
# Copy the backup to the target Jira server
# Copy the Attachments backup to the target Jira server
# Establish ssh connection to the target Jira server
# Switch user to 'root'
# Unzip the Attachments backup
# Set file ownership correctly
# Copy the backup file to the import location
# Tidy up
# exit root
# exit
Return to the "Setup Application Properties" screen in your new Jira application.
Point the restore process to: /media/atl/jira/shared/import/backupfilename.zip
Alternatively (e.g. if you have accidentally closed that screen) in the source JSD application...
Administration (cog) - System - Import & Export - Restore System
Bibliography
Bibliography
https://confluence.atlassian.com/adminjiraserver/backing-up-data-938847673.htmlhttps://confluence.atlassian.com/adminjiraserver/restoring-data-938847686.htmlhttps://confluence.atlassian.com/adminjiraserver/migrating-jira-applications-to-another-server-938846962.htmlhttps://confluence.atlassian.com/adminjiraserver/restoring-data-from-an-xml-backup-938847707.htmlhttps://confluence.atlassian.com/jirakb/how-to-use-the-data-center-migration-app-to-migrate-jira-to-an-aws-cluster-1005781495.htmlhttps://confluence.atlassian.com/adminjiraserver0814/creating-a-test-environment-for-jira-1043893463.html
Page updated
Google Sites
Report abuse