Migrating from Amazon Web Services v2 to AWS v4 Authentication.
On June 24, 2020*, AWS will fully stop support for V2 authentication to S3. Centos 6 appliances by default use V2 authentication and must be switched to using V4, Centos 7 appliances use V4 authentication by default.
*Amazon has extended support for v2 signatures for another year for accessing buckets, but no new v2 buckets can be created after June 24, 2019. Amazon originally stated that support for V2 buckets would end on June 24, 2019 but later extend support until June 24, 2020. https://aws.amazon.com/blogs/aws/amazon-s3-update-sigv2-deprecation-period-extended-modified/
Unitrends customers who are sending cold backup copies to AWS S3 still need to upgrade to Unitrends software v10.3.6-2 or later and migrate to an AWS V4 bucket at your earliest convenience. However, the June 24, 2019 deadline has been extended. Unitrends customers with existing AWS EC2 buckets will continue to support SigV2 while we work with you to move off this older request signing method.
Unitrends customers with data in Amazon GovCloud are not affected by this signature change do not need to take action.
To determine if your S3 Backup Copy target is using V2 authentication go to the “Backup Copy Targets” tab on the “Configure” page. If the Type for the target is “cloud” then it is using V2 authentication, V4 authentication will show as Type “cloud2”.
Upgrade your Unitrends Appliance
- Before migrating your AWS S3 bucket, upgrade your Unitrends system to release version 10.3.6-3 or newer.
Enabling AWS V4 Authentication
- To enable AWS V4 Authentication for Cold Backup Copies add the following settings to the "CloudHook" section of the file /usr/bp/bpinit/master.ini:
CloudTempDir=/backups/tmp CloudDockerCmd=/usr/bp/bin/container CloudDockerStart=/usr/bp/bin/container start CloudDockerStop=/usr/bp/bin/container stop CloudRegion=us-east-1
- Set AWS CloudRegion to be the correct default region.
Migrating data from an old V2 bucket to a new V4 bucket*
- This must be done from a Centos 6 appliance that has been upgraded to 10.3.6-2 with the old Backup Copy target already added.
- First enable V4 Authentication by adding the settings mentioned above, then create a new Backup Copy target using a new bucket in AWS. After it has been added, check in the UI in the “Backup Copy Targets” tab and make sure the Type is "cloud2".
- This process may take a significant amount of time depending on the amount of data being migrated. Start a screen session to allow this process to complete without being interupted.
- Next, from the command line, run the migrate_S3_data.sh script. It takes two parameters, the old storage name and the new storage name in that order. So if the old storage was named "Cloud_Storage" and the new storage was named "Cloud_Storage_New" the script would be run like this (names are case-sensitive):
/usr/bp/bin/migrate_S3_data.sh Cloud_Storage Cloud_Storage_New
The script outputs progress to the terminal as well as writing to a log file, /usr/bp/logs.dir/migrate_S3_data.log.
- When the script finishes all data should be in the new bucket and all schedules and profiles should be updated to use the new Backup Copy target.
- Launch your EC2 in same region as your S3 bucket.
- Choose at least t3a.medium instance type.
Check you S3 Bucket region:
- Log into AWS, from Services dropdown, go to S3.
- Check the region for the required S3 bucket.
**Requires running a VM in EC2 cloud.
- During this process, data is copied between bucket to bucket. We do not anticipate any disk usage on the Unitrends appliance but CPU and RAM utilization may receive a slight impact during the process.
- The attached CloudHook Migration process may be used as an alternate route to migrate buckets. The CloudHook Migration process migrates buckets from within the AWS cloud on a CentOS 7 Linux server deploy into EC2 for this purpose.