1. EC2 instances
The backup-restore strategies for the EC2 instances are more easily understood if we keep these points in mind.
- As these EC2 instances are managed by Elastic Beanstalk, the proper way to restore them is via Elastic Beanstalk.
- Our application may have "ebextensions" folder, which are deleted from the EC2 instances after successful deployment. A backup taken from the Elastic-Beanstalk-managed EC2 instance will not be a complete backup, as the "ebextensions" folder will be missing.
- The only sources of the "ebextensions" folder are the Beanstalk-managed S3 bucket containing current and previous versions of the application, and our local computer from where we upload the application.
- The Beanstalk-managed S3 bucket is deleted when the application is deleted via the Amazon Management Console.
Depending on the scenario where a restore is needed, basically there are 2 options.
a. The current version of our application has issues. We need to restore to a previous version of our application.
Everytime we upload our application, Elastic Beanstalk keeps a copy of it in an S3 bucket. (It has to, as it needs to reproduce the application when it spins up new instances.)
When we upload a newer version of our application, it still keep the older versions. These older versions can be deployed via "Upload and Deploy" button, then the "Application Versions page".
 |
| Redeploying an older version of our application. |
 |
| Accessing the older versions of our application... |
 |
| Click "Application Versions page" to access older versions of our application. |
b. The entire application gets deleted via the Amazon Management Console.
In such a scenario, the only way to restore the application is re-deploying the application from the local computer that has the application's folders and files, and the ".ebextensions" folder.
Thus, the backing up of that computer should be part of the backup strategy in the backup-restore plan of the load balanced EC2 instances.
 |
| Re-deploying application from computer containing ".ebextensions" folder and the application's files. |
2. RDS
The RDS can be treated as a single EC2 instance, and be backup up and restored using the method described here parts 6 to 9.
 |
| The RDS can be treated like a single EC2 instance, and be backed up and restored similarly. |
3. EFS
The EFS cannot be backed up directly.
The contents of the EFS has to be copied into an EC2 instance first. Only 1 copy has to be maintained.
That EC2 instance is then backed up using the usual method described here parts 6 to 8.
Here's how we can copy the contents of the EFS into an EC2 instance.
- Create an EC2 instance.
- Mount the EFS in the EC2 instance. For example,
# sudo mkdir -p /wpfiles # sudo chmod 777 /wpfiles # sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-5937d960.efs.ap-southeast-2.amazonaws.com:/ /wpfiles
- Copy the contents of the EFS into the EC2 instance using rsync. For example,
# mkdir /home/ec2-user/backup-volume # sudo rsync --recursive --update --perms --times --owner --group --verbose --stats --progress --links --delete /wpfiles/. /home/ec2-user/backup-volume(Only 1 copy needs to be maintained, similar to mirroring. Historical copies will be handled by the backup server.)
The "rsync" command can be placed in a cron job, preferably to be executed with the same frequency as the backup job.
We then backup the EC2 instance using usual methods described here parts 6 to 8.
 |
| 1. Copy the contents of the EFS into an EC2 instance, using rsync. Only 1 copy is needed, similar to mirroring. 2. Backup using the usual methods. Older copies are maintained by the backup server. |
After the EC2 instance has been restored, we mount the EFS in the restored EC2 instance using the same commands above.
We then copy the contents from the restored EC2 instance back into the EFS. For example,
# sudo rsync --recursive --update --perms --times --owner --group --verbose --stats --progress --links /home/ec2-user/backup-volume/. /wpfiles
