The divine usage of Cloudberry Drive

Colleagues asked me to help transfer some data from S3 under one AWS to S3 under another account in many ways, such as AWS CLI, but I still like visualization, so I thought of using Cloudberry Drive and Cloudberry Backup to migrate, both of which have a 15-day trial period, during which I can transfer the data. The idea is to mount my S3 as a local site, and then transfer the data from this local disk to my colleague's S3 through Backup.

So after setting up my IAM account and permission settings, I installed these two software and started to run. Cloudberry Drive set up my account smoothly, but there was a problem in setting up my colleague's account. The IAM setting did not have the permission of list bucket, and my colleagues were sometimes lagging in Europe, so they were resting at this time, so I thought, I'd better do it myself. I've used Cloudberry Explorer before. If I can't list bucket, you can solve it by entering the bucket name manually. Fortunately, Cloudberry Drive can lose path by hand.

However, when setting Cloudberry Backup, it is written to stop, because the software Backup can only list bucket itself and then let you choose. As shown in the figure below, bucket cannot be listed because there is no permission.

After thinking about it for a while, in that case, can the two S3s both map low-cost disks and then transfer data by copying and pasting each other? Anyway, I can only try this way at present, so I try to load my colleague's S3 into a disk, and then I find that both of them can be opened without conflict. The mount disk should be opened in this way, because these two disks cannot be seen under my computer.

Looking at the transmission speed, it feels good and stable.